System Requirements Phase. (See also Sommerville Section 6.3). 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.
(See also Sommerville Section 6.3)
Name Compute Insulin Dose: Safe sugar level
Description Computes the does of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units
Inputs Current 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.
Requires Two 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
PreCondition The insulin reservoir contains at least the maximum allowed single dose of insulin
PostCondition new r0 and r1 are replaced by old r1 and r2 respectively
Exception Patient 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)
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.
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.
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 shallbe 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 mayinclude other kinds of model, such as state machines, flow diagrams, business process analysis, abstract data type model, XML DTDs, tables, formal specifications, etc etc.
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.
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.
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 commentingstandards 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.
4 Traceability matrix. Give a table cross referencing software requirements to user requirements, show influence.