Requirements Gathering (Part I) -What I’m suppose to do in requirements gathering?
The requirements gathering is a fundamental process in the construction of any project (an application, a module, a functionality…).
It may seem like a fairly easy process, however, anyone working in this area knows that not even the customers know what they prefer.
We know that without consistent and solid roots hardly a tree bears fruit, so let’s focus on construct good roots with excelent requirements!
There are three sources you should consider:
- Use of existing systems/applications:
Advantages: Knowledge of the application for which functional analysis or knowledge of another application of the company is being carried out, perception of how the application was built, how it is interconnected with other applications; perception of what should be done and also of what should not be done. It is also extremely important (when we put ourselves in the user’s shoes) to understand the operation of the business.
Disadvantages: A lot of time is spent. If the purpose is the construction of a new application, we can be biased by the one that already exists.
2. Documentation ( Functional/Business Requirements Documents, User Manuals, Technical Manuals…)
Advantages: Documentation is an excellent source of knowledge. It is usually very detailed and has details that can escape in a common dialogue. It may have been carried out by people who are no longer even in the same workplace and, consequently, have information that could never arise since it would no longer be possible to speak to that person. It may have schematized information (diagrams, flowcharts) that allow a better perception of the business in question than in dialogue.
Disadvantages: Sometimes the documentation contains incorrect or outdated information, may take longer than expected and if doubts arise and the person is no longer in the workplace, it may never be clarified.
Be carefull: All regulations, directives, laws (…) that are involved in the scope of the project for which the requirements are being surveyed must be read by the functional analyst and, whenever doubts arise, they must be clarified either with the entities, or with experts in the business…
3. Dialogue with stakeholders
Advantages: Project stakeholders are an important source of information in requirements gathering. The dialogue with stakeholders (customers, managers, colleagues, Product Owner, people with a lot of knowledge of the business…) should be carried out with the objective that the information exchanged is clear and transparent so that there are as few failures as possible in the specification of requirements. The functional analyst must, together with the Product Owner, try to maximize the value of the product.
Disadvantages: Stakeholders are usually very busy and difficult to access people. There may also be conflicts of interest between stakeholders so it is necessary to know how to manage them.
How to plan the requirements gathering?
The first step is to identify the stakeholders involved in the projects. . All the people that the project sponsor mentions will be stakeholders.
You should ask to the project sponsor if there are more people relevant to the project that he didn’t mention and, among other questions, do the following: Who will be using the solution? Who is impacted by the problem today?
After identifying all the stakeholders, they should be classified by the most diverse categories:
· greater/lesser interest
· greater/lesser decision-making power
· effectively use the applications/only guide those who uses.
This classification can also be done with the help of the sponsor.