SOFTWARE ENGINEERING (CO3001) Chapter 4 – Requirements Engineering WEEK 4, 5 Jan 2018 Chapter 3. Requirements engineering 2 Topics covered • Functional and non-functional requirements • Requirements engineering processes • Requirements elicitation • Requirements specification • Requirements validation • Requirements change Jan 2018 Chapter 3. Requirements engineering 3 REQUIREMENTS Jan 2018 Chapter 3. Requirements engineering 4 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 engineering 5 Requirement engineering = What is a requirement? establishing the services that the customer requires from a system and the constraints under which it operates and is developed. • Requirement = the descriptions of • the system services • and constraints • It may range • from a high-level abstract statement • to a detailed mathematical functional specification. • May serve a dual function • The basis for a bid for a contract - must be open to interpretation; • The basis for the contract itself - must be in detail; Jan 2018 Chapter 3. Requirements engineering 6 Types of requirement • User requirements • Written for customers.
• statements in natural language + diagrams of the services the system provides and its operational constraints. • System requirements • (For) developers/contractor • detailed descriptions of the system’s functions, services and operational constraints Jan 2018 Chapter 3. Requirements engineering 7 User and system requirements example User requirements definition 1. The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.
System requirements specification 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.2 The system shall generate the report for printing after 17.30 on the last working day of the month.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.4 If drugs are available in different dose units (e. 10mg, 20mg, etc) separate reports shall be created for each dose unit.5 Access to drug cost reports shall be restricted to authorized users as listed on a management access control list. Requirements engineering 8 Readers of different types of requirements specification Client managers System end-users User Client engineers requirements Contractor managers System architects System end-users System Client engineers requirements System architects Software developers Jan 2018 Chapter 3. Requirements engineering 9 System stakeholders • Any person or organization who is affected by the system in some way and so who has a legitimate interest • Stakeholder types • End users • System managers • System owners • External stakeholders Jan 2018 Chapter 3.
Requirements engineering 10 Stakeholders in the Mentcare system Stakeholder Why? - Role Patients whose information is recorded in the system Doctors responsible for assessing and treating patients Nurses coordinate the consultations with doctors and administer some treatments Medical manage patients’ appointments receptionists IT staff responsible for installing and maintaining the system Medical ethics ensure that the system meets current ethical guidelines for manager patient care Health care obtain management information from the system managers Medical responsible for ensuring that system information can be records staff maintained and preserved, and that record keeping procedures have been properly implemented. Requirements engineering 11 Agile methods and requirements • Many agile methods argue that producing detailed system requirements is a waste of time as requirements change so quickly. • The requirements document is therefore always out of date. • Agile methods usually use incremental requirements engineering and may express requirements as ‘user stories’ • This is practical for business systems but problematic for systems that require pre-delivery analysis (e.
critical systems) or systems developed by several teams. Requirements engineering 12 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS Jan 2018 Chapter 3. Requirements engineering 13 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 Jan 2018 Chapter 3. Requirements engineering 14 Functional requirements • Describe functionality or system services.
• Functional user requirements may be high-level statements of what the system should do. • Functional system requirements should describe the system services in detail. Requirements engineering 15 Mentcare system: functional requirements 1. 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. Requirements engineering 16 Requirements imprecision • Problems arise when requirements are not precisely stated. • Ambiguous requirements may be interpreted in different ways by developers and users.
• For 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. Requirements engineering 17 Requirements completeness and consistency • 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. Requirements engineering 18 Non-functional requirements • Define system properties and constraints • Properties: reliability, response time and storage requirements. • Constraints: I/O device capability, system representations, etc. • Non-functional requirements may be more critical than functional requirements.
• If these are not met, the system may be useless. Requirements engineering 19 Non-functional requirements implementation • Non-functional requirements may affect the overall architecture of a system • rather than the individual components. • A single non-functional requirement • may generate a number of related functional requirements • and may also generate requirements that restrict existing requirements. Requirements engineering 20 Types of nonfunctional requirement Non-functional requirements Product Organizational External requirements requirements requirements Efficiency Dependability Security Regulatory Ethical requirements requirements requirements requirements requirements Usability Environmental Operational Development Legislative requirements requirements requirements requirements requirements Performance Space Accounting Safety/security requirements requirements requirements requirements Jan 2018 Chapter 3.
Requirements engineering 21 Non-functional classifications • Product requirements • Requirements which specify that the delivered product must behave in a particular way e. execution speed, reliability, etc. • Organisational requirements • Requirements which are a consequence of organisational policies and procedures e. process standards used, implementation requirements, etc.
• External requirements • Requirements which arise from factors which are external to the system and its development process e. interoperability requirements, legislative requirements, etc.vn/Uploaded/file/CV%20HD%20huong%20dan%20YC%20phi%20chu c%20nang-130129.doc Jan 2018 Chapter 3. Requirements engineering 22 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. 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. Requirements engineering 23 Goals vs. requirements • Goal • A general intention of the user such as ease of use.
• Testable non-functional requirement • A statement using some measure that can be objectively tested. Requirements engineering 24 Goals vs.) Goal: The system should be easy to use by medical staff. Non-functional requirement: Medical staff shall be able to use all the system functions after four hours of training. Requirements engineering 25 Metrics for specifying nonfunctional 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 … Jan 2018 Chapter 3.
Requirements engineering 26 REQUIREMENTS ENGINEERING PROCESSES Week 5 Jan 2018 Chapter 3. Requirements engineering 27 Requirements engineering processes • Processes to “generate” all requirements • Generic activities common to all processes • Requirements elicitation; • Requirements analysis; • Requirements validation; • Requirements management. • In practice, RE is an iterative activity Jan 2018 Chapter 3. Requirements engineering 28 A spiral view of the requirements engineering process Requirements specification System requirements specification and modeling User requirements specification Business requirements specification Start Feasibility System study Requirements req.
Requirements elicitation elicitation User validation requirements elicitation Prototyping Reviews System requirements document Jan 2018 Chapter 3. Requirements engineering 29 REQUIREMENT ELICITATION AND ANALYSIS Jan 2018 Chapter 3. Requirements engineering 30 Requirements elicitation and analysis • ~ requirements elicitation or requirements discovery. • Work with customers to find out: • the application domain, the services and the operational constraints (system performance, hardware constraints, etc.
• May involve • end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Requirements engineering 31 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 change.
Requirements engineering 32 The requirements elicitation and analysis process Interacting with stakeholders to Requirements are discover their documented and input requirements. into the next round Groups related requirements and organises Prioritising them into requirements and coherent resolving conflicts clusters Jan 2018 Chapter 3. Requirements engineering 33 Requirements discovery • To gather information about the required and existing systems and distil the user and system requirements from this information. • Main concerns: • Stakeholders • Discovery techniques/approaches/… Jan 2018 Chapter 3.
Requirements engineering 34 Discovery technique - Interviewing • Part of most RE processes. • Types of interview • Closed vs Open => mixed? • Be effective • 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. Requirements engineering 35 Discovery technique - Ethnography • Observational technique • used to understand operational processes and help derive support requirements for these processes • How • A social scientist spends a considerable time observing and analysing how people actually work.
• People do not have to explain or articulate their work. • Social and organisational factors of importance may be observed. Requirements engineering 36 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. Requirements engineering 37 Ex: Photo sharing in the classroom (iLearn) • Jack is a primary school teacher in Ullapool (a village in northern Scotland). He has decided that a class project should be focused around the fishing industry in the area, looking at the history, development and economic impact of fishing. As part of this, pupils are asked to gather and share reminiscences from relatives, use newspaper archives and collect old photographs related to fishing and fishing communities in the area.
Pupils use an iLearn wiki to gather together fishing stories and SCRAN (a history resources site) to access newspaper archives and photographs.