Practical Software Engineering Session 4

1. Practical Software EngineeringSession 4 Requirements Engineering

2. Recap • SE ≈ Software process + management • Software processes • Plan-driven process vs Agile development • Software process models • Linear (waterfall), incremental development (iterative), integration and configuration (reuse) • Fundamental development activities (specification, development, validation, maintenance)

3. This session (requirements) • What are requirements • How to obtain requirements • Requirement engineering processes • Requirement elicitation, specification, and validation • How to write requirements • How to validate requirements

4. Requirements • Requirements are the descriptions of the system services and constraints. • In SE, a requirement isadescription of: • A unit of functionality a system should offer • A constraint on a system’s operation • A quality attribute of a system • A performance attribute of a system • Requirements serve as a basis for: • An agreement between customer and supplier as to what a software product should do • A basis for estimates of cost and schedule • A basis for system design • A basis for system validation and verification

5. Example Requirements Functionality The Mentcare system shall red flag any patient who has missed an appointment without prior notice. Constraint The Mentcare system shall implement patient privacy provisions as set out in Hstan-03-2006-priv. Quality The system shall only allow access to authorised users. Performance The system should support 100 simultaneous service requests, consisting of data entry, data update, data deletion and report generation.

6. Different levels: User and System Requirements • User requirements are high level descriptions of system features and functionality (in natural language) • provide an initial understanding of a system • are not concerned with how a system will be implemented. • System Requirementsare detaileddescriptions of system functionality, features and constraints (from a technical perspective) • They are directly concerned with how a system will be implemented. • They provide the basis for later technical work and for detailed contracts.

7. Readers of requirements specification

8. Stakeholders • Any person or organisation 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 • Mentcare system • Patients, doctors, nurses, medical receptionists, IT staff, medical ethics managers, healthcare managers, medical records staff

9. Agile Methods and Requirements • Proponents of agile methods argue that • producing a detailed system requirements specification is a waste of resources, as requirements change quickly. • Instead of a detailed and complete requirements specification • agile methods work on a just enough basis, where requirements are developed increment-by-increment. • Requirements in agile methods are often specified as user stories or as use cases.

10. Functional and non-functional requirements

11. Functional and Non-functional (System) Requirements • Functional requirements • The individual services the system should carry out. • How the system should react to particular inputs • How the system should behave in particular situations. • Non-functional requirements • constraints on the services or functions offered by the system • e.g. legal and ethical constraints, performance constraints, operational constraints, … • Often apply to the system as a whole rather than individual features/ services. • Domain requirements • Constraints on the system from the domain of operation

12. Functional Requirements • Functional requirements • specify operations that software must accomplish. • This can include • creating, updating and deleting records, • searching and viewing data, allowing access to data, transmitting data, • performing calculations • Functional requirements: users and systems • refer to operations which are carried out by a user, or • operations which a system carries out automatically in response to state changes or triggers.

13. Functional Requirements (examples) • Functional requirements for the Mentcare System. 1.3 A user shall be able to search the appointments lists for all clinics. 1.4 The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments. 1.5 Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

14. Requirement imprecision • Problems arise when functional requirements are not precisely stated. • Ambiguous requirements may be interpreted in different ways by developers and users. • Consider the term ‘search’ in requirement 1.3 • A user shall be able to search the appointments lists for all clinics • 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.

15. Non-functional Requirements • Non-functional requirements are requirements which are not directly concerned with the individual operations of a system. • They specify constraints on the operation or required characteristics of a system • system properties: reliability, response time and storage requirements • System constraints: I/O device capability, data representations (in interfaces) • Non-functional requirements are often more critical than individual functional requirements • they affect the entire system rather than just small parts of it. • For example if reliability or security requirements are not met, an entire system may be rendered as unfit-for-purpose.

16. Non-functional Requirements • Non-functional requirements fall into three broad categories: • Product requirements • Specify how the product should behave (e.g. execution speed, reliability, etc.). • Organisational requirements • Specify constraints which result from organisational policies and procedures • e.g. process standards used, implementation requirements, etc. • External requirements • Specify constraints which result from factors which are external to the system and its development process • e.g. interoperability requirements, standards conformance, legislative requirements, etc.

17. Non-functional Requirements

18. Non-functional Requirements (example) Non-functional requirements for the Mentcare System. • Product requirement The Mentcare system shall be available to all clinics during normal working hours (Mon–Fri, 08.30 – 17.30). Downtime within normal working hours shall not exceed five seconds in any one day. • Organisational 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.

19. Non-functional Requirements --- issues • A common problem with non-functional requirements is that stakeholders frame them as general goals, which are difficult or impossible to measure. The Mentcare system shall be user-friendly. • Non-functional requirements must be verifiable. They must, therefore, be framed in terms of verifiable metrics. Mentcare staff shall be able to use all system functions after two hours training. After this training, the average number of errors made per hour should be <= 2.

20. Metrics for specifying nonfunctional requirements

21. Requirements Engineering Processes • The process of establishing (1) the services that a customer requires from a system and (2) the constraints under which it operates and is developed. • Requirements engineering involves three key activities: • Requirements elicitation • Requirements specification • Requirements validation • Requirements engineering is generally an iterative process in which the three key activities are interleaved.

22. Requirements elicitation • Requirements specification • Requirements validation

23. Requirements Elicitation • Requirements elicitation is essentially a dialogue between developers, users and other system stakeholders (e.g. managers, unions, domain experts, etc.) • Requirements elicitation has three stages: • Discovery and understanding • Classification and organisation • Prioritisation and negotiation (e.g. MoSCoW)

24. Requirements elicitation activities • Requirements discovery • Interacting with stakeholders to discover their requirements. • Domain requirements are also discovered at this stage. • Requirements classification and organisation • Group related requirements and organises them into coherent clusters. • Requirements prioritisation and negotiation • Prioritising requirements and resolving requirements conflicts. [Specification: Requirements are documented and input into the next round of the spiral]

25. Requirements elicitation techniques • Requirements elicitation techniques include: • Interviewing • Closed interviews based on pre-determined list of questions. • Open interviews (conversations), where system related issues are informally explored with stakeholders. • Ethnography • Observation of operational aspects of a system, work-practices, values and cultures. • Stories and scenarios • Descriptions of how a system is used for particular tasks (e.g. user stories) • As we have discussed in the previous lecture

26. Focused ethnography • Developed in a project studying the air traffic control process • Combines ethnography with prototyping • Prototype development results in unanswered questions which focus the ethnographic analysis. • The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant.

27. Requirements elicitation: challenges • Requirements elicitation presents some notable challenges: • Stakeholders do not always know exactly what they want • Stakeholders express requirements in idiosyncratic and/or domain specific terms • Different stakeholders may have conflicting requirements • Organisational and political factors may influence the system requirements • Requirements invariably change during the analysis process. New stakeholders may emerge and the business environment may change

28. Requirements elicitation • Requirements specification • Requirements validation

29. Requirement specification • The process of writing down the user and system requirements in a requirements document. • User requirements have to be understandable by end-users and customers who do not have a technical background. • System requirements are more detailed requirements and may include more technical information. • The requirements may be part of a contract for system development • It is therefore important that these are as complete as possible.

30. Ways of writing requirement specification • Requirements can be specified in a range of formats.

31. Requirements Specification • Natural Language. 3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) 3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.) • More suitable for user requirements.

32. Natural languages (remarks) • Pros: • expressive, intuitive, and universal • Cons: • Vague, lack of clarity • ambiguous • Requirements confusion • Mix up func. and non-func. req • Requirements amalgamation • 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.

33. Example requirements for the insulin pump software system

34. Structured Specification • An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. • More suitable for system requirements.

35. Tabular specification • Used to supplement natural language. • Particularly useful when you have to define a number of possible alternative courses of action. • For example, the insulin pump systems bases its computations on the rate of change of blood sugar level

36. Use cases • Use-cases are a kind of scenario that are included in the UML. • Use cases identify the actors in an interaction and which describe the interaction itself. • A set of use cases should describe all possible interactions with the system. • High-level graphical model supplemented by more detailed tabular description • UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

37. 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. • Focus on WHAT the system should do rather than HOW it should do it.

38. The structure of a requirements document (1)

39. The structure of a requirements document (2)

40. Writing Requirements • A well-written requirement should have the following attributes:

41. Requirements elicitation • Requirements specification • Requirements validation

42. Requirements Validation • Requirements validation is concerned with demonstrating that the requirements specification correctly defines the required system. • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. • It involves rigorous checking to determine: • Validity. Does the requirements provide the functions which best support the customer’s needs? • Consistency. Are there any requirements conflicts? • Completeness. Are all functions required by the customer included? • Feasibility. Can the requirements be implemented given available budget and technology? • Verifiability. Can the requirements be tested?

43. Requirements Validation • Requirements validation techniques include: • Requirements reviews • Systematic manual analysis of the requirements. • Prototyping • Using an executable model of the system to check requirements. • Test-case generation • Developing tests for requirements to check testability. • 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?

44. Requirements Change • The business and technical environment of the system always changes after installation. • New hardware may be introduced • It may be necessary to interface with other systems • Business priorities may change • New legislation and regulations may be introduced that constrain the system and its use • Changes to requirements must be expected and must be systematically managed.

45. Requirements Management • Requirements management is the process of managing changing requirements during and after system deployment. • It involves keeping track of individual requirements and maintaining links between dependent requirements • so that the impact of requirements changes can be determined. • Requirements management involves structured, formal processes for making change proposals and linking these to system requirements.

46. Portfolio Task… • You are required to complete a detailed requirements specification document for the Patient Information System for Mental Health Care based on the case study information and the stakeholder interviews provided

47. Class activities … • Wilderness Weather Station Requirements