1

Lecture 3Lecture 3

Requirement Analysis

System Analysis Concepts

Modeling Techniques

2

Disclaimer and Copyright Notice

This work is subject to copyright. All rights are reserved.

This course material is developed in conjunction with the courseware of Software Engineering: A Practitioner’s

Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001.

The material provided is for reference only. It should not be redistributed with prior written consent. Proceeding beyond this notice implies willingness to comply with the terms.

3

The HierarchyWorld view

Business orProduct Domain

Domain of interest

Domain view

System element

Element view

Detailed view

4

Business Process Engineering

uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise

focuses first on the enterprise and then on the business area

creates enterprise models, data models and process models

creates a framework for better information management distribution, and control

5

The BPE Hierarchy

Information strategy planning– strategic goals defined– success factors/business

rules identified– enterprise model created

Business area analysis– processes/services modeled– interrelationships of

processes and data

Business system design– modeling information

systems/procedures that address BAA and constraints of ISP

– Translate requirement into data architecture, applications architecture and technology infrastructure

Construction and delivery– using CASE and 4GTs,

testing

6

Product EngineeringSystem analysis

(World view)

The completeproduct

capabilities

Componentengineering

(Domain view)

Processing requirement

Analysis & DesignModeling

(Element view)

Construction&

Integration(Detailed view)

software

function

SoftwareEngineering

programcomponent

hardware

data behavior

7

Requirement Requirement EngineeringEngineering

8

Elicitation

Determining what the customer requires Problems of scope, understanding and volatility

Assess project Assess project feasibilityfeasibility

Identify key person(s)Identify key person(s) Get user commitmentGet user commitment Identify environmentIdentify environment Define elicitation Define elicitation

methodsmethods Identify ambiguous Identify ambiguous

requirementsrequirements Create usage Create usage

scenariosscenarios

Statement of need and Statement of need and feasibilityfeasibility

Statement of scopeStatement of scope List of participantsList of participants Description of technical Description of technical

environmentenvironment List of requirements and List of requirements and

constraintsconstraints Set of usage scenariosSet of usage scenarios

9

Analysis & negotiation

understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result

ConsistentConsistent Right level of detailRight level of detail NecessaryNecessary Bounded and clearBounded and clear

Traceable to the Traceable to the sourcesource

ConflictsConflicts AchievableAchievable TestableTestable

10

Other Steps

Requirements specification — building a tangible model of requirements, the basis for product development for all parties involved

System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency

Validation — reviewing the model Management — identify, control and track

requirements and the changes that will be made to them– Traceability tables: features, source, dependency, subsystem

and system interface

11

Product Architecture Template

user interface processing

inputprocessing

outputprocessing

maintenance and self-test

process and controlfunctions

12

Architecture Flow Diagram

bar codereader

subsystem

bar codedecoding

subsystem

data baseaccess

subsystem

shuntcontrol

subsystem

reportformating

subsystem

diagnosticssubsystem

operatorinterface

subsystem

shuntcontroller

mainframecommunications

driver

operator requests CLSS queries, reports, displays

shunt control statusbar code acquisition request

bar code

pulse tach input

linespeed

bar codereader status

sensor status

raw barcode data

partnumber

reportrequests

binlocation

key

sort records

formatedreporting data

sorting reports

shunt commands

CLSS reports

BCR statusshunt status

communications status

timing/location data

operatorinterface

data acquisitioninterface diagnostic interface output interface

CLSS processing & control

sensor dataacquisitionsubsystem

13

Systems Analysis Systems Analysis ConceptsConcepts

14

Requirements GatheringFFacilitatedacilitated AApplication pplication SSpecification pecification TTechniquesechniques

SoftwareSoftwareEngineeringEngineering

GroupGroup

CustomerCustomerGroupGroup

15

FAST Guidelines

participants must attend entire meeting all participants are equal preparation is as important as meeting all pre-meeting documents are to be viewed as

“proposed” off-site meeting location is preferred set an agenda and maintain it don’t get mired in technical detail

J. Wood & D. Silver

16

Quality Function Deployment

Function deployment determines the “value” (as perceived by the customer) of each function required of the system

Information deployment identifies data objects and events

Task deployment examines the behavior of the system

Value analysis determines the relative priority of requirements

17

Use-cases

A collection of scenarios that describe the thread of usage of a system

Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way

Each scenario answers the following questions:– What are the main tasks of functions performed by the actor?– What system information will the actor acquire, produce or

change?– Will the actor inform the system about environmental changes?– What information does the actor require of the system?– Does the actor wish to be informed about unexpected changes

– What are the main tasks of functions performed by the actor?– What system information will the actor acquire, produce or

change?– Will the actor inform the system about environmental changes?– What information does the actor require of the system?– Does the actor wish to be informed about unexpected changes

18

The Analysis Process

the problemthe problemrequirementsrequirements

elicitationelicitation

build abuild aprototypeprototype

createcreateanalysisanalysismodelsmodels

developSpecification ReviewReview

19

Analysis Principle IModel the Data Domain

define data objects describe data attributes establish data relationships

define data objects describe data attributes establish data relationships

content and relationshipcontent and relationship flowflow structurestructure

20

Analysis Principle IIModel Function

identify functions that transform data objects

indicate how data flow through the system

represent producers and consumers of data

an iterative process

identify functions that transform data objects

indicate how data flow through the system

represent producers and consumers of data

an iterative process

21

Analysis Principle IIIModel Behavior

indicate different states of the system specify events that cause the system

to change state

indicate different states of the system specify events that cause the system

to change state

22

Analysis Principle IVPartition the Models

refine each model to represent lower levels of abstraction refine data objects create a functional hierarchy represent behavior at different levels

of detail

refine each model to represent lower levels of abstraction refine data objects create a functional hierarchy represent behavior at different levels

of detail

23

Analysis Principle VEssence

begin by focusing on the essence of the problem without regard to implementation details

begin by focusing on the essence of the problem without regard to implementation details

24

Davis’ Principles

Understand the problem before you begin to create the analysis model.

Develop prototypes that enable a user to understand how human-machine interaction will occur.

Record the origin of and the reason for every requirement.

Use multiple views of requirements. Prioritize requirements. Work to eliminate ambiguity.

25

The Analysis Model

Data Model

BehavioralModel

FunctionalModel

26

Analysis ModelingAnalysis Modeling

27

Where to Begin?

A statement of scope can be acquired from:– the FAST working document – A set of use-cases

the statement of scope must be “parsed” to extract data, function and behavioral domain information

28

Statement of Scope

a relatively brief description of the system to be built– indicates data that are input and output and

basic functionality– indicates conditional processing (at a high

level)– implies certain constraints and limitations

29

Identifying Objects and Operations

define “objects” - nouns in the written statement of scope

• producers/consumers of data• places where data are stored• “composite” data items

define “operations” - by active verbs• processes relevant to the application• data transformations

consider other “services” that will be required by the objects

30

Elements of an Analysis Model

DataDictionary

EntityRelationship

Diagram

DataFlow

Diagram

State-transitionDiagram

DataObject

Description

ProcessSpecification

(PSPEC)

ControlSpecification (CSPEC)

31

Data Modeling Data Modeling and and

Entity RelationshipEntity RelationshipDiagrammingDiagramming

32

Why Data Modeling?

examines data objects independently of processing

focuses attention on the data domain creates a model at the customer’s level of

abstraction indicates how data objects relate to one

another

33

What Is a Data Object?

Object – something that is described by a set of attributes (data items) and that will be manipulated within the software (system)

Each instance of an object (e.g. a book) Each instance of an object (e.g. a book) can be identified uniquely (e.g. ISBN#)can be identified uniquely (e.g. ISBN#)

Each plays a necessary role in the Each plays a necessary role in the systemsystem

i.e. the system could not function i.e. the system could not function without access to instances of the without access to instances of the objectobject

Each is described by attributes that are Each is described by attributes that are themselves data itemsthemselves data items

34

Typical Objects

external entities (printer, user, sensor) things (e.g., reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) organizational units (e.g., division, team) places (e.g., manufacturing floor) structures (e.g, employee record)

35

Data Objects and AttributesA data object contains a set of attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, that act as an aspect, quality, characteristic, or descriptor of the objector descriptor of the object

object: automobileobject: automobileattributes:attributes: makemake modelmodel body typebody type priceprice options codeoptions code

object: automobileobject: automobileattributes:attributes: makemake modelmodel body typebody type priceprice options codeoptions code

36

What Is a Relationship?

several instances of a relationship can exist objects can be related in many different ways

several instances of a relationship can exist objects can be related in many different ways

relationship relationship – indicates “connectedness”’; a – indicates “connectedness”’; a “fact” that must be “remembered” by the “fact” that must be “remembered” by the system and cannot or is not computed or system and cannot or is not computed or derived mechanicallyderived mechanically

37

ERD Notation

object1object1

object2object2

object2object2

(0, m)(0, m) (1, 1)(1, 1)

object1object1 relationshiprelationship

One common form:One common form:

(0, m)(0, m)

(1, 1)(1, 1)

relationshiprelationship

Another common form:Another common form:

attributesattributes

38

Building an ERD

Level 1—model all data objects (entities) and their “connections” to one another

Level 2—model all entities and relationships Level 3—model all entities, relationships, and

the attributes that provide further depth Other ERD – data object type hierarchy,

associated data object

Level 1—model all data objects (entities) and their “connections” to one another

Level 2—model all entities and relationships Level 3—model all entities, relationships, and

the attributes that provide further depth Other ERD – data object type hierarchy,

associated data object

39

The ERD: An Example

(1,1)(1,1) (1,m)(1,m)placesplacesCustomerCustomer

requestrequestfor servicefor service

generatesgenerates(1,n)(1,n)

(1,1)(1,1)

workworkorderorder

workworktaskstasks

materialsmaterials

ConsistsConsistsofof

listslists

(1,1)(1,1)(1,w)(1,w)

(1,1)

(1,i)(1,i)

selectedselectedfromfrom

standardstandardtask tabletask table

(1,w)(1,w)

(1,1)(1,1)

40

Creating a Flow ModelCreating a Flow Model

41

The Flow Model

Every computer-based system is an Every computer-based system is an information transform ....information transform ....

computercomputerbasedbased

systemsysteminputinput outputoutput

42

Flow Modeling Notation

external entityexternal entity

processprocess

data flowdata flow

data storedata store

43

External Entity

A producer or consumer of dataA producer or consumer of data

Examples: a person, a device, a sensor Examples: a person, a device, a sensor or computer-based systemor computer-based system

Data must always originate Data must always originate somewhere and must always be sent somewhere and must always be sent to somethingto something

44

Process

A data transformer (changes inputA data transformer (changes inputto output)to output)

Examples: compute taxes, determine Examples: compute taxes, determine area, format report, display graph area, format report, display graph

Data must always be processed in some Data must always be processed in some way to achieve system functionway to achieve system function

45

Data Flow

Data flows through a system, beginningData flows through a system, beginningas input and be transformed into output.as input and be transformed into output.

computecomputetriangle triangle

areaarea

basebase

heightheight

areaarea

46

Data Stores

Data is often stored for later use.Data is often stored for later use.

look-uplook-upsensorsensor

datadata

sensor #sensor #

report requiredreport required

sensor #, type, sensor #, type, location, agelocation, age

sensor datasensor data

sensor numbersensor number

type, type, location, agelocation, age

47

DFD Guidelines

all icons must be labeled with meaningful names the DFD evolves through a number of levels of

detail always begin with a context level diagram (also

called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic

48

Constructing a DFD—I

review ERD to isolate data objects and grammatical parse to determine “operations”

determine external entities (producers and consumers of data)

create a level 0 DFD (fundamental system model, context model)

49

Level 0 DFD Example

useruserprocessing processing

requestrequest

videovideosourcesource NTSCNTSC

video signalvideo signal

digitaldigitalvideovideo

processorprocessor

requestedrequestedvideovideosignalsignal

monitormonitor

50

Constructing a DFD—II

write a narrative describing the transform parse to determine next level transforms “balance” the flow to maintain data flow

continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio

51

The Data Flow Hierarchy

PPaa bbxx yy

p1p1p2p2

p3p3p4p4 55

aa

bb

cc

ddee

ff

gg

level 0level 0

level 1level 1

52

Flow Modeling Notes

each bubble is refined until it does just one thing

the expansion ratio decreases as the number of levels increase

most systems require between 3 and 7 levels for an adequate flow model

a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

53

DFDs: A Look Ahead

Maps intoMaps intoanalysis modelanalysis model

design modeldesign model