lec 8 - requirement engineering.pptx

Requirements Engineering Non-functional requirements classifications Non-functional classifications Product requirements – Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisati...

Requirements Engineering Non-functional requirements classifications 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 organisational 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. 1  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. 2  Goals and requirements Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal – A general intention of the user such as ease of use. Verifiable non-functional requirement – A statement using some measure that can be objectively tested. Goals are helpful to developers as they convey the intentions of the system users. 3  Usability requirements The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) 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. (Testable non-functional requirement) 4 Metrics for specifying nonfunctional requirements 5 Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation 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. 6  Requirements elicitation and analysis Sometimes called requirements elicitation or requirements discovery. 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. 7  Requirements elicitation Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include: – Requirements discovery, – Requirements classification and organization, – Requirements prioritization and negotiation, Requirements specification 8 Problems of requirements elicitation 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 may change. 9 The requirements elicitation and analysis process 10  Process activities Requirements discovery – Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation – Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation – Prioritising requirements and resolving requirements conflicts. Requirements specification – Requirements are documented and input into the next round of the spiral. 11  Requirements discovery The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. Interaction is with system stakeholders from managers to external regulators. Systems normally have a range of stakeholders. 12  Interviewing Formal or informal interviews with stakeholders are part of most RE processes. Types of interview – Closed interviews based on pre-determined list of questions – Open interviews where various issues are explored with stakeholders. Effective interviewing – Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders. – Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. 13  Interviews in practice Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Interviewers need to be open-minded without pre-conceived ideas of what the system should do You need to prompt the use to talk about the system by suggesting requirements rather than simply asking them what they want. 14  Problems with interviews Application specialists may use language to describe their work that isn’t easy for the requirements engineer to understand. Interviews are not good for understanding domain requirements – Requirements engineers cannot understand specific domain terminology; – Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating. 15  Stories and scenarios Scenarios and user stories are real-life examples of how a system can be used. Stories and scenarios are a description of how a system may be used for a particular task. Because they are based on a practical situation, stakeholders can relate to them and can comment on their situation with respect to the story. 16  Scenarios A structured form of user story Scenarios should include – A description of the starting situation; – A description of the normal flow of events; – A description of what can go wrong; – Information about other concurrent activities; – A description of the state when the scenario finishes. 17  Requirements and design In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable – A system architecture may be designed to structure the requirements; – The system may inter-operate with other systems that generate design requirements; – The use of a specific architecture to satisfy non-functional requirements may be a domain requirement. – This may be the consequence of a regulatory requirement. 18  Natural language specification Requirements are written as natural language sentences supplemented by diagrams and tables. Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers. 19 Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon. Include an explanation (rationale) of why a requirement is necessary. 20 Problems with natural language Lack of clarity – Precision is difficult without making the document difficult to read. Requirements confusion – Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation – Several different requirements may be expressed together. 21  Structured specifications An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements. 22  The software requirements document The software requirements document 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. 23 Requirements document variability Information in requirements document depends on type of system and the approach to development used. Systems developed incrementally will, typically, have less detail in the requirements document. Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems engineering projects. 24 The structure of a requirements document 25 26  Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage. 27  Review checks Verifiability – Is the requirement realistically testable? Comprehensibility – Is the requirement properly understood? Traceability – Is the origin of the requirement clearly stated? Adaptability – Can the requirement be changed without a large impact on other requirements? 28