Class 4 (Software Requirements)

o m
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
and the constraints underlo

g
that the customer requires from a system
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
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
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
servicesnand operational constraints. Defines

descriptions of the system’s functions,
what/a
of:a/ contract between client and contractor.
should be implemented so may be part
t t p
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

Requirements readers co
m
o t .
p
Client managers
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

Functional and non-functional
o m
requirements
o .t c
• Functional requirements
sp
l o g
– Statements of services the system should provide,
how the system should react to particular inputs and
. 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
h t tof the system and that reflect characteristics of that

domain. Copyright C 2011 Anik Patra 8
Functional requirements co
m
o t .
sp
• Describe functionality or system services.
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.
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:/
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
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’
ik p special purpose viewer for
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.
ht t Copyright C 2011 Anik Patra 13

o m
Non-functional requirements
t . c
p o
s
• These define system properties and constraints
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
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 :
Non-functional requirement
o m
types
t . c
po
g s
bl o
a.
at r
ik p
/ an
t p:/
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.
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.
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.
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

Requirements interaction o m
t . c
• Conflicts between different non-functional
p o
requirements are common in complex
g s
o
systems.
l
– To minimise weight, the.b
• Spacecraft system
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
h t t most critical requirement?

Domain requirements o m
• Derived from the application domaintand . c
p o
s
describe system characteristics and
g
l o
features that reflect the domain.
b
• Domain requirements be
a . new functional
t r
requirements, constraints
requirements ora
on existing
ik p define specific
• If domainnrequirements are not satisfied,

computations.
// a
the :system
t t p may be unworkable.

m
Library system domain
requirements
.t co
p o
s
• There shall be a standard user interface to
all databases which shall be based on the
Z39.50 standard.
l o g
• Because of copyright.brestrictions, some
documents must tbe r adeleted immediately
p a
on arrival. Depending on the user’s
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
of the application domain; lo

g the language
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.

o m
User requirements
o .t c
• Should describe functional and non-
sp
o
functional requirements in such a way that
l g
a. b
they are understandable by system users
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.

m
Problems with natural
language
.t co
p o
s
• Lack of clarity
document difficult to read. lo

g
– Precision is difficult without making the
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.
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
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
h t Copyright C 2011 Anik Patra 28

Requirements and design o m
t . c
• In principle, requirements should state
p o
what the system should do and the
should describe how it does g s design
• In practice, requirements land

b o this.
a . design are
inseparable
a t r
p
– A system architecture may be designed to
ik
structure the requirements;
systemsnthat generate design requirements;

– The system may inter-operate with other
:// a
t p
– The use of a specific design may be a domain
h t requirement.
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.

Alternatives to NL
o m
.t c
specification
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.

Structured language
o m
specifications
o .t c
s
• The freedom of the requirements writer is limited
p
g
by a predefined template for requirements.
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
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.

Form-based node
o m
.t c
specification
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
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:/
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 :/
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:/
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.

m
Sequence diagram of
ATM withdrawal
.t co
p o
g s
bl o
a.
at r
ik p
/ an
t p:/
Interface specification
o m
t . c
• Most systems must operate with other
p o
systems and the operating interfaces
g s must
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.
h t Copyright C 2011 Anik Patra 40

o m
The requirements document
t . c
p o
statement of what is required of thessystem
• The requirements document is the official
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
Users of a requirements
o m
document
o .t c
sp
l o g
a. b
at r
ik p
/ an
t p:/
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
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.

o m
o .t c
Thank Yougs
p
bl o
a.
t r
Presentation Created By
a
Anik Patra
p
Assistant Professor
ik
Department of MCA
/ an Techno India Hooghly
:/
anikpatra@gmail.com
p
http://anikpatra.blogspot.com
ht t Copyright C 2011 Anik Patra 45

Class 4 (Software Requirements)

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Class 4 (Software Requirements)

Загружено:

Авторское право:

Доступные форматы

o m

and the constraints underlo

servicesnand operational constraints. Defines

h Copyright C 2011 Anik Patra 6

ht Copyright C 2011 Anik Patra 7

h t tof the system and that reflect characteristics of that

ik p special purpose viewer for

ht t Copyright C 2011 Anik Patra 13

ht Copyright C 2011 Anik Patra 20

h t t most critical requirement?

• If domainnrequirements are not satisfied,

h Copyright C 2011 Anik Patra 22

of the application domain; lo

h Copyright C 2011 Anik Patra 24

ht Copyright C 2011 Anik Patra 25

document difficult to read. lo

h t Copyright C 2011 Anik Patra 28

• In practice, requirements land

systemsnthat generate design requirements;

h Copyright C 2011 Anik Patra 30

ht Copyright C 2011 Anik Patra 31

ht Copyright C 2011 Anik Patra 33

ht Copyright C 2011 Anik Patra 38

h t Copyright C 2011 Anik Patra 40

h Copyright C 2011 Anik Patra 44

/ an Techno India Hooghly

ht t Copyright C 2011 Anik Patra 45

Вам также может понравиться