8 requirements engineering1
2 likes2,596 views
This document provides an overview of requirements engineering for software development. It defines requirements as descriptions of the services a system should provide and constraints under which it operates. Requirements can be functional, describing what a system should do, or non-functional, describing properties like performance or security. The document discusses best practices for writing requirements, including avoiding ambiguity and ensuring requirements are complete and consistent. It also describes the purpose and typical structure of a software requirements specification document.
8 requirements engineering1
- 1. MedTech Chapter 8 – Requirements Engineering (1) Definition, Functional and Non Functional Req, Documentation Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 1 MedTech – Mediterranean Institute of Technology CS321-Software Engineering MedTech
- 2. MedTech Requirements Engineering • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. • Requirements : • Descriptions of the system services and constraints that are generated during the requirements engineering process. • It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. • May serve a dual function • May be the basis for a bid for a contract - therefore must be open to interpretation; • May be the basis for the contract itself - therefore must be defined in detail; • Both these statements may be called requirements. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 2 Requirements Engineering
- 3. MedTech Requirements Abstraction If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system. Davis - 1993 Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 3 Requirements Engineering
- 4. MedTech Types of Requirements • User requirements • Statements in natural language plus diagrams of the services the system provides and its operational constraints. • Written for : • Client Managers, System end-users, Client engineers, Contractor Managers, System architects • System requirements • A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. • Defines what should be implemented so may be part of a contract between client and contractor. • Written for: • System end-users, Client engineers, System architects, Software Developers Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 4 Requirements Engineering
- 5. MedTech Types of Requirements : Example Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 5 Requirements Engineering 1. The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after 17.30 on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. User requirement definition System requirements specification
- 6. MedTech FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS Requirements Engineering Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 6
- 7. MedTech 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 • Derived from the application domain of the system rather than from the specific needs of the users • Can be missed by software engineers as they are proper to the business Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 7 Functional and Non-Functional Requirements
- 8. MedTech 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. • Examples: 1. A user shall be able to search the appointments lists for all clinics. 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. 3. Each staff member using the system shall be uniquely identified by his or her 8 -digit employee number. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 8 Functional Requirements
- 9. MedTech Requirements Imprecision • Problems arise when requirements are not precisely stated. • Ambiguous requirements may be interpreted in different ways by developers and users. • Developers may interpret the requirement in the way that simplifies its implementation • Consider the term ‘search’ in requirement 1 • User intention: search for a patient name across all appointments in all clinics; • Developer interpretation: search for a patient name in an individual clinic. User chooses clinic then search. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 9 Functional Requirements
- 10. MedTech Requirements Completeness and Consistency • In principle, requirements should be both complete and consistent. • Complete • They should include descriptions of all facilities required. • Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities. • In practice, it is impossible to produce a complete and consistent requirements document • Making these mistakes for complex systems is easy • Many stakeholders may have conflicting needs Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 10 Functional Requirements
- 11. MedTech Non-Functional Requirements • Define system properties and constraints • Properties: reliability, response time, storage requirements, etc. • Constraints: I/O device capability, system representations, etc. • Requirements that are not directly concerned with the specific services delivered by the system • Usually specify or constrain characteristics of the system as a whole • 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. • Example: if an aircraft system is not reliable, it will not be certified as safe for operation. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 11 Non-Functional Requirements
- 12. MedTech 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. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 12 Non-Functional Requirements
- 13. MedTech Types of Non-Functional Requirements Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 13 Non-Functional Requirements Performance requirements Space requirements Usability requirements Efficiency requirements Dependability requirements Security requirements Regulatory requirements Ethical requirements Legislative requirements Operational requirements Development requirements Environmental requirements Safety/security requirements Accounting requirements Product requirements Organizational requirements External requirements Non-functional requirements
- 14. MedTech Types of Non-Functional Requirements • Product requirements • Requirements which specify that the delivered product must behave in a particular way • Ex: Execution speed, reliability, etc. • Organisational requirements • Requirements which are a consequence of organisational policies and procedures • Ex: Process standards used, implementation requirements, etc. • External requirements • Requirements which arise from factors which are external to the system and its development process • Ex: Interoperability requirements, legislative requirements, etc. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 14 Non-Functional Requirements
- 15. MedTech Examples of Non-Functional Requirements • Product requirement The 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 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. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 15 Non-Functional Requirements
- 16. MedTech Expressing Non-Functional Requirements • Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. • Customers often propose them as general Goals • Ex: The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. • Problem: Goals leave scope for interpretation • Goals should be expressed as Verifiable non-functional requirements • A statement using some measure that can be objectively tested. • Ex: Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. • Use (if possible) quantifiable metrics. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 16 Non-Functional Requirements
- 17. MedTech Metrics for Non-Functional Requirements Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 17 Non-Functional Requirements Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems
- 18. MedTech Domain Requirements • The system’s operational domain imposes requirements on the system. • For example, a train control system has to take into account the braking characteristics in different weather conditions. • Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. • If domain requirements are not satisfied, the system may be unworkable. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 18 Domain Requirements
- 19. MedTech Domain Requirements Problems • Understandability • Requirements are expressed in the language of the application domain; • This is often not understood by software engineers developing the system. • Implicitness • Domain specialists understand the area so well that they do not think of making the domain requirements explicit. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 19 Domain Requirements
- 20. MedTech SOFTWARE REQUIREMENTS DOCUMENT Requirements Engineering Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 20
- 21. MedTech Software Requirements Document • The software requirements document (or Software Requirements Specification SRS) is the official statement of what is required of the system developers. • Should include both a definition of user requirements and a specification of the system requirements. • It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 21 Software Requirements Document
- 22. MedTech SRS and Agile Methods • Many agile methods argue that producing a requirements document is a waste of time as requirements change so quickly. • The document is therefore always out of date. • Methods such as XP use incremental requirements engineering and express requirements as ‘user stories’ • This is practical for business systems but problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems developed by several teams. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 22 Software Requirements Document
- 23. MedTech Users of the SRS Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 23 Software Requirements Document Use the requirements to develop validation tests for the system. Use the requirements document to plan a bid for the system and to plan the system development process. Use the requirements to understand what system is to be developed. System test engineers Managers System engineers Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. System customers Use the requirements to understand the system and the relationships between its parts. System maintenance engineers
- 24. MedTech SRS Variability • Information in requirements document depends on type of system and the approach to development used. • SRS should be detailed for: • Critical systems: safety and security should be analyzed in details • Outsourced systems: a separate company is developing the system • Systems developed in-house and incrementally will, typically, have less details in the requirements document. • Ambiguities can be resolved during development • Requirements documents standards have been designed • Ex: IEEE standard. • Mostly applicable to the requirements for large systems engineering projects. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 24 Software Requirements Document
- 25. MedTech SRS Standard Example: IEEE 1998 Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 25 Software Requirements Document Chapter Description Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements definition Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.
- 26. MedTech SRS Standard Example: IEEE 1998 Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 26 Software Requirements Document Chapter Description System requirements specification This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System models This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.
- 27. MedTech References Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 27 • Ian Sommerville, Software Engineering, 9 th Edition, Addison-Wesley 2009 • Robert Japenga, How to write a software requirements specification