Requirements Gathering Approach
One of the first challenges to producing an SRS document is determining the approach. How do we gather requirements and develop an understanding of the domain of a business? There is no single answer to this question. The method depends on the circumstances, the level of access available to the company, and their personnel, systems, processes, and data. Given the challenges, it is beneficial to identify some example approaches that can be used individually or in combination depending on the circumstances of any given project. To that end, here is a list of a few of the common approaches used during the first two steps of the SDLC:
- Interviews — Interviewing key personnel in the business is a common approach for gathering requirements and domain information.
- Questionnaires — If the number of personnel is large, questionnaires can be sent to any number of people to gather requirements and domain information.
- Observation — Processes in a business handled by humans, which may become part of a new software system, are often best understood and documented through observation.
- Brainstorming — Gathering a group of crucial personnel together and brainstorming the new system’s needs is often a fruitful approach for gathering requirements and understanding the business domain.
- Document Review — There may be existing documentation, instructions, diagrams, etc., that the software engineer can review to gather information about the requirements.
- Sampling — When project requirements include complex data or processes, taking samples of data and experimenting with business rules with those samples often reveal a great deal of technical detail about the data and processes.
- Prototyping — Software Engineers often create a simplified solution prototype for the customer to review to help confirm the engineer’s understanding of the requirements and domain.
