Software Requirements: ©ian Sommerville 2006 Slide 1
Software Requirements: ©ian Sommerville 2006 Slide 1
Software Requirements: ©ian Sommerville 2006 Slide 1
“If a comp any w ishes to le t a cont ract for a la rge software deve lopmen t project, it
must define its need s in a suffi cien tly ab stract way that a solution is no t pre-defined.
The requi remen ts must be written so that several cont ractors can b id for the con tract,
offering, pe rhap s, different ways of me eting the c lien t organi sation ’s need s. Once a
contract has been a warded, the cont ractor must write a system definition for the client
in more detail so that the c lient und erstand s and c an val idate what th e software will
do. Both o f these docu ment s may be ca lled the requirements document for the
system. ”
Functional requirements
• Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
Non-functional requirements
• constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
Domain requirements
• Requirements that come from the application domain of the
system and that reflect characteristics of that domain.
Effi ciency Relia bilit y Porta bilit y Inter oper a bilit y Et hi cal
requi r ements requi r ements requi r ements requi r ements requi r ements
Usa bilit y Deli very Impl ementa tion Standar ds Leg islative
requi r ements requi r ements requi r ements requi r ements requi r ements
A system goal
• The system should be easy to use by experienced controllers
and should be organised in such a way that user errors are
minimised.
A verifiable non-functional requirement
• Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this training,
the average number of errors made by experienced users shall
not exceed two per day.
Understandability
• Requirements are expressed in the language of the
application domain;
• This is often not understood by software engineers
developing the system.
Implicitness
• Domain specialists understand the area so well that
they do not think of making the domain requirements
explicit.
Lack of clarity
• Precision is difficult without making the document
difficult to read.
Requirements confusion
• Functional and non-functional requirements tend to
be mixed-up.
Requirements amalgamation
• Several different requirements may be expressed
together.
Ambiguity
• The readers and writers of the requirement must
interpret the same words in the same way. NL is
naturally ambiguous so this is very difficult.
Over-flexibility
• The same thing may be said in a number of different
ways in the specification.
Lack of modularisation
• NL structures are inadequate to structure system
requirements.
Notation Description
Structured natural This approach depends on defi ning standard forms or templates to exp ress the
language requirements specifi cation.
Design This approach uses a la nguage li ke a programmi ng langu age but with more abstract
description features to specif y the requir ements by defining an op erationa l m odel of the system.
language s This approach is not now widely used alt hough it can be us eful for interface
specification s.
Graphical A graph ic al languag e, supp lemented by text anno tations is used to defi ne the
notations func tiona l requir ements for the system. An early exa mple of such a graphical
language was SADT. Now, use-case descriptions and sequence d iagrams are
comm only u sed .
Mathematical These are no tations based on mathematical concep ts such as finit e-state machines or
specification s sets. These una mbiguous specifications reduce the argu ments between customer and
contractor about system func tiona lit y. Howeve r, most cus tomers don’t unde rstand
formal specifications and a re reluctant to accept it as a system contract.
Condition Action
Sugar le vel falling (r2 < r1) CompDose = 0
Sugar le vel stable (r2 = r1) CompDose = 0
Sugar le vel increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0))
Sugar le vel increasing and rate of CompDose = round ((r2-r1)/4)
increase stable or increasing. ((r2-r1) • If rounded result = 0 then
(r1-r0)) CompDose = MinimumD ose
Card
Card nu mber
Card OK
PIN request
PIN
Option menu Validate card
<<exception>>
invalid card
<<exception>>
Debit respo nse
insufficient cas h
Card
Card removed
Complete
Cash transaction
Cash removed
Receipt
interface PrintServer {
Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index