ch6 software requirement part 2

8/8/2019 Ch6 Software Requirement Part 2

http://slidepdf.com/reader/full/ch6-software-requirement-part-2 1/19

1

Chapter 6

Software RequirementsPart - 2



2

6.3 System requirements

More detailed specifications of user requirements

Serve as a basis f or designing the system

May be used as part of the system contract

System requirements may be expressed using system models

such as (con

text, behavioral, data, a

nd

object

orie

nted m

odels)

Should state what the system should do and not ,how it shouldbe implemented.



3

Requirements and design

In principle, requirements should state what thesystem should do and the design should describe how it does this

In practice, requirements and design are inseparable,because of the f ollowing:

± A system architecture may be initially desig

ned t

o help in structuring the requirements

± The system may inter-operate with other systemsthat generate design requirements



4

Pr oblems with NL (When used in detailed

specification , in system design)

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 modularization

± NL structures are inadequate to structure system

requirements



5

Alter natives to NL specification

Because of these problems, requirements

specifications written in NL are prone (liable) to

misunderstanding.

These are often not discovered until later phases

which make it very expensive to resolve.

There are various alternatives to the use of NL

such are structured language specifications and

graphical notation.



6

Alter natives to NL specification

Notation Description

Structured natural

language

This approach depends on defining standard forms or templates to express the

requirements specification.

Design

descriptionlanguages

This approach uses a language like a programming language but with more abstract

features to specify the requirements by defining an operational model of the system.This approach is not now widely used although it can be useful for interfacespecifications.

Graphical

notations

A graphical language, supplemented by text annotations is used to define the

functional requirements for the system. An early example of such a graphical

language was SADT. Now, use-case descriptions and sequence diagrams arecommonly used .

Mathematical

specifications

These are notations based on mathematical concepts such as finite-state machines or

sets. These unambiguous specifications reduce the arguments between customer and

contractor about system functionality. However, most customers don¶t understandformal specifications and are reluctant to accept it as a system contract.



7

6.3.1 Structured language

specifications

A limited f orm of natural language may be usedto express requirements.

This removes some of the pr oblems resultingfr om ambiguity and flexibility and imposes adegree of unif ormity on a specification

It may limit the terminology used, and may useone or more standard f orms or templates to

specify system requirements.



8

functional requirementsis used f or specifyingf ormhisT

( content of the f orm)

Form-based appr oach specifications:

Definition of the function or entity

Description of inputs and where they come

fr om Description of outputs and where they go

to

Indication of other entities required Description of the side effects (if any)



9

Form-based node specification

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: a e sugar level

Descri tion Computes the dose o insulin to be delivered hen the current measured sugar level is in

the sa e zone bet een 3 and 7 units.

Inputs Current sugar reading (r2), the previous t o readings (r0 and r1)

Source Current sugar reading rom sensor. Other readings rom memory.

OutputsComp ose ± the dose in insulin to be delivered

Destination ain control loop

Action: Comp ose is zero i the sugar level is stable or alling or i the level is increasing but the rate o

increase is decreasing. I the level is increasing and the rate o increase is increasing, then Comp ose is

computed by dividing the di erence bet een the current sugar level and the previous level by 4 and

rounding the result. I the result, is rounded to zero then Comp ose is set to the minimum dose that can

be delivered.

R equires T o previous readings so that the rate o change o sugar level can be computed.

Pre-condition The insulin reservoir contains at least the maximum allo ed single dose o insulin..

Post-condition r0 is replaced by r1 then r1 is replaced by r2

Side-effects one



11

Graphical models Graphical models are most useful when you need to show

how state changes or where you need to describe asequence of actions.

Example of graphical model is sequence diagram in the

next slide. You read them fr om top to bottom to see the order of the

actions that take place.

Cash withdrawal fr om an ATM ± Validate card;

± Handle request;

± Complete transaction.



12

Sequence diagram of ATM

withdrawal



13

6.4 Interface specification Most systems must operate with other systems and the

operating interfaces must be specified as part of the

requirements

Three types of interface may have to be defined

± Pr ocedural interfaces, where existing sub-system offer a

range of services. (Called application pr ogramming Interface(APIs)

± Data structures which are passed fr om one structure to

another. Use the Graphical Data models to represent thistype.

± Data representation: such as the order of bits. Used in real

time embedded system



14

6.5 The software requirements

document

The requirements document is the official statement of

what is required of the system developers

Should include both a definition and a specification of

requirements

It is NOT a design document. As far as possible, it

should set of WHAT the system should do rather than HOW it should do it



15

The Requirements Document should:

Specify exter nal system behaviour

Specify implementation constraints

should be easy to change Characterise responses to unexpected events



16

requirements documentStructure of

Standards as suggested by IEEE:

Intr oduction, purpose of the requirements document, scope of

the pr oduct, references, overview of the document.

General description, pr oduct functions, user chars, generalconstraints, assumptions and dependencies.

Specific requirements, covering functional, non-functional, and

interface requireme

nts.

Appendices

Index

This is a generic structure that must be instantiated f or specific

systems



17

Requirements document

structure Intr oduction

Glossary

User requireme

nts defi

niti

on

System architecture

System requirements specification

System models

System evolution

Appendices

Index, may be several.



18

Key points

Requirements set out what the system should do and

define constraints on its operation and implementation

Functional requirements set out services the system

should pr ovide

Non-functional requirements are pr oduct requirements

which constrain the system being developed or the

developme

nt pr

ocess

User requirements are high-level statements of what

the system should do



19

Key points

User requirements should be written in natural

language, tables and diagrams

System requirements are intended to communicate

the functions that the system should pr ovide

System requirements may be written in structured

natural language, a in a f ormal language

A software requirements document is the agreedstatement of the system requirements. It should be

organized so that can be used by both system

customers and software developers.

ch6 software requirement part 2

Documents