Req and Specification.zip

(1)

Software Requirements

Analysis

U. Ungkawa

2

(2)

2 2

Introduction



The main objective is to set up a working

agreement with the customer



Delivers a list of technical requirements the

software must satisfy



Requirements should be traceable; they can

be:

• Easily identifiedEasily identified

• Unambiguously describedUnambiguously described

• TestedTested

Specification Process

(3)

Introduction



Specification is a commitment between the

customer and the developer.



It end with the SW Specification Review (SSR)

during which the customer approves or rejects

the list of requirements that must be satisfied

by the software.



It must guarantee – as much as possible – the

feasibility of the software product.

Specification Process

(4)

4 4

Process Model



Modeling of functional requirements by

Functional Decomposition.



We wish to decompose our functional

requirements in a manner such that:

• Related functions are grouped togetherRelated functions are grouped together

• Unrelated functions are separatedUnrelated functions are separated

• Each function should be specified only once.Each function should be specified only once.

Purpose of The Process Model

(5)

Process Model



Context Diagram describes the system

function and defines the system scope.



Only one process bubble.



At least one input and one output



At least one terminator



All terminators are connected to at least one

input or output flow



No data exchanged between terminators

Data Context Diagram

(6)

6 6

Process Model

Data Context Diagram



DFDs are used for process decomposition



Every process is decomposed in other process

(within a DFD) or in one PSPEC (outside a

DFD)



Rule of 7 ± 2is used:

• Balance between lack of information (4 or less) and Balance between lack of information (4 or less) and too much (more than 9)

too much (more than 9)



Up to 4 levels of decomposition



Each DFD specifies the decomposition of its

(7)

Process Model

Data Context Diagram (Cont.)



Processes are the active elements in the

model



Process performs a transformation:

• If and only if ALL input information availableIf and only if ALL input information available

• Production of all information is IMMEDIATE, i.e all Production of all information is IMMEDIATE, i.e all proceeing is done in zero delay

proceeing is done in zero delay



The output from the process should be a

function of the input to it



Data flow allow transit of data within the

system

(8)

(9)

Process Model

PSPEC



PSPEC’s are the lowest abstraction level



Make a PSPEC approximately ½ page long



Shows the relation between process input and

output flows



Any form of specification mat be used:

• DrawingsDrawings

• Mathematical equationsMathematical equations

(10)

10 Sufficient payment: data out Sufficient payment: data out

Body

Body::

if payment ≥ price if payment ≥ price

change due = payment – price change due = payment – price

sufficient payment = yes sufficient payment = yes otherwise

otherwise

(11)

Control Model

Purpose of the Control Model

 Describes the dynamic aspects of the softwareDescribes the dynamic aspects of the software

 Is an addition to the process model, uses the Is an addition to the process model, uses the

hierarchical structure of the process model

 Controls the data processingControls the data processing

 Defines the operating modes and the events that Defines the operating modes and the events that

causes changes in the operating modes

 Logic of the control flow is summarized in a Control Logic of the control flow is summarized in a Control

Specification (CSPEC)

(12)

12

 CCD describes the system function and defines the CCD describes the system function and defines the

system scope (same as DCD)

 CCD defines the external control interface of the CCD defines the external control interface of the

system

Data flow:

Carry information needed by a process to perform transformations

Control flow:

Carry information that is to be interpreted for

changing system behavior and/or activating

(13)

Control Model

CFD

 CFD is coupled to the equivalent level DFD and shares CFD is coupled to the equivalent level DFD and shares

the same processes.

 CFD shows control flows instead of data flowsCFD shows control flows instead of data flows

 The control processing is described in the Control The control processing is described in the Control

Specification (CSPEC)

 The CSPEC is represented by a bar.The CSPEC is represented by a bar.

(14)

14 14

Control Model

CSPEC

 Use of the concept of Finite State MachineUse of the concept of Finite State Machine

 The two types of FSM we distinguish are:The two types of FSM we distinguish are:

• Combinational: has no memory, at any time it can only Combinational: has no memory, at any time it can only produce its output directly from its input.

produce its output directly from its input.

• Sequential: has memory, it can only handle the control that is Sequential: has memory, it can only handle the control that is relevant in a certain state.

relevant in a certain state.

 Models used:Models used:

• PATPAT • STDSTD

(15)

Data Model

Requirements Dictionary

 Is the principal tool that makes the method rigorousIs the principal tool that makes the method rigorous

 It is a list of data and control flow names each with a It is a list of data and control flow names each with a

definition in terms of its components and structure.

 Every flow must be in the dictionaryEvery flow must be in the dictionary

 Group names must be broken down, eventually into Group names must be broken down, eventually into

their primitive (self-defining) elements.

 Primitive elements have attributes that define the Primitive elements have attributes that define the

element like: units, range, accuracy, …

 In fact a database is necessary to support the In fact a database is necessary to support the

modeling in practice

(16)

16

All possible data structures can be represented with:

=

= composed ofcomposed of +

+ together withtogether with {}

{} iteration ofiteration of [..|..]

[..|..] composed ofcomposed of ()

() optional itemoptional item “ ”

“ ” literalliteral * *

(17)

Building The Requirements Model

Context Diagram (CD)

 CD establishes data and control exchange between the CD establishes data and control exchange between the

system under study and environment

 Terminators are shown on the CD of the system, Terminators are shown on the CD of the system,

because they are not part of the system

 Stores are not shown on the CD because they are Stores are not shown on the CD because they are

considered to be part of the system

 The CD is the highest level of the Data/Control Flow The CD is the highest level of the Data/Control Flow

Diagrams, it comprises:

• One process (the system)One process (the system) • TerminatorsTerminators

(18)

18 18

Building The Requirements Model

Context Diagram (CD) (cont.)

 When creating the CD for any system, remember that When creating the CD for any system, remember that

establishing the system boundary is an iterative

process.

 For complex systems it may be necessary to draw For complex systems it may be necessary to draw

several data flow diagrams before a boundary can be

established.

 It is very important that this boundary be established It is very important that this boundary be established

and be modified if required, because at all times you

should know: “What you are working on” and “What is

your system”

(19)

Building The Requirements Model

Separation of Data and Control

It is usually best to work on the data and data processing

first, because:

 It is necessary to know It is necessary to know whatwhat you are controlling before you you are controlling before you

decide how to control it decide how to control it

 Data processing can and should be defined independently of Data processing can and should be defined independently of

how, why or when

how, why or when they are activated they are activated

 Our objective in defining systems will be to minimize control by Our objective in defining systems will be to minimize control by

finding

finding as many as processesas many as processes as possible which can simplify as possible which can simplify

data triggered

data triggered and need no other control and need no other control But be aware

But be aware

 Your model may need rework after you decide to introduce a Your model may need rework after you decide to introduce a

control specification:

control specification: requirements modeling is an iterative requirements modeling is an iterative process

(20)

20 20

Building The Requirements Model

Separation of Data and Control (cont.)

The following criteria are helpful in determine whether a

flow is a data flow or a control flow:

 Continuous signals, and processes that act on them, are Continuous signals, and processes that act on them, are

always

always categorized as data.categorized as data.

 Discrete signals, and process that act on them, are Discrete signals, and process that act on them, are

usually

usually categorized as controlcategorized as control

 Terms like Terms like activate, turn on, engage activate, turn on, engage and and execute execute are are

usually associated with control requirements

(21)

Building The Requirements Model

Something about Control

Each DFD/CFD pair decide:

 Is control required at this level, i.e. may all processes operate Is control required at this level, i.e. may all processes operate

concurrently and data triggered? concurrently and data triggered?

 Do not control processes if they do not need controlling!Do not control processes if they do not need controlling!

 If control at this level then the flow flow s into a CSPECIf control at this level then the flow flow s into a CSPEC

 If control not at this level, flows are passed down to the If control not at this level, flows are passed down to the

appropriate level where control takes place appropriate level where control takes place

 For those processes that need control decide which processes For those processes that need control decide which processes

may operate concurrently and which must be mutual exclusive may operate concurrently and which must be mutual exclusive

Let as many of your processes be

(22)

22 22

Building The Requirements Model

Balancing and Leveling

 The inputs and outputs of a decomposition of a process The inputs and outputs of a decomposition of a process

into children must match those of its parent process, this

is called

is called balancingbalancing

 The decomposition itself is called The decomposition itself is called levelingleveling

 When a process can not be broken down anymore, it is When a process can not be broken down anymore, it is

called a

called a functional primitivefunctional primitive and it will be described in and it will be described in a PSPEC

a PSPEC

 A rule of thumb is to stop when the process can be A rule of thumb is to stop when the process can be

described in about ½ page of specifications

 PSPEC are written for functional primitives only. However PSPEC are written for functional primitives only. However

it is good practice to write so called high-level PSPECs for

each process at any level DFD

(23)

Building The Requirements Model

Requirement Model Balancing Rules

 Every DFD/CFD must balance with each parent processEvery DFD/CFD must balance with each parent process  Every PCPEC must balance with the functional primitive Every PCPEC must balance with the functional primitive

process it describes

 Every CSPEC must balance with its associated CFDEvery CSPEC must balance with its associated CFD

 Every CSPEC must only show activation and deactivation Every CSPEC must only show activation and deactivation

of processes on the DFD having the same number as the

CSPEC

 The derivation of control signal from data signals (data The derivation of control signal from data signals (data

conditions) can only be specified in a PSPEC for a

functional primitive process

 Every data flow, control flow, and store must be defined, Every data flow, control flow, and store must be defined,

and must be decomposed to its primitive elements, in

the requirements dictionary

(24)

24 24

Building The Requirements Model

Evaluation of the Requirements Model

 Are all the level necessary?Are all the level necessary?

 Are all the names clear?Are all the names clear?

 Has control been isolatedHas control been isolated

 Is every component correctly named and are the Is every component correctly named and are the

names understandable?

 Are any flows missing?Are any flows missing?

 Do the processes satisfy the requirements?Do the processes satisfy the requirements?

 Have unrelated functions been separated and are Have unrelated functions been separated and are

related functions grouped together?

(25)

Building The Requirements Model

Summary

 Don’t be afraid to start overDon’t be afraid to start over. It frequently happens . It frequently happens

that preparing a child DFD will cause its parents to be

revised

 You will not fully comprehend the process of putting You will not fully comprehend the process of putting

DFD’s together until

DFD’s together until you have completed ityou have completed it..