Chapter 4: Software Requirements Elicitation
Verification
- Are we building the product right? - In the right way Concerns the product building process
Challenges of Requirements Elicitation
- Software development = wicked problem - Communication barrier b/t the team and the customer/users - importance of requirements elicitation are often underestimated - requirements change throughout the lifecycle
Validation
Are we building the right product? - the product the customer wants? concerns the correctness of the product being built
Types of requirements
- Functional requirements - Nonfunctional requirements
Requirements
- capabilities that the system must deliver - documented in a requirements specification, which serves as part of the contract - Requirements elicitation is the process to identify and formulate the capabilities for the software system
How the planning phase helps customers
- helps them identify the needs for their business - help them determine the real requirements for the future system - help them prioritize the requirements
Requirements Elicitation Activities
- identifying problems and needs - constructing analysis models to help understanding - formulating system/software requirements - conducting feasibility study - checking the requirements and models for desired properties such as correctness and consistency - specifying acceptance tests - formulating an iterative development plan
Why are requirements elicitation important?
- legally liable to deliver - 37% of all software development problems are related to requirements - poorly identified requirements significantly increase the development costs
nonfunctional requirements
- performance requirements - quality requirements - safety requirements - security requirements - interface requirements
Steps of Requirements Elicitation
1. collect information about the application 2. Constructing analysis models, if desired 3. Deriving requirements and constraints 4. Conducting feasibility study 5. Reviewing the requirements specification
Techniques of technical review
1. peer review - peers are guided by a review questionnaire 2. walkthrough- the analyst explains each requirement while the reviewers examine it and raise doubts 3. Inspection - inspector is guided by a checklist of commonly encountered problems in SRS
The planning phase
1. requirements elicitation 2. deriving use cases from the requirements 3. producing an iterative development plan
feasibility study
aims at determining if the project is doable under the given constraints - feasibility of the functional, performance, nonfunctional, and quality constraints - adequacy of the technology - timing and cost constraints - constraints imposed byt eh customer, industry and government agencies
Technical review
an internal review performed but eh technical team
Customer/user reviews
performed by involving the customer and/or users of the system
Expert Review
review of the requirements specification by domain experts
Functional Requirements
statements of information processing capabilities that the software system must process
Goal of constructing analysis models
to aid understanding of the application, requirements, and constraints
Aim of software requirement elicitation
to identify the real requirements for the system
