Software Requirements Gathering

This article outlines some of key techniques and methods that can be used for gathering and capturing requirements on a software project. It includes some suggestions and ideas to capture the different types of requirement during the gathering process.

 

What is Requirements Gathering?

Requirements Gathering is the process of generating a list of requirements (functional, system, technical, etc.) from the various stakeholders (customers, users, staff, etc.) that will be used as the basis for the formal Requirements Definition.

The process is not as straightforward as just asking the stakeholders what they want in the system to do, as in many cases, they are not aware of all the possibilities that exist, and may be limited by their immersion in the current state. For example: In my current job, I have to work with many Govt. employees. Recently, I am working in a management system. Collecting requirement is the hardest part for me because they don’t know what exactly they want from the software. It is because they are not the direct stakeholder, they are not going to use this. For this, I have to observe their work for few days how they exactly do this process in the paper-based system.

What Techniques Can Be Used?

  • Interviews – These are an invaluable tool at the beginning of the process of getting background information on the business problems and understanding a current-world perspective of what the system being proposed needs to do. You need to make sure that your interviews cover a diverse cross-section of different stakeholders so that the requirements are not skewed towards one particular function or area.
  • Questionnaires – One of the challenges with interviews is that you will only get the information that the person is consciously aware of. Sometimes there are latent requirements and features that are better obtained through questionnaires. By using carefully chosen, probing questions (based on the information captured in prior interviews), you can drill-down on specific areas that the stakeholders don’t know are important, but can be critical to the eventual design of the system.
  • User Observation – One of the best ways to determine the features of a system is to observe users actually performing their daily tasks, and ideally recording the actions and activities that take place. By understanding the holistic context of how they perform the tasks, you can write requirements that will reinvent the processes rather than just automating them, and will ensure that usability is paramount.
  • Workshops – Once you have the broad set of potential requirements defined, you will need to reconcile divergent opinions and contrasting views to ensure that the system will meet the needs of all users and not just the most vocal group. Workshops are a crucial tool that can be used to validate the initial requirements, generate additional detail, gain consensus and capture the constraining assumptions. Specifically, I call it PPT demo presentation (I don’t know the exact term). Here You don’t need to build everything, Just a simple flow of the system in ppt with the real example of stakeholders act.
  • Brainstorming – This is a powerful activity, which can be performed either in the context of a workshop or on its own. By considering different parts of the system and considering scenarios or ideas, you can break out of the context of the current-state and consider visionary ideas for the future. Tools such as whiteboards or mind-mapping software can be very helpful in this phase. I personally prefer Whiteboard as it gives me the real feel.
  • Use Cases & Scenarios – Once you have the high-level functional requirements defined, it is useful to develop different use-cases and scenarios that can be used to validate the functionality in different situations and to discover any special exception or boundary cases that need to be considered.
  • Prototyping – There is truth to the saying “I don’t know what I want, but I know that I don’t want that!”. Often stakeholders won’t have a clear idea of what the requirements are, but if you put together several different prototypes of what the future could be, they will know which parts they like. You can then synthesize the different favored parts of the prototypes to reverse-engineer the requirements. You don’t need to build the whole system to make it. Just use the confirm flow from the workshop section and convert it to into a demo. For mockup or prototyping, there are lots of online tools. You can use those.

 

There are many different ways to capture the information, from a simple Word document, spreadsheet or presentation to sophisticated modeling diagrams. I recommend that the initial high-level brainstorming and requirements discovery be done on a whiteboard. After the confirmation makes it well documented.

 

Note: Don’t forget to take an autograph of your Stakeholders, at least 3 persons. I don’t know in Bangladesh the growth of changing the face of people is more than the growth of their hair.

Hopefully, It will help you in future someway or think you just read a useless article in a tech magazine.