Chapter 5 Requirements Engineering Process Chapter 7 in

Chapter 5 Requirements Engineering Process Chapter 7 in textbook 1

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

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

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

Requirements engineering o Requirements engineering is important n n n o Four main processes n n o 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 Feasibility Study Feasibility Report Requirements elicitation System Models Requirements Specification user and system requirements Requirements validation Requirements document Requirements Management 5

Requirements Engineering Process 6

The feasibility study o o A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks n n n 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. 7

Requirements Elicitation o o 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. 8

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

Stakeholders for LIBSYS o o Library manager Article providers Students Staff 10

Problems o o o 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. 11

Analysis : System models o Why? n n n o o 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. 12

Requirements specification o o o 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 13

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

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

Validation techniques o Requirements reviews n o Prototyping n o A team of reviewers manually check the requirements. An executable model of the system is demonstrated and to customers. Test-case generation n n 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 ----? 16

Requirements Management o Why? n n n o 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? n It is the process of understanding and controlling changes to system requirements. 17

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

Assignment 3 o Check the weblog for assignment 3 19