requirements analysis

59
1 Chapter 6-7 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides - http://www.informatics.sussex.ac.uk/users/lb203/se/ SE04.pdf - Jochen Rick’s slides from GA Institute of Technology Coming up: Requirements Analysis

Upload: kipling

Post on 23-Jan-2016

15 views

Category:

Documents


0 download

DESCRIPTION

- PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Requirements Analysis

1

Chapter 6-7Analysis Modeling

Adapted by Dan Fleck from:- Roger Pressman’s Slides- http://www.informatics.sussex.ac.uk/users/lb203/se/SE04.pdf- Jochen Rick’s slides from GA Institute of Technology- http://webfuse.cqu.edu.au/Courses/aut2001/95169/

Extra_Examples/DFD_Example_1/- System Analysis and Design slides edited by Yale Braunstein

Coming up: Requirements Analysis

Page 2: Requirements Analysis

2

Requirements Analysis Requirements analysis

specifies software’s operational characteristics indicates software's interface with other system elements establishes constraints that software must meet

Requirements analysis allows the software engineer (called an analyst or modeler in this role) to: elaborate on basic requirements established during earlier

requirement engineering tasks build models that depict user scenarios, functional activities,

problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.

Coming up: Analysis Phase: What is it?

Page 3: Requirements Analysis

3

Analysis Phase: What is it?

systemdescription

analysismodel

designmodel

Three objectives:

• To describe what the customer requires

• To establish a basis for the creation of a software design

• To define a set of requirements that can be validated once the software is built

Three objectives:

• To describe what the customer requires

• To establish a basis for the creation of a software design

• To define a set of requirements that can be validated once the software is built

Coming up: Elements of the Analysis Model

Page 4: Requirements Analysis

4

Elements of the Analysis Model

Use-case diagrams

Use cases - text

Activity Diagrams

Swim lane diagrams

Scenario-based elements

Class diagrams

Analysis Packages

CRC Models

Collaboration Diagrams

Class-based elements

Data-flow diagrams

Control flow diagrams

Processing narratives

Flow-oriented elements

State diagrams

Sequence diagrams

Behavioral elements

Analysis Model

Coming up: Elements of the Analysis Model

Page 5: Requirements Analysis

5

Elements of the Analysis ModelScenario-based elements

Class-based elements

Flow-oriented elements

Behavioral elements

Coming up: Class-Based Modeling

High level idea of the system from user’s or a functional perspective

How information flows throughout the system (data and control flow)

How the system responds to external stimuli

Static view of the system and how the different parts are related. Tries to show standard ideas of object oriented development

Page 6: Requirements Analysis

6

Class-Based Modeling Identify analysis classes by examining

the problem statement Use a “grammatical parse” to isolate

potential classes Identify the attributes of each class Identify operations that manipulate the

attributes

Coming up: Grammatical Parsing

Page 7: Requirements Analysis

7

Grammatical Parsing

Write an informal description of the problem. The

customer requirements document is one such

description.

Underline all nouns in the description

Decide which of these are really objects which the

project requires and organize them in related

clusters

Coming up: Grammatical Parsing

Page 8: Requirements Analysis

8

Grammatical ParsingUniversity Bank will be opening in Oxford, Mississippi, in January,

2000. We plan to use a full service automated teller machine (ATM)

system.The ATM system will interact with the customer through a

display screen, numeric and special input keys, a bankcard reader, a

deposit slot, and a receipt printer.Customers may make deposits,

withdrawals, and balance inquires using the ATM machine, but the

update to accounts will be handled through an interface to the

Accounts system.Customers will be assigned a Personal Identification

Number (PIN) and clearance level by the Security system. The PIN can

be verified prior to any transaction.In the future, we would also like to

support routine operations such as a change of address or phone

number using the ATM

Coming up: Grammatical Parsing

Page 9: Requirements Analysis

9

Grammatical Parsing University Bank will be opening in Oxford, Mississippi, in

January, 2000. We plan to use a full service automated teller machine (ATM) system.The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM

Coming up: Typical Classes (a reminder)

Page 10: Requirements Analysis

10

Typical Classes (a reminder) External entities - printer, user, sensor Things - 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 or loading dock) Structures (e.g., sensors, four-wheeled vehicles, or computers)

But, how do we select classes?

Coming up: Selecting Classes—Criteria

Page 11: Requirements Analysis

11

Selecting Classes—Criteria

needed services – needed services – operations that change the attributesoperations that change the attributes

multiple attributes – multiple attributes – if it is only one attribute, if it is only one attribute, probably should be part of another classprobably should be part of another class

common attributes – common attributes – common things for all instances of a classcommon things for all instances of a class

common operations – common operations – for all instances of the classfor all instances of the class

essential requirements – essential requirements – appear in the PROBLEM space appear in the PROBLEM space (remember we’re doing analysis modeling!)(remember we’re doing analysis modeling!)

retained information – retained information – information about it must be rememberedinformation about it must be remembered

Coming up: Selecting Classes—Example

Page 12: Requirements Analysis

12

Selecting Classes—Example

needed servicesneeded services

multiple attributesmultiple attributes

common attributescommon attributes

common operationscommon operations

essential requirementsessential requirements

retained informationretained information

Coming up: CRC Cards

ATMUser

Yes

Yes

Yes

Yes

Yes

Yes

PinNum

Yes

No

No

Yes

Maybe

Yes

Page 13: Requirements Analysis

CRC Cards

Is there a better way to find classes?

Sure… Class Responsibility Collaborator Cards (see CRC slides and book pg 173)

Coming up: Elements of the Analysis Model

13

Page 14: Requirements Analysis

14

Use-case diagrams

Use cases - text

Activity Diagrams

Swim lane diagrams

Scenario-based elements

Class diagrams

Analysis Packages

CRC Models

Collaboration Diagrams

Class-based elements

Data-flow diagrams

Control flow diagrams

Processing narratives

Flow-oriented elements

State diagrams

Sequence diagrams

Behavioral elements

Analysis Model

Elements of the Analysis Model

Coming up: The ERD: An Example

Page 15: Requirements Analysis

15

The ERD: An Example

placesplacesCustomerCustomer

requestrequestfor servicefor service

generatesgenerates workworkorderorder

workworktaskstasks

materialsmaterials

consistsconsistsofof

listslists

(1,1)selectedselected

fromfrom

standardstandardtask tabletask table

Coming up: Data Modeling

Page 16: Requirements Analysis

16

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

Coming up: What is a Data Object?

Page 17: Requirements Analysis

17

What is a Data Object?

ObjectObject ——something that is described by a setsomething that is described by a setof attributes (data items) and that will be of attributes (data items) and that will be manipulated within the software (system)manipulated within the software (system)

each each instanceinstance of an object (e.g., a book) 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 systemeach plays a necessary role in the systemi.e., the system could not function without i.e., the system could not function without access to instances of the objectaccess to instances of the object

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

What are some typical data objects?

Coming up: Typical Data Objects

Page 18: Requirements Analysis

18

Typical Data Objects

external entitiesexternal entities (printer, user, sensor)(printer, user, sensor)thingsthings (e.g, reports, displays, signals) (e.g, reports, displays, signals) occurrences or eventsoccurrences or events (e.g., interrupt, alarm)(e.g., interrupt, alarm)rolesroles (e.g., manager, engineer, salesperson)(e.g., manager, engineer, salesperson)organizational unitsorganizational units (e.g., division, team)(e.g., division, team)placesplaces (e.g., manufacturing floor) (e.g., manufacturing floor)

structuresstructures (e.g., employee record)(e.g., employee record)

Coming up: Data Objects and Attributes

Page 19: Requirements Analysis

19

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

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

How do data objects differ from OO classes or do they?

Coming up: What is a Relationship?

Page 20: Requirements Analysis

20

What is a Relationship?

relationshiprelationship ——indicates “connectedness”; indicates “connectedness”; a "fact" that must be "remembered" a "fact" that must be "remembered" by the system and cannot or is not computed by the system and cannot or is not computed or derived mechanicallyor derived mechanically

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

Coming up: Crow’s Foot Style ERD

Page 21: Requirements Analysis

21

Crow’s Foot Style ERD

Coming up: ERD Example: From http://www.b2ttraining.com

The ERD: Other style’s exist. There are a few, but most are more confusing and less common than Crow’s foot. Depending on who you ask this was invented by Dr. Gordon Everest or Clive Finkelstein.

Teacher Class

Student Address

Teacher teaches 0 to many classes

Classes have 1 and only 1 teacher

Students have 1 to many addressesAn address is for zero to one student (addresses may not be associated with multiple students)

First “thing” denotes optional or mandatory. Second “thing” denotes cardinality (one or many)

Page 22: Requirements Analysis

22

Coming up: Elements of the Analysis Model

ERD Example: From http://www.b2ttraining.com

Page 23: Requirements Analysis

23

Use-case diagrams

Use cases - text

Activity Diagrams

Swim lane diagrams

Scenario-based elements

Class diagrams

Analysis Packages

CRC Models

Collaboration Diagrams

Class-based elements

Data-flow diagrams

Control flow diagrams

Processing narratives

Flow-oriented elements

State diagrams

Sequence diagrams

Behavioral elements

Analysis Model

Elements of the Analysis ModelOnward to data flow diagrams!

Coming up: Flow-Oriented Modeling

Page 24: Requirements Analysis

24

Flow-Oriented Modeling

•Represents how data objects are transformed at they Represents how data objects are transformed at they move through the systemmove through the system

•A A data flow diagram (DFD)data flow diagram (DFD) is the diagrammatic form is the diagrammatic form that is used to show how data is transformed as it moves that is used to show how data is transformed as it moves through the systemthrough the system

•Considered by many to be an ‘old school’ approach, Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement system that is unique—it should be used to supplement other analysis model elementsother analysis model elements

Coming up: The Flow Model

Page 25: Requirements Analysis

25

The Flow Model

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

computercomputerbasedbased

systemsystemdata inputdata input outputoutput

Coming up: Flow Modeling Notation

Page 26: Requirements Analysis

26

Flow Modeling Notation

external entityexternal entity

processprocess

data flowdata flow

data storedata store

Coming up: External Entity

Page 27: Requirements Analysis

27

External Entity

A producer or consumer of dataA producer or consumer of data

Examples: a person, a device, a sensorExamples: a person, a device, a sensor

Data must always originate somewhereData must always originate somewhereand must always be sent to somethingand must always be sent to something

Coming up: Process

Page 28: Requirements Analysis

28

Process

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

Examples: compute taxes, determine area,Examples: compute taxes, determine area,format report, display graph 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

Coming up: Data Flow

Page 29: Requirements Analysis

29

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

Coming up: Data Stores

Key thought: In a DFD the DATA is what is moving on the arrows!Key thought: In a DFD the DATA is what is moving on the arrows!

Page 30: Requirements Analysis

30

Data Stores

DataData is often stored for later use.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

Coming up: Data Flow Diagramming:Guidelines

In a real system what things are “Data Stores”?In a real system what things are “Data Stores”?

Page 31: Requirements Analysis

31

Data Flow Diagramming: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 ensure that you show DATA moving through the

system (not control)

Coming up: Constructing a DFD—I

Page 32: Requirements Analysis

32

Constructing a DFD—I

review the data model to isolate data objects and use a grammatical parse to determine “operations”

determine external entities (producers and consumers of data)

create a level 0 DFD

Coming up: Level 0 DFD Examples

Page 33: Requirements Analysis

33

Level 0 DFD Examplesuseruser

processing processing requestrequest

videovideosourcesource NTSCNTSC

video signalvideo signal

digitaldigitalvideovideo

processorprocessor

requestedrequestedvideovideosignalsignal

monitormonitor

Coming up: Constructing a DFD—II

Page 34: Requirements Analysis

34

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

Coming up: The Data Flow Hierarchy

Page 35: Requirements Analysis

35

The Data Flow Hierarchy

PPaa bbxx yy

p1p1p2p2

p3p3p4p4 55

aa

bb

cc

ddee

ff

gg

level 0level 0

level 1level 1

Coming up: Example DFD: Level 1

Page 36: Requirements Analysis

36

Example DFD: Level 1

Coming up: DFD: A practical example

Page 37: Requirements Analysis

DFD Example Example from

http://ldtconsultinginc.com/

Can we add labels to unlabled data flows?

Is this a level 0 diagram?

Coming up: Lets Try It

38

Page 38: Requirements Analysis

Lets Try It

Lets create a DFD for A carpet cleaning business A web-based order processing system for a

computer store An address book for an iPhone

Coming up: Flow Modeling Notes

39

Page 39: Requirements Analysis

40

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)

The things that move on the arrows are DATA!

Coming up: Elements of the Analysis Model

Page 40: Requirements Analysis

41

Use-case diagrams

Use cases - text

Activity Diagrams

Swim lane diagrams

Scenario-based elements

Class diagrams

Analysis Packages

CRC Models

Collaboration Diagrams

Class-based elements

Data-flow diagrams

Control flow diagrams

Processing narratives

Flow-oriented elements

State diagrams

Sequence diagrams

Behavioral elements

Analysis Model

Elements of the Analysis Model

Oh behave!

Coming up: Behavioral Modeling

Page 41: Requirements Analysis

42

Behavioral Modeling The behavioral model indicates how software will

respond to external events or stimuli. To create the model, the analyst must perform the following steps:

Evaluate all use-cases to fully understand the sequence of interaction within the system.

Identify events that drive the interaction sequence and understand how these events relate to specific objects.

Create a sequence diagram for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy and

consistency.

Coming up: State Representations

Page 42: Requirements Analysis

43

State Representations

In the context of behavioral modeling, two different characterizations of states must be considered: the state of each class as the system performs its function

and the state of the system as observed from the outside as the

system performs its function

What are some states for an ATM machine? Washing machine? Cell phone?

Coming up: State Diagram for the ControlPanel Class

Page 43: Requirements Analysis

44

State Diagram for the ControlPanel Class

reading

locked

selecting

passwordentered

comparing

password = incorrect& numberOfTries < maxTries

password = correct

activation successful

key hit

do: validatePassword

numberOfTries > maxTries

timer < lockedTime

timer > lockedTime

Coming up: State Diagram Details

Page 44: Requirements Analysis

State Diagram Details

Coming up: The States of a System

45

State Name (verb in current tense)

(Optional) actions happening during state

Name Examples:sortingvalidatingupdating status…

[age > 20]

[age <= 20]

Guards: Use to describe event that causes a state transition happens (ALL transitions should have guards)

[age <= 20]/setFlag(false)

Action: If something happens while transitioning to another state. (Optional)

Page 45: Requirements Analysis

46

The States of a System state—a set of observable

circumstances that characterizes the behavior of a system at a given time

state transition —the movement from one state to another

event —an occurrence that causes the system to exhibit some predictable form of behavior

action —process that occurs as a consequence of making a transition

Coming up: Behavioral Modeling

Page 46: Requirements Analysis

47

Behavioral Modeling

make a list of the different states of a system (How does the system behave?)

indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action

draw a state diagram or a sequence diagram

Coming up: State Diagram - Lets Try It!

Page 47: Requirements Analysis

48

State Diagram - Lets Try It!You are designing a traffic light system for this intersection.

Draw a state diagram showing the different states and how they transition.

North

South

East

West

Coming up: Elements of the Analysis Model

Page 48: Requirements Analysis

49

Use-case diagrams

Use cases - text

Activity Diagrams

Swim lane diagrams

Scenario-based elements

Class diagrams

Analysis Packages

CRC Models

Collaboration Diagrams

Class-based elements

Data-flow diagrams

Control flow diagrams

Processing narratives

Flow-oriented elements

State diagrams

Sequence diagrams

Behavioral elements

Analysis Model

Elements of the Analysis Model

Coming up: Object Oriented Analysis (OOA)

Page 49: Requirements Analysis

50

Object Oriented Analysis (OOA)

The intent of OOA is to define all classes (and the relationships and behavior associated with them) that are relevant to the problem to be solved. For that, a number of tasks must occur:

1. Classes must be identified (i.e., attributes and methods)

2. A class hierarchy is defined

3. Object-to-object relationships should be represented

4. Object behavior must be modeled

5. Tasks 1 through 4 are reapplied iteratively

Coming up: Object-Oriented Concepts

Page 50: Requirements Analysis

51

Object-Oriented Concepts What are the basic object oriented

concepts?

Coming up: Object-Oriented Concepts

Page 51: Requirements Analysis

52

Object-Oriented Concepts What are the basic object oriented

concepts? Classes and objects Attributes and operations Encapsulation and instantiation Inheritance

The analysis model is designed to help you make “good” choices

Coming up: Object-Oriented Concepts

Page 52: Requirements Analysis

53

Object-Oriented Concepts What helps you determine if

something should be a class or an attribute?

What helps you determine needed operations?

How does the analysis model make sure your requirements are correct?

Coming up: Elements of the Analysis Model

Page 53: Requirements Analysis

54

Elements of the Analysis ModelScenario-based elements

Class-based elements

Flow-oriented elements

Behavioral elements

Coming up: Analysis Model Rules of Thumb

High level idea of the system from user’s or a functional perspective

How information flows throughout the system (data and control flow)

How the system responds to external stimuli

Static view of the system and how the different parts are related. Tries to show standard ideas of object oriented development

Page 54: Requirements Analysis

55

Analysis Model Rules of Thumb

The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high.

Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.

Delay consideration of infrastructure and other nonfunctional models until design

Minimize coupling throughout the system. Be certain that the analysis model provides value to all

stakeholders. Keep the model as simple as it can be.

Coming up: Analysis Phase: What is it?

Page 55: Requirements Analysis

56

Analysis Phase: What is it?

systemdescription

analysismodel

designmodel

Three objectives:

• To describe what the customer requires

• To establish a basis for the creation of a software design

• To define a set of requirements that can be validated once the software is built

Three objectives:

• To describe what the customer requires

• To establish a basis for the creation of a software design

• To define a set of requirements that can be validated once the software is built

Coming up: Writing the Software Specification

Page 56: Requirements Analysis

57

Writing the Software Specification

Everyone knew exactly what had to be done until someone wrote it down!

Coming up: Specification Guidelines

Read the last three

slides on your own

Read the last three

slides on your own

Page 57: Requirements Analysis

58

Specification Guidelinesuse a layered format that provides increasing detail as the "layers" deepen

use consistent graphical notation and apply textual terms consistently (stay away from aliases)

be sure to define all acronyms

be sure to include a table of contents; ideally, include an index and/or a glossary

write in a simple, unambiguous style (see "editing suggestions" on the following pages)

always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?"

Coming up: Specification Guidelines

Page 58: Requirements Analysis

59

Specification GuidelinesBe on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that ...

Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ...

When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as

Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex?

Beware of vague verbs such as handled, rejected, processed, ...

Beware "passive voice" statements e.g., The parameters are initialized. By what?

Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag?

Coming up: Specification Guidelines

Page 59: Requirements Analysis

60

Specification GuidelinesWhen a term is explicitly defined in one place, try substituting the definition forother occurrences of the term

When a structure is described in words, draw a picture

When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure

When symbolic equations are used, try expressing their meaning in words

When a calculation is specified, work at least two examples

Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never

Search behind certainty statements—be sure restrictions or limitations are realistic

End of presentation