Transcript 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. •

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.
• This is the next phase of our project work.
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
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.
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.
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
Example:Form-Based Requirement
Name
Compute 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
Inputs
Current sugar level (r2), the previous two readings (r1 and r0)
Source
Current sugar reading from sensor. Other readings from memory
Outputs
CompDose – the dose of insulin to be delivered
Destination Main control loop
Action
CompDose 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)
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.
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.
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.
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.
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.
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.
PSS-05 SRD Format (Section 3)
4 Traceability matrix. Give a table cross
referencing software requirements to user
requirements, show influence.
UR-1
UR-2
SR-1
x
SR-2
x
SR-3
UR-3
UR-4
x
SR-4
x
SR-5
x
SR-6
…
x
…