The development team is expected to determine both functional and nonfunctional
ID: 3743839 • Letter: T
Question
The development team is expected to determine both functional and nonfunctional requirements. Some analysts may have strong business backgrounds which help them to understand the functional requirements quite well, but have a harder time even knowing what is important in the nonfunctional area. Similarly an analyst may have strong programming and other technical skills but not understand workflows or business process well.
Please respond to the following questions in a forum posting:
If you do not have a strong technical background, how do you ensure that you have found out all of the important nonfunctional requirements? How do you test or validate that you are not missing important things?
Similarly if you do not have a strong business process background, or very much knowledge about the problem domain (e.g. the business area being supported), how do you ensure that you have asked all the important questions and that your requirements are accurate, thorough, and comprehensive?
What are some techniques that might help you to have good interviews that get to the root of the issues?
Explanation / Answer
The thing is, we are conducting interviews of people form the required backgrounds and we can use that to our advantage.
If i do not have a strong technical background, i will most likely take a structured interview followed by off-hand questions. To prepare for the structured part of the interview, it is good to first research on what kind of questions i need to ask while keeping in mind the needs of the project. It's also good to sit and discuss these things with someone from this background before interviewing the required people. Also, it will help in getting an analysis of what the consumers of the end produnt are likely to be expecting from it. During interview, we can use answers to the structured questions as premise to unerstand and ask a few off-hand questions. To test this method, the easiest way is to incorporate a few external stakeholders to the project and give them the details and ask them how good they think our technical feature are.
To get into the business side aspect, it's first of all, good to talk with your manager about the requirements, budget and the expectations of the board from the project. This can help in seeing a clearer picture. Since this involves the company's finances, we can't involve outside stakeholders here.
A better approach is research, followed by discussing the aboce details with the project manager, and try to imagine yourself implementing the decisions taken. After the intrview, it's better to discuss the outcomes and infromation obtained with the financial managers, and try to run a simulation of the project with the necessary constraints to try and see if something was missed out.
To get to the root of issues, it always helps to know the expectations of the company with the product. These will serve as management and financial guidelines. Then, expectations of the consumers should be taken into account. That will give an idea of what people want. After that, a market survey should be done to identify potential competitors and how they're dealing with such problems. After all this, discussions and deliberatioins should be carried out and simulations done(if required) to make sure nothing was missed. The end goal is to make both the consumers and the company happy.