1. System Requirements Phase (See also Sommerville Section 6.3)

2. System Requirements Specification A URD is a user-centric description of a product to be developed. In the next phase of a waterfall lifecycle we need a developer-centric description of the product. This is the next phase of our project work.

3. System Requirements: What? SR is an expanded version of the UR SR add detail and explain how URs can be achieved from a developers perspective The language of SRs is often very technical, class diagrams, sequence diagrams, statecharts etc Can be used as part of the contract

4. System Requirements: How Ideally SRs should describe the black-box behaviour of the system in terms of its data model and/or API What – but not how (no design) For complex systems this is almost impossible: An initial architecture may be needed to structure discussion and presentation, explore possibilities External systems impose constraints along specific interfaces Non-functional requirements like performance may simply demand specific architectures.

5. How (continued) Natural language is the basis for reporting, however: – ambiguous “shoes must be worn”, “dogs must be carried” subjective meanings! – overflexible : when are two statements the same? – non-modular: no clear interfaces between text sections, difficult to trace impact of change.

6. UML We will use UML static notations to describe architecture and data models – Class diagrams – Package diagrams – Use case diagrams We will use UML dynamic models to describe functional behaviour and performance – Sequence diagrams – statecharts

7. Example:Form-Based Requirement NameCompute Insulin Dose: Safe sugar level DescriptionComputes the does of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units InputsCurrent sugar level (r2), the previous two readings (r1 and r0) Source Current sugar reading from sensor. Other readings from memory OutputsCompDose – the dose of insulin to be delivered Destination Main control loop ActionCompDose is zero if the sugar level is stable or falling, or if the level is increasing, but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result is rounded to zero then CompDose is set to the minimum dose that can be delivered. RequiresTwo previous readings so that the rate of change of sugar level can be computed. Readings must be taken at fixed regular time intervals of H hours PreConditionThe insulin reservoir contains at least the maximum allowed single dose of insulin PostConditionnew r0 and r1 are replaced by old r1 and r2 respectively ExceptionPatient has special medical condition then raise exception “manual intervention needed” Traceability URD version 1.2: Requirement CompDose and American Physicians Society Insulin Dosage recommendation version 9.1 (1996)

8. PSS-05 SRD Format (Section 1) SRD table of contents 1 Introduction. Similar to URD Section 1, but set in the context of this SRD report. 1.1 Purpose. See URD Section 1.1 1.2. Scope of the software. May be revised from URD Section 1.2 and updated in the light of feasibility study outcomes, project planning etc. Deviations from the URD (aka. RFCs) must be included and flagged. 1.3. Definitions, acronyms and abbreviations. May extend/delete information from URD Section 1.3. Deviations from the URD must be included and flagged. 1.4. References. May extend/delete information from URD Section 1.4. 1.5. Overview of the document. Similar to URD Section 1.5. but describes the SRD. It shall not be assumed that the reader is an end-user. It shall be assumed that the reader is a development team member.

9. PSS-05 SRD Format (Section 2) 2 General Description 2.1 Relation to current projects. Describes the relationship with other current projects (either customer side or developer side). Customer side could be outsourced component of a larger project. Developer side could be related to similar development work allowing synergies in work, software re-use, etc. 2.2 Relation to predecessor and successor projects. Describes the relationship with past and future projects (either customer side or developer side). Similar to 2.1 above. 2.3 Function and purpose. Describes the main functions the product must perform, gives an overview. (Details are set out in Section 3) Takes a developer-centric approach. 2.4 Environmental considerations. Describes where the product will be used (business environment and/or geographical location), who will use it (job roles, skill levels), who will operate and maintain it, hardware it will run on, operating system required.

10. PSS-05 SRD Format (Section 2 continued) 2.5 Relation to other systems. Describes related external systems and subsystems. (A revision of URD Section 2.1.) 2.6 General constraints. Describes the main constraints that apply and why they exist. (A revision of URD Section 2.3.) 2.7 Model description. Describes the logical or conceptual model using a recognized analysis method (including a data model). Description shall provide a top level or global description of the model. (Details can be presented in Section 3) This shall be precise: for example the results of an object-oriented analysis of the user requirements from the URD using UML, with data dictionary, role identification, use case analysis and object models/class diagrams. Description may include other kinds of model, such as state machines, flow diagrams, business process analysis, abstract data type model, XML DTDs, tables, formal specifications, etc etc.

11. PSS-05 SRD Format (Section 3) 3 Specific Requirements. Here we list specific requirements, classified by their attribute type. (Alternatively we can list by functional component type, and group around non-functional attributes of each functional component). This is a matter of taste. 3.1 Functional requirements. Each functional component and what it does. See previous template proposal above. 3.2 Performance requirements. Time, space, load, reliability aspects of relevant functional components. 3.3 Interface requirements. Proposal for global system interface, including GUI. Information organization, product workflow analysis, design philosophy, (may include prototype designs). 3.4 Operational requirements. Minimum levels of functionality and performance to be provided by external systems and subsystems (if any). 3.5 Resource requirements. Platform, OS, network, browser requirements, etc.

12. PSS-05 SRD Format (Section 3 continued) 3.6 Verification requirements. Plan and methods for internally verifying and validating the system against the SRD based on user evaluation, testing and if necessary formal verification. 3.7 Acceptance testing requirements. Plan and methods for externally verifying that the final system meets the end-user requirements as specified by the URD. 3.8 Documentation requirements. Proposal for a system documentation approach suitable for the job roles and skill levels identified for end users. 3.9 Security requirements. Requirements on data security, global access security, security of external system and overall environment. May include firewall and cryptology techniques, password protection, data encryption, underlying OS security etc.

13. PSS-05 SRD Format (Section 3 continued) 3.10 Portability requirements. Cross platform compatibility. 3.11 Quality requirements. Includes design quality, software quality, performance quality, report quality, documentation quality, usability quality. Plans and methods to impose quality. Standards for measurement and reporting. 3.12 Reliability requirements. Includes uptime, mean time to failure, accessibility, loading, average performance, worst case performance, etc. 3.13 Maintainability requirements. Standards for code documentation, maintenance handbooks, software commenting standards needed to maintain, repair and upgrade the code. 3.14 Safety requirements. Hazard situations, plans and methods to avoid system failure under hazard. Levels of safety assurance.

14. PSS-05 SRD Format (Section 3) 4 Traceability matrix. Give a table cross referencing software requirements to user requirements, show influence. UR-1UR-2UR-3UR-4… SR-1x SR-2x SR-3x SR-4x SR-5x SR-6x …