Beruflich Dokumente
Kultur Dokumente
o .t c
sp
lo g
a. b
Software Requirements
at r
ik p
/ an
t p:/
ht Copyright C 2011 Anik Patra 1
o m
Topics covered
o .t c
• Functional and non-functional
sp
requirements
l o g
• User requirements
a. b
t
• System requirements
a r
p
• Interface specification
ik
n
• The software requirements document
:// a
t t p
h Copyright C 2011 Anik Patra 2
Requirements engineeringco
m
o t .
sp
• The process of establishing the services
a . b which it
r
operates and is developed.
• The requirements tthemselves are the
a
descriptions ofpthe system services and
k
constraintsithat
n
a
are generated during the
://
requirements engineering process.
t t p
h Copyright C 2011 Anik Patra 3
What is a requirement? co
m
o t .
sp
• It may range from a high-level abstract statement of a
g
service or of a system constraint to a detailed
l o
mathematical functional specification.
. b
• This is inevitable as requirements may serve a dual
a
function
t r
– May be the basis for a bid for a contract - therefore
a
must be open to interpretation;
ik p
– May be the basis for the contract itself - therefore
n
must be defined in detail;
/ a
– Both these statements may be called requirements.
:/
t tp
h Copyright C 2011 Anik Patra 4
Types of requirement
o m
o .t c
p diagrams
• User requirements
– Statements in natural language s
g
plus
l o
of the services the system provides
b
and its
a .
operational constraints. Written for customers.
• System requirements
a t r
ik p
– A structured document setting out detailed
what/a
of:a/ contract between client and contractor.
should be implemented so may be part
t t p
h Copyright C 2011 Anik Patra 5
Definitions and specifications
o m
• User Requirement Definition
o .t c
sp
– The software must provide a means of representing and accessing
g
external files created by other tools
l o
• System requirement specification
b
.
– The user should be provided with facilities to define the type of external
ra
files
t
– Each external file types may have an associated tool which may be
a
applied to the file
k p
– Each external file type may be represented as a specific icon on the
i
users display
an
– Facilities should be provided for the icon representing an external file
/
/
type to be defined by the user
:
– When a user selects an Icon representing an external file, the effect of
t p
the selection is to apply the tool associated with the type of the external
t
file to the file represented by the selected icon
s
System end-users
g
User
Client engineers
o
requirements
l
Contractor managers
b
System architects
a.
System
at r System end-users
Client engineers
p
requirements System architects
ik
Software developers
/ an
/
Client engineers (perha
ps)
:
Software design
System architects
p
specification
t
Software developers
. b
how the system should behave in particular
situations.
a
t r
• Non-functional requirements
a
p
– constraints on the services or functions offered by the
ik
system such as timing constraints, constraints on the
n
development process, standards, etc.
// a
• Domain requirements
:
p
– Requirements that come from the application domain
l
• Depend on the type of software,
o g expected
.
users and the type of system
a b where the
software is used.
a t r
p
• Functional user requirements may be
ik
high-level statements of what the system
should donbut functional system
:// a
requirements should describe the system
t t p
services in detail.
h Copyright C 2011 Anik Patra 9
o m
The LIBSYS system
o .t c
• A library system that provides a single
sp
o
interface to a number of databases of
l g
a. b
articles in different libraries.
t r
• Users can search for, download and print
a
these articles for personal study.
ik p
/ an
t p:/
ht Copyright C 2011 Anik Patra 10
Examples of functional
o m
requirements
o .t c
s
• The user shall be able to search either all of the
p
l o g
initial set of databases or select a subset from it.
. b
• The system shall provide appropriate viewers for
ra
the user to read documents in the document
t
a
store.
ik p
• Every order shall be allocated a unique identifier
/ an
(ORDER_ID) which the user shall be able to
:/
copy to the account’s permanent storage area.
t t p
h Copyright C 2011 Anik Patra 11
Requirements imprecisionco
m
• Problems arise when requirements areo
t .
s p not
precisely stated.
• Ambiguous requirements mayo
l g
b
be interpreted in
a
different ways by developers
. and users.
– User intention -a
t r
• Consider the term ‘appropriate viewers’
n
each different document type;
// a
– Developer
:
interpretation - Provide a text
p
viewer that shows the contents of the
h t t document.
Copyright C 2011 Anik Patra 12
Requirements completeness
o m
.t c
and consistency
p o
s
• In principle, requirements should be both complete
and consistent.
l o g
b
• Complete
a.
– They should include descriptions of all facilities
required.
at r
p
• Consistent
ik
– There should be no conflicts or contradictions in
n
the descriptions of the system facilities.
:// a
• In practice, it is impossible to produce a complete and
p
consistent requirements document.
g
e.g. reliability, response time and storage
requirements. Constraints are I/O
b l o device
.
capability, system representations, etc.
t
• Process requirements may
r a also be specified
a
mandating a particular CASE system,
p
• Non-functionalkrequirements
programming language
i
or development method.
n
may be more
:/
not met,/ a
critical than functional requirements. If these are
the system is useless.
t t p
h Copyright C 2011 Anik Patra 14
o m
Non-functional classifications
t . c
p o
s
• Product requirements
g
– Requirements which specify that the delivered product must
l o
behave in a particular way e.g. execution speed, reliability, etc.
. b
• Organisational requirements
a
– Requirements which are a consequence of organisational
t r
policies and procedures e.g. process standards used,
a
implementation requirements, etc.
•
k p
External requirements
i
– Requirements which arise from factors which are external to the
an
system and its development process e.g. interoperability
/
/
requirements, legislative requirements, etc.
t p :
ht Copyright C 2011 Anik Patra 15
Non-functional requirement
o m
types
t . c
po
g s
bl o
a.
at r
ik p
/ an
t p:/
ht Copyright C 2011 Anik Patra 16
m
Non-functional requirements
examples c o .
o t
• Product requirement
sp
l o
simple HTML without frames or Java applets. g
The user interface for LIBSYS shall be implemented as
• Organisational requirement b
a.
t r
The system development process and deliverable
a
p
documents shall conform to the process and
ik
deliverables defined in XYZCo-SP-STAN-95.
an
• External requirement
/
:/
The system shall not disclose any personal information
p
t
about customers apart from their name and reference
h t
number to the operators of the system.
Copyright C 2011 Anik Patra 17
Goals and requirements co
m
o t .
s
• Non-functional requirements may be very
p
l o g
difficult to state precisely and imprecise
requirements may be difficult to verify.
• Goal
a . b
a t r
– A general intention of the user such as ease of use.
ik p
• Verifiable non-functional requirement
n
– A statement using some measure that can be
/ a
objectively tested.
:/
• Goals are
p
helpful to developers as they convey
h t t
the intentions of the system users.
Copyright C 2011 Anik Patra 18
o m
Examples
o .t c
• A system goal
sp
o g
– The system should be easy to use by experienced
l
controllers and should be organised in such a way
. b
that user errors are minimised.
a
at r
p
• A verifiable non-functional requirement
ik
– Experienced controllers shall be able to use all the
n
system functions after a total of two hours training.
// a
After this training, the average number of errors
:
p
made by experienced users shall not exceed two per
h t tday.
Copyright C 2011 Anik Patra 19
Requirements measures
o m
o .t c
p
Property Measure
s
Speed Processed transactions/second
g
User/Event response time
Screen refresh time
Size M Bytes
bl o
.
Number of ROM chips
a
Ease of use Training time
r
Number of help frames
Reliability
at
Mean time to failure
p
Probability of unavailability
Rate of failure occurrence
ik
Availability
n
Robustness Time to restart after failure
a
Percentage of events causing failure
://
Probability of data corruption on failure
Portability Percentage of target dependent statements
t p
Number of target systems
t r a number of separate
a
chips in the system should be minimised.
k
– To minimise power
i p consumption, lower power
n
chips should be used.
a
that//more
– However,
:
using low power chips may mean
p
chips have to be used. Which is the
t r
requirements, constraints
requirements ora
on existing
ik p define specific
// a
the :system
t t p may be unworkable.
n i
requirements,k these documents will either
/ a
be printed
/
locally on the system server for
a:network printer.
manually forwarding to the user or routed
top
h t t Copyright C 2011 Anik Patra 23
o m
Domain requirements problems
t . c
p o
– Requirements are expressed in s
• Understandability
a . b
r
– This is often not understood by software
• Implicitness pa
t
engineers developing the system.
n ik
a
– Domain specialists understand the area so
: //
well that they do not think of making the
t t p
domain requirements explicit.
r
who don’t have detailed technical
knowledge.
at
ik p
• User requirements are defined using
an
natural language, tables and diagrams as
/
t p:/
these can be understood by all users.
a . b
r
• Requirements confusion
a t
– Functional and non-functional requirements
ik p
tend to be mixed-up.
a
• Requirements
/ n amalgamation
:/
– Several
p
different requirements may be
h t t expressed together.
Copyright C 2011 Anik Patra 26
Guidelines for writing
o m
requirements
o .t c
• Invent a standard format and use it for all
sp
requirements.
l o g
. b
• Use language in a consistent way. Use
a
t r
shall for mandatory requirements, should
a
for desirable requirements.
ik p
• Use text highlighting to identify key parts
/ an
of the requirement.
p:/
• Avoid the use of computer jargon.
t
ht Copyright C 2011 Anik Patra 27
System requirements co
m
o t .
s p
• More detailed specifications of system
user requirements.
l o g
functions, services and constraints than
a
• They are intended to be. ba basis for
t
designing the system.
a r
contract. ikp
• They may be incorporated into the system
n
• Systemarequirements
/
/
may be defined or
p :
illustrated
t
using system models
a . design are
inseparable
a t r
p
– A system architecture may be designed to
ik
structure the requirements;
:// a
t p
– The use of a specific design may be a domain
h t requirement.
Copyright C 2011 Anik Patra 29
o
Problems with NL specification m
t . c
• Ambiguity
po
– The readers and writers of the requirement
g s
o
must interpret the same words in the same
bl
way. NL is naturally ambiguous so this is very
difficult.
.
• Over-flexibility
ra
t be said in a number of
– The same thinga
different wayspin the specification.
may
n ik
: // a
• Lack of modularisation
– NL structures are inadequate to structure
t t p
system requirements.
p o
s
Notation Description
g
Structured natural This approach depends on defining standard forms or templates to express the
l o
language requirements specification.
. b
Design This approach uses a language like a programming language but with more abstract
description features to specify the requirements by defining an operational model of the system.
ra
languages This approach is not now widely used although it can be useful for interface
t
specifications.
Graphical
notations
p a
A graphical language, supplemented by text annotations is used to define the
functional requirements for the system. An early example of such a graphical
ik
language was SADT. Now, use-case descriptions and sequence diagrams are
n
commonly used .
/ a
Mathematical These are notations based on mathematical concepts such as finite-state machines or
:/
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers don’t understand
t p
formal specifications and are reluctant to accept it as a system contract.
l o
• All requirements are written in a standard way.
b
a.
• The terminology used in the description may be
limited.
at r
p
• The advantage is that the most of the
ik
expressiveness of natural language is
/ an
maintained but a degree of uniformity is imposed
:/
on the specification.
t t p
h Copyright C 2011 Anik Patra 32
Form-based specifications
o m
o .t c
p
• Definition of the function or entity.
• Description of inputs and where they come
g s
from.
bl o
a.
• Description of outputs and where they go
to.
at r
ik p
• Indication of other entities required.
an
• Pre and post conditions (if appropriate).
/
t p:/
• The side effects (if any) of the function.
p o
Insulin Pump/Control Software/SRS/3.3.2
s
Function Compute insulin dose: Safe sugar level
Computes the dose of insulin to be delivered when the current measured sugar level is in
g
Description
the safe zone between 3 and 7 units.
l o
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
b
Source Current sugar reading from sensor. Other readings from memory.
.
Outputs CompDose Š the dose in insulin to be delivered
ra
Destination Main control loop
t
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of
a
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
p
rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can
ik
be delivered.
n
Requires Two previous readings so that the rate of change of sugar level can be computed.
a
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
://
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
t t p
h Copyright C 2011 Anik Patra 34
o m
Tabular specification
o .t c
• Used to supplement natural language.
sp
l o
• Particularly useful when you have to g
. b
define a number of possible alternative
a
courses of action.
at r
ik p
/ an
t p:/
ht Copyright C 2011 Anik Patra 35
o m
Tabular specification
o .t c
sp
g
Condition Action
Sugar level falling (r2 < r1)
bl o CompDose = 0
Sugar level stable (r2 = r1)
a. CompDose = 0
Sugar level increasing and rate of
at
increase decreasing ((r2-r1)<(r1-r0)) r CompDose = 0
ik p
Sugar level increasing and rate of
increase stable or increasing. ((r2-r1)
CompDose = round ((r2-r1)/4)
If rounded result = 0 then
(r1-r0))
/ an CompDose = MinimumDose
t p :/
ht Copyright C 2011 Anik Patra 36
o m
Graphical models
o .t c
• Graphical models are most useful when
sp
o
you need to show how state changes or
l g
a. b
where you need to describe a sequence of
r
actions.
at
ik p
/ an
t p:/
ht Copyright C 2011 Anik Patra 37
o m
Sequence diagrams
o .t c
• These show the sequence of events that
sp
take place during some user interaction
with a system.
l o g
a. b
• You read them from top to bottom to see
t r
the order of the actions that take place.
a
k p
• Cash withdrawal from an ATM
i
– Handle n
– Validate card;
:// a request;
t p
– Complete transaction.
o
be specified as part of the requirements.
.
• Three types of interface may
b l have to be
defined
t ra
a
– Procedural interfaces;
p
ik
– Data structures that are exchanged;
/ a n
– Data representations.
• Formal
p :/ notations are an effective
t
technique for interface specification.
developers.
l o g
a . b
• Should include both a definition of user
t r
requirements and a specification
a
of the system
p
requirements.
n ik
• It is NOT a design document. As far as possible,
:// a
it should set
rather than
of WHAT the system should do
HOW it should do it
t t p
h Copyright C 2011 Anik Patra 41
Users of a requirements
o m
document
o .t c
sp
l o g
a. b
at r
ik p
/ an
t p:/
ht Copyright C 2011 Anik Patra 42
Requirements document
o m
structure c t .
po
s
• Preface
• Introduction
l o g
b
• Glossary
•
a.
User requirements definition
•
a
System architecture
t r
•
p
System requirements specification
ik
n
• System models
•
/ a
System evolution
:/
p
• Appendices
•
ht tIndex
Copyright C 2011 Anik Patra 43
Key points
o m
• Requirements set out what the system should do and
o .t c
p
define constraints on its operation and implementation.
g s
• Functional requirements set out services the system
should provide.
bl o
.
• Non-functional requirements constrain the system being
ra
developed or the development process.
t
a
• User requirements are high-level statements of what the
ik p
system should do. User requirements should be written
using natural language, tables and diagrams.
an
• System requirements are intended to communicate the
/
:/
functions that the system should provide.
t p
• A software requirements document is an agreed
t
statement of the system requirements.
a
Anik Patra
p
Assistant Professor
ik
Department of MCA
:/
anikpatra@gmail.com
p
http://anikpatra.blogspot.com