Reconfigurable computing
Small Embedded Systems
Unit 6.4
Requirements Analysis and Specification
Introduction
Requirements
Specification
System design process
Requirements
Detailed descriptions of what a customer wants
Documented as numbered lists
They can be refined, for example.
R5 The system should measure acceleration
R5.1 The maximum acceleration is 10g
Two types of requirements:
Functional requirements: What the design must do.
Non-functional requirements: Other required attributes, e.g. cost, weight, reliability, power consumption
Requirements Should Be …
Correct
Free from error
Unambiguous
Capable of only one reasonable interpretation
Complete
Nothing that matters should be missing
Verifiable
There is an objective and cost effective way to tell whether or not requirement is met
Requirements Should Be …
Consistent
One requirement should not contradict another requirement
Modifiable
Structured in a way such that modifying one requirement doesn’t present serious risk of generating inconsistencies with others
Traceable
Should be able to trace back from requirement document to know why each requirement is there
Should be able to trace forward to final implementation to see how each requirement is met
The Importance of Requirements
In 1999 the Mars Climate Orbiter, an unmanned US spacecraft, disintegrated because it got too close to Mars
The embedded system designers had not specified the units for force and assumed units of Newtons
The software company assumed units of pound-force
https://solarsystem.nasa.gov/missions/mars-climate-orbiter/in-depth/
The Importance of Requirements
Mariner 1 Venus probe: 1962
The most expensive overbar in history
(~$135 million in today’s money)
Onboard guidance system had error due to faulty spec
Technical Specification said compensate for changes in (time derivative of radius)
It should have said (time averaged value of time derivative of radius)
Normal vibrations were confused with being off course
Erratic over-compensation by rocket
5 minutes into mission, self destruct instruction had to be issued
https://solarsystem.nasa.gov/missions/mars-climate-orbiter/in-depth/
Mandatory Requirements
Specify the necessary and sufficient conditions that a minimal system must have in order to be acceptable
Must be passed or failed, there is no middle ground. They usually contain the word ‘must’
e.g “The bridge must reach all the way across the river”
95%
100%
Preference Requirements
State the conditions that would make the customer happier
Should use scoring functions to evaluate figures of merit
Should be evaluated, and trade-offs made in terms of technical and economic feasibility
e.g. the height difference on transitioning from road to bridge should be small enough to ensure driver comfort
Specification
A detailed description of what should be constructed.
This should be based on the requirements.
Every requirement should be addressed and referenced in the specification.
For example:
S4 The system should use a CXL04LP1Z accelerometer (R5.1)
Architecture Design
Requirements/specification and testing are normally done for the integrated system as a whole
Architecture needs to consider system partition into hardware and software
Hardware and software are normally designed separately
requirements and
specification
architecture
hardware design
software design
integration
testing
Design Flows
A design flow shows the major steps to be taken and how they are sequenced
Software Development Life Cycle
Some famous examples are:
Waterfall model
Successive refinement
Spiral model
Waterfall Diagram
Top-down approach
Defines 5 major phases of design:
Views them as largely sequential:
once a phase is finished we don’t revisit it (much)
This approach is generally regarded as unrealistic
Successive Refinement
System is built several times
Early versions are prototypes, and may not be fully completed
Spiral Model
Several versions of the system are built
Requirements-Design-Test stages performed for each
Early version are mock-ups with not much detail
(hence the narrow top of the spiral)
As design progresses more is found out about problems and gaps in the requirements, and more functionality will be included
Summary
Requirements characterise what customer wants
Specifications characterise what will be built
Software development life cycle (SDLC)
/docProps/thumbnail.jpeg