Chapter 5 Requirements Engineering Process

1. Chapter 5Requirements Engineering Process Chapter 7 in textbook

2. Objectives • Understand the requirements engineering process • Understand how to discover requirements • Understand how to validate requirements • Understand how to manage requirements

3. Overview • The requirements engineering process. • Feasibility study • Requirements elicitation • Requirements specification • Requirements validation • Requirements management

4. Requirements Engineering Process • “The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.” • The result is a specification :“representing the requirements in a manner that ultimately leads to successful software implementation.

5. Requirements engineering • Requirements engineering is important • Engineering is about finding solutions and a good solution is one that solves the problem • Errors cost more the longer the go undetected • Failure to understand requirements is the biggest single cause of cost and schedule overruns • Four main processes • Feasibility Study  Feasibility Report • Requirements elicitation  System Models • Requirements Specification  user and system requirements • Requirements validation  Requirements document • Requirements Management

6. Requirements Engineering Process

7. The feasibility study • A feasibility study decides whether or not the proposed system is worthwhile. • A short focused study that checks • If the system contributes to organisational objectives; • If the system can be engineered using current technology and within budget; • If the system can be integrated with other systems that are used.

8. Requirements Elicitation • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

9. Requirements discovery • Sources of information • Documentation • System stakeholders • Interviews • Observation (ethnography) • Specifications of similar systems

10. Stakeholders for LIBSYS • Library manager • Article providers • Students • Staff

11. Problems • Stakeholders don’t know what they really want. • Stakeholders express requirements in their own terms. • Different stakeholders may have conflicting requirements. • Organisational and political factors may influence the system requirements. • The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

12. Analysis : System models • Why? • The model aids the analyst in understanding the system, thereby makes the requirements analysis easier and more systematic. • The model becomes the focal point of review. • The model becomes foundation for design. • Produced during requirements analysis. • More on modeling in chapter 6.

13. Requirements specification • It is the final work product produced by the requirements engineer. • It serves as a foundation for the software design and implementation. • The SRS document described in chapter 4

14. Requirements Validation • The process of ensuring that the requirements actually define the system that the customer wants. • Why is it important? • The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors.

15. Validation checks • Validity checks • Is this what the user wants? • Consistency checks • Requirements should not conflict • Completeness checks • Requirements should define all functions and constraints • Realism checks • Ensure they could be implemented • Verifiability • Requirements should be written so that they are verifiable, you should be able to write tests for each requirement.

16. Validation techniques • Requirements reviews • A team of reviewers manually check the requirements. • Prototyping • An executable model of the system is demonstrated and to customers. • Test-case generation • Requirements should be testable. If tests are difficult or impossible to design, this means that the requirements will be difficult to implement. • Developing tests before any code is written is used in ----?

17. Requirements Management • Why? • Requirements for large software systems are always changing. Because the problem can not be fully specified, the requirements are usually incomplete and bound to change. • During the software process the stakeholders understanding of the problem is constantly changing • After the system is installed, new requirements will emerge. • What? • It is the process of understanding and controlling changes to system requirements.

18. Requirements Management Planning • Requirements identification • Each requirement must be uniquely identified • A change management process • Assess the impact and cost of change • Traceability policies • Define the relationship between requirements • CASE tool support

19. Assignment 3 • Check the weblog for assignment 3