Requirements Engineering
- 1. Lecture Four Requirements Engineering Assistant Lecturer Huda A. Alameen [email protected]
- 2. The requirements for a system are the descriptions of what the system should do the services that it provides and the constraints on its operation. These requirements reflect the needs of customers for a system that serves a certain purpose such as controlling a device, placing an order, or finding information. The process of finding out, analyzing, documenting and checking these services and constraints is called requirements engineering (RE). Introduction
- 3. Requirements engineering The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed.
- 4. Requirements may be defined: User requirements: System requirements:
- 5. Requirements definition/specification 1. Requirement definition: A statement in natural language plus diagrams of the services the system provides and its operational constrains. Written for customers(User requirements). 2. Requirement specification: A structured document setting out detailed descriptions of the system services, written as a contract between customer and contractor(System requirements). 3. Software specification: A detailed software description which can serve as a basis for a design or implementation. Written for developers.
- 6. Requirements Checking 1. Validity: Does the system provide the functions which best support the customer’s needs? 2. Consistency : Are there any requirements conflicts? 3. Completeness: Are all functions required by the customer included? 4. Realism: Can the requirements be implemented given the available budget and technology?
- 7. Techniques for Requirements Gathering 1. Interviews 2. Questionnaires 3. Observation 4. Document /procedures analysis 5. Prototyping
- 8. Functional and non-functional requirements Functional requirements: ▪ Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. ▪ May state what the system should not do. Non-functional requirements: ▪ Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. ▪ Often apply to the system as a whole rather than individual features or services. Domain requirements ▪ Constraints on the system from the domain of operation
- 9. Functional requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail.
- 10. Mentcare system: functional requirements A user shall be able to search the appointments lists for all clinics. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.
- 11. Non-functional requirements These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
- 12. Types of nonfunctional requirement
- 13. Non-functional requirements implementation Non-functional requirements may affect the overall architecture of a system rather than the individual components. ▪ For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. ▪ It may also generate requirements that restrict existing requirements.
- 14. Non-functional classifications Product requirements ▪ Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements ▪ Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements ▪ Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
- 15. Examples of nonfunctional requirements in the Mentcare system Product requirement The Mentcare system shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the Mentcare system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.
- 16. The software requirements document The software requirements document (sometimes called the software requirements specification or SRS) official statement of what the system developers should implement. It should include both the user requirements for a system and a detailed specification of the system requirements.
- 18. Requirements specification Requirements specification is the process of writing down the user and system requirements in a requirements document. the user and system requirements should be: 1.clear, 2.unambiguous, 3.easy to understand, 4.complete, 5.and consistent
- 19. Requirement Notes 1. The user requirements for a system should describe the functional and nonfunctional requirements. 2. The requirements document should not include details of the system architecture or design. 3. the system requirements should simply describe the external behavior of the system and its operational constraints. 4. User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document. 5. Graphical models are most useful when you need to show how a state changes or when you need to describe a sequence of actions.
- 20. Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements. However, there are a number of generic activities common to all processes ▪ Requirements elicitation; ▪ Requirements analysis; ▪ Requirements validation; ▪ Requirements management. In practice, RE is an iterative activity in which these processes are interleaved.