Req and Specification.zip

  Software Requirements Software Requirements

  Analysis Analysis

  U. Ungkawa U. Ungkawa

  2

  1 September 2

  1

  2

  1 September 2

  1

  

Introduction

Introduction

   The main objective is to set up a working

  The main objective is to set up a working agreement with the customer agreement with the customer

  

Delivers a list of technical requirements the

  

Delivers a list of technical requirements the

software must satisfy software must satisfy

  

Requirements should be traceable; they can

  

Requirements should be traceable; they can

be: be:

• Easily identified

  Easily identified

• Unambiguously described

  Unambiguously described

• Tested

  Tested

  Specification Process Specification Process

  

Introduction

Introduction

   Specification is a commitment between the

  Specification is a commitment between the customer and the developer. customer and the developer.

   It end with the SW Specification Review (SSR)

  It end with the SW Specification Review (SSR) during which the customer approves or rejects during which the customer approves or rejects the list of requirements that must be satisfied the list of requirements that must be satisfied by the software. by the software.

   It must guarantee – as much as possible – the

  It must guarantee – as much as possible – the feasibility of the software product. feasibility of the software product.

  Specification Process Specification Process

  

Process Model

Process Model

   Modeling of functional requirements by

  Modeling of functional requirements by Functional Decomposition. Functional Decomposition.

   We wish to decompose our functional

  We wish to decompose our functional requirements in a manner such that: requirements in a manner such that:

• Related functions are grouped together

  Related functions are grouped together

• Unrelated functions are separated

  Unrelated functions are separated

• Each function should be specified only once.

  Each function should be specified only once.

  Purpose of The Process Model Purpose of The Process Model

  

Process Model

Process Model

   Context Diagram describes the system

  Context Diagram describes the system function and defines the system scope. function and defines the system scope.

   Only one process bubble.

  Only one process bubble.

   At least one input and one output

  At least one input and one output 

  At least one terminator At least one terminator

  

All terminators are connected to at least one

  

All terminators are connected to at least one

input or output flow input or output flow

   No data exchanged between terminators

  No data exchanged between terminators

Data Context Diagram

  Data Context Diagram

  

Process Model

Process Model

  Data Context Diagram Data Context Diagram

   DFDs are used for process decomposition

  DFDs are used for process decomposition 

  Every process is decomposed in other process Every process is decomposed in other process

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

  DFD) DFD)

   Rule of 7 ± 2is used:

  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

  Up to 4 levels of decomposition 

  Each DFD specifies the decomposition of its Each DFD specifies the decomposition of its parent bubble parent bubble

  

Process Model

Process Model

  

Data Context Diagram (Cont.)

Data Context Diagram (Cont.)

   Processes are the active elements in the

  Processes are the active elements in the model model

   Process performs a transformation:

  Process performs a transformation:

• If and only if ALL input information available

  If 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

  The output from the process should be a function of the input to it function of the input to it

   Data flow allow transit of data within the

  Data flow allow transit of data within the system system

  

Store is place where information is preserved

  

Store is place where information is preserved

  

Process Model

Process Model

  PSPEC PSPEC 

  PSPEC’s are the lowest abstraction level PSPEC’s are the lowest abstraction level

   Make a PSPEC approximately ½ page long

  Make a PSPEC approximately ½ page long 

  Shows the relation between process input and Shows the relation between process input and output flows output flows

   Any form of specification mat be used:

  Any form of specification mat be used:

• Drawings

  Drawings

• Mathematical equations

  Mathematical equations

• Structural English (Indonesian)

  Structural English (Indonesian)

  

Process Model

Process Model

  PSPEC PSPEC

  Inputs: Inputs:

  payment payment

  : data in : data in price price

  : data in : data in

  Output: Output:

  Change due Change due

  : data out : data out

  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 change due = payment change due = payment

  

Control Model

Control Model

  

Purpose of the Control Model

Purpose of the Control Model _

  Describes the dynamic aspects of the software Describes 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

  _ hierarchical structure of the process model Controls the data processing

  Controls 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

  _ 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)

  Specification (CSPEC)

  

Control Model

Control Model

  CCD _

CCD

  CCD describes the system function and defines the CCD describes the system function and defines the system scope (same as DCD) _ system scope (same as DCD) CCD defines the external control interface of the

  CCD defines the external control interface of the system system

  Control flow : Data flow : Carry information that is Carry information needed to be interpreted for by a process to perform changing system behavior transformations and/or activating processes

  

Control Model

Control Model

  CFD CFD _

  CFD is coupled to the equivalent level DFD and shares CFD is coupled to the equivalent level DFD and shares the same processes. the same processes. _

  CFD shows control flows instead of data flows CFD 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) Specification (CSPEC) _ The CSPEC is represented by a bar.

  The CSPEC is represented by a bar. _ At most one CSPEC for each DFD/CFD

  At most one CSPEC for each DFD/CFD

  CSPEC CSPEC _

  

Control Model

Control Model

  Use of the concept of Finite State Machine Use 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:

• PAT

  PAT

• STD

  STD

• Combination of two

  Combination of two

  

Data Model

Data Model

  Requirements Dictionary Requirements Dictionary _

  Is the principal tool that makes the method rigorous Is 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. definition in terms of its components and structure. _

  Every flow must be in the dictionary Every 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. their primitive (self-defining) elements. _

  Primitive elements have attributes that define the Primitive elements have attributes that define the element like: units, range, accuracy, …

  _ 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 modeling in practice

  

Data Model

Data Model

  Requirements Dictionary Requirements Dictionary

  All possible data structures can be represented with: All possible data structures can be represented with:

  = = composed of composed of

  together with together with

  {} {} iteration of iteration of

  [..|..] [..|..] composed of composed of

  () () optional item optional item

  “ ” “ ” literal literal

  gives additional insight into its meaning gives additional insight into its meaning

  

Building The Requirements Model

Building The Requirements Model

  Context Diagram (CD) Context Diagram (CD) _

  CD establishes data and control exchange between the CD establishes data and control exchange between the system under study and environment

  _ 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

  _ 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

  _ 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:

  Diagrams, it comprises:

• One process (the system)

  One process (the system)

• Terminators

  Terminators

• Data flows, control flows

  Data flows, control flows

  

Building The Requirements Model

Building The Requirements Model

  Context Diagram (CD) (cont.) 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 establishing the system boundary is an iterative process. 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 several data flow diagrams before a boundary can be established. 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 and be modified if required, because at all times you should know: “What you are working on” and “What is should know: “What you are working on” and “What is your system” your system”

  

Building The Requirements Model

Building The Requirements Model

  

Separation of Data and Control

Separation of Data and Control

  It is usually best to work on the data and data processing It is usually best to work on the data and data processing first, because:

  _ first, because:

  It is necessary to know It is necessary to know what what 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 processes as 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 process

  

Building The Requirements Model

Building The Requirements Model

  

Separation of Data and Control (cont.)

Separation of Data and Control (cont.)

  The following criteria are helpful in determine whether a The following criteria are helpful in determine whether a flow is a data flow or a control flow:

  _ 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 control _ categorized 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 usually associated with control requirements

  

Building The Requirements Model

Building The Requirements Model

  

Something about Control

Something about Control

  Each DFD/CFD pair decide: 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 CSPEC

  If 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 Let as many of your processes be data triggered data triggered as possible as possible

  

Building The Requirements Model

Building The Requirements Model

  

Balancing and Leveling

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 into children must match those of its parent process, this is called is called

  balancing balancing _

  The decomposition itself is called The decomposition itself is called

  leveling leveling _

  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 primitive functional 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

  _ 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 it is good practice to write so called high-level PSPECs for each process at any level DFD each process at any level DFD

  

Building The Requirements Model

Building The Requirements Model

  

Requirement Model Balancing Rules

Requirement Model Balancing Rules

_

  Every DFD/CFD must balance with each parent process Every 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

  _ process it describes Every CSPEC must balance with its associated CFD

  Every 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 of processes on the DFD having the same number as the

  CSPEC 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 conditions) can only be specified in a PSPEC for a functional primitive process

  _ 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 and must be decomposed to its primitive elements, in the requirements dictionary the requirements dictionary

  

Building The Requirements Model

Building The Requirements Model

  

Evaluation of 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 isolated Has control been isolated _

  Is every component correctly named and are the Is every component correctly named and are the names understandable?

  _ 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?

  _ related functions grouped together? …

  … ?

  ?

  Building The Requirements Model Building The Requirements Model

  Summary Summary _

  Don’t be afraid to start over Don’t be afraid to start over

  . It frequently happens . It frequently happens that preparing a child DFD will cause its parents to be that preparing a child DFD will cause its parents to be revised

  _ 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 it you have completed it .

  . _ It is only clear what a DFD means once it is completed

  It is only clear what a DFD means once it is completed