Software requirement elicitation is the process of gathering, identifying, and defining the needs and constraints for a software system. Here are the key steps involved:
- Stakeholder Identification
- Identify all parties who have an interest in the system
- Include end-users, clients, developers, management, and domain experts
- Preparation
- Research the domain and existing systems
- Establish goals and scope for the elicitation process
- Develop initial questions and discussion topics
- Information Gathering
- Conduct interviews with stakeholders
- Organise workshops and brainstorming sessions
- Distribute questionnaires and surveys
- Observe users in their work environment
- Review existing documentation and systems
- Collaborative Techniques
- Use Joint Application Development sessions
- Implement focus groups
- Conduct prototyping sessions
- Apply user stories and scenarios
- Create use cases
- Analysis and Validation
- Organise and categorise collected requirements
- Identify conflicts and inconsistencies
- Validate requirements with stakeholders
- Prioritise requirements (MoSCoW method: Must have, Should have, Could have, Won’t have)
- Documentation
- Document requirements in clear, consistent language
- Create formal requirement specifications
- Develop models and diagrams (usecases, personas, stories, use case diagrams, etc.)
- Review and Refinement
- Conduct formal review sessions
- Refine requirements based on feedback
- Establish traceability between requirements
- Management and Control
- Establish version control for requirements
- Create a change management process
- Maintain requirement traceability matrix
This is an iterative process, with multiple cycles of gathering, analysing, and refining requirements as the understanding of the system evolves.
Requirement analysis
Vision & scope
The Vision & Scope is a very high level strategic document that defines what the organisation wishes to achieve with this project, or why the organisation is implementing this system. (In some cases, business —i.e. the funder— is different from the user). It is not always present. (Learn more in Vision & Scope Document)
User Requirements Specification (SRS)
The User Requirement Specification is typically produced by the customer organisation (based on the Vision & Scope if present), and used for advertising the project availability if multiple competing contractors are available. On the other hand, if only a single contractor is present, they may work with the customer organisation in producing the URS. It describes the task the system should perform that will provide value to the user. These are typically captured using Personas, Use-cases, User-stories. (Learn more in User Requirement Specification (URS))
Software Requirement Specification (SRS)
The Software Requirement Specification is typically produced by the contracting firm based on the URS, and is used for responding to the URS with a plan of action. It contains the full technical specification and serves as the contract between the customer and the contractor in this case. If on the other hand, URS is produced with help from the contractor, SRS is internal to the contractor. (Learn more in Software Requirement Specification (SRS))
Back to parent page: Software Requirement Engineering
SDLC SOFT3202 Requirement_Engineering Requirement_Elicitation Requirement_Analysis