Requirements Elicitation
https://www.elementool.com/
Your first responsibility in good requirements management is requirements elicitation and we’re going to give you the 411 on how it works. Requirements elicitation is the method for determining the needs of all the customers and users in the project. This is a very important process, and it requires a collaborative effort between the development team and the client. Our new program helps to facilitate requirements elicitation, making it a straightforward process that allows you to easily organize and prioritize important information.
One thing to keep in mind about requirements elicitation is that it isn’t necessarily just a matter of asking the customer what they want. You have to dig deeper than that, read between the lines, and learn to use your own expertise to understand what they truly need. It’s sort of like when you take your broken-down car to a mechanic. He doesn’t ask if you want him to replace this part or tighten that screw. All he has to know is that you need the car to run – he’ll figure out the rest. So, when you’re meeting with a client, don’t just ask “What do you want?” Instead, ask “What do you need to do?” That way, your client will tell you what they ultimately need to accomplish, and you can help them find the best way to make that happen.
“Why?” is another important question to have in your arsenal. As the customer presents his requirements, don’t be afraid to ask “Why?” when appropriate. Chances are it will help lead the development team and the client to a better understanding of both the problem and the solution.
Take care to learn as much as you can about the client’s current processes. What don’t they like about it now? What do they want to see improve? And don’t just write down what they say and leave it at that. Create a conversation with your client, with lots of give and take. Suggest ideas that come to you on the fly and get their feedback on those ideas.
You should review the full client vision, including future goals and tangential projects, and interview the client stakeholders to get the full set of requirements.
There are often very important unstated requirements that are uncovered and are essential for the project to meet its objectives. As a result the project will meet the written requirements but will not be a success, as the client will be dissatisfied because it doesn't fit the full vision the client have but didn't elucidate.
You must attend to the speaker, and then repeat, in your words, what you think the speaker said. This allows the speaker to determine if you really understood. If something is missing, the speaker can further explain the point. Usually when people feel that the other side listens to them, it encourages them to share more details.
When taking requirements notes make eye contact with the speaker, don't multitask and do other things while listening to the speaker. Do not interrupt the let the other side finish what they say. Clarify the points that you don't understand, and ask for more details if needed.
Summarize the conversation by organizing the key points and play them back for the speaker.
We are taught that is rude to ask personal questions. People will answer personal questions if they will get them what they want. People will talk all day long about their fears, wants, and frustrations if they feel it will help them to get what they want.
If some requirements or client requests don't seem reasonable, you should question them. Something that might seem like a simple request from the client may be a huge commitment on our side. We should clarify this to the client and consider the benefit of the request in compared to the cost. Remember, in many cases the client don't know what is required to develop a feature (this is why they hired you).
Identifying users is another significant component of requirements elicitation, and our program will make that process much easier as well. There are a few different types of users, and the ways in which they differ include: how often they use the product, what features they use, which tasks they perform for their business processes, their level of experience and systems expertise, and their security levels or access privileges. It can be helpful to classify users based on these differences. Keep in mind, though, that some people may belong to more than one class.
Also keep in mind that some users may not even be people. No, robots aren’t taking over the world – yet. I’m just referring to the fact that some applications or hardware components might be interacting with your system, and these could be considered their own class of users.
A good way to confirm that you really get when the client means is to write down their requirements and then repeat it back to them for confirmation and to make sure you are correct. Ask more questions to clarify necessary data.