Intro to Software Engineering - Requirements Analysis

Requirements analysis

McGill ECSE 321Intro to Software Engineering

Radu Negulescu

Fall 2003

McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 2

About this module

Analysis: transform a “linear” list of requirements into a structured model of the application

Serves multiple purposes

• Understand the requirements

• Consolidate the requirements by revealing inconsistencies

• Prepare the design stage by identifying compulsory elements


Static models

Represent static structure

• Static vs. dynamic: fixed vs. variable over lifetime of system

Class diagrams

• Design: classes (sets of objects) and relationships

• Analysis: concepts (sets of objects) and relationships

Object diagrams

• Snapshot of data/concepts in the system

Deployment diagrams

Entity-relationship diagrams


Class diagrams

Class descriptor

• Three predefined compartments: name, attributes, operations

• Some compartments may be omitted or empty

• Optional list compartments or named compartments

• Attributes: name, type (optional), visibility (private (-), public (+), protected (#))

ObservationHistory

-patientName: String#obsList

+addObservation()+getObservation()+setPatientInfo(String)

ObservationHistory

Responsibilities--Store observations--Check validity--Search observationsUpdatesRN, 3 Jan. 2010

ObservationHistory


Generalization

Generalization

• In any model: “is-a” relationship

• In a model of a program: subtyping (“extends” or “implements” in Java)

Observation

#timeAndDate: Date

+originatorName()+observType()…

Measurement

-quantity: int

…

Category

-value: String

…


Aggregation

Aggregation

• “has-a” relationship

Pictorial representation:

• Reference field:

• Value field:

Observation

#timeAndDate: Date


Measurement

-quantity: int

…

Category

-value: String

…

ObservationHistory

-patientName: String



Multiplicities

Multiplicities

• How many objects of one type correspond to one object of the other type

• E.g. 1; 5; *; 0..1; 1..*; 5, 8..17

Observation

#timeAndDate: Date


* 1

Measurement

-quantity: int

…

Category

-value: String

…

ObservationHistory

-patientName: String



Associations

Associations

• Represent navigability: “can go from A to B”Method invocation (a method of A calls a method of B)Reference (A has a reference/pointer to B)Containment (A contains a copy of B)Other links stored in the rest of the system

• Thus, aggregation is a particular case of association

• To an association, we can assign:Label, directionalAttributes, as for a class

• To each association end, we can assign:Multiplicity or multiplicity rangeRole: string describing how the related objects relate in the association

• It is possible to indicate constraints between associations


Static analysis models

UML class diagrams could represent the problem domain

• As opposed to the system being developed

• E.g. email-based auction systemBids and notifications sent by email

CommandManagerauctionStatesendMailreceiveMailtimeout

AuctioncrtPricecompareBidsetCrtBidgetCrtBid

BidderemailAddr

IteminitialPrice

crtWinner

1

*

compareBidsetCrtBid

1 1

1

Messagetextaddr

11

crtBidwarningclosure

getCrtBid

1

* 1

sendMailreceiveMail, timeout



UML class diagrams could represent parts of a physical system

• As opposed to the program or software

• E.g. automated radio channel tuner

Receiver

SignalPresent()SetFrequency()

Dial

SeekNext()SeekPrev()Program1()Program2()Program3()

Frequency1 1



Class diagrams could represent concepts

Consider a “software piano” project

• What exactly is meant by a “piano”?A piano is a keyboard instrumentA piano is an instrument with a keyboard...

Piano

Keyboard Instrument

Keyboard1 1

Piano

Musical Instrument

Keyboard1 1


Object diagrams

Elements

• ObjectsProgramReal-worldVirtual

• AttributesTypes (optional)Values (optional)

• RelationshipsAssociationAggregation

Usage

• Snapshot of the dataAnalysis vs. design

Jazz Rock Salsa

...

UIWindow

RockPane

PopPane

SalsaPane

Tab1:Tab

Text = “Jazz”

Tab2:Tab

Text = “Rock”

Tab3:Tab

Text = “Salsa”


Class diagrams vs. object diagrams

An object diagram is a class diagram with one object per class

Example class diagram [BD]:

Example object diagram [BD]:

12

11

11

11

SimpleWatch

Display Battery TimePushButton

SimpleWatch

Display Battery TimeRightButton

LeftButton


Sequence diagrams

Pictorial representation of one scenario

• Objects are arranged approximately in the order of involvement, usually starting with an actor

• Each object has a lifeline

• Messages: method invocations

• The time axis is vertical, and indicates order of messages

• Return from a call is usually not represented

measure

aTimer aMeasWithRangeaMonitor

measure

notify

create

anAlarm

alarmCheck

alarmSound

alarmCheck

anotherMeasWithRange

create


Sequence diagrams

Focus of control: time when an object is “alive”


measure

notify

createalarmCheck


Sequence diagrams

Extensions for representing several scenarios

• Iteration: *op()

• Condition: [i>0]op()


* measure

notify

create

anAlarm

alarmCheck

[emergency] alarmSound


Collaboration diagrams

Similar to sequence diagrams, except that

• Objects can be placed anywhere on the sheet

• The time order of messages is given by their numbers

Semantically equivalent to sequence diagrams

• Can be converted from one form to the other

• Interaction diagrams: common term for either form

• E.g. convert the sequence diagram from a previous slide:

aTimer

aMeasWithRangeaMonitor

2: measure

1: notify

3: create4: alarmCheck

anAlarm

5: alarmSound

anotherMeasWithRange6: create7: alarmCheck


Consistency: dynamic vs. static models

When used to illustrate system behaviors, collaboration/sequencediagrams must be consistent with static models of the system

parent:expr

left:expr

1:evaluate

right:expr

2:evaluate

exprevaluate*

1


Consistency: dynamic vs. static models

aTimer


2: measure

1: notify

3: create4: alarmCheck

anAlarm

5: alarmSound

anotherMeasWithRange6: create7: alarmCheck

Timer

MeasWithRangeMonitor

measure

create

Alarm

alarmSound1

*

*

*

1

1

alarmCheck

notify1

1

1

1


Hierarchical statecharts

Specific notations have been introduced to model high-level behavior

• Nested states: A transition from the superstate = a transition from each substateA transition to the superstate = a transition to the local initial substate

• Concurrent states:Several threads of controlSynchronization on entry and exit of the superstate


Example: nesting

Statecharts are handy for modeling parts of a software system, such as a user interface

• Flat statechart

• Hierarchical statechart

Panel1Active Panel2ActiveclickTab2

clickTab1

Panel3ActiveclickTab1 clickTab3 clickTab3 clickTab2

Panel1Active Panel2Active

Panel3Active

clickTab1

clickTab3

clickTab2

Tab 1 Tab 2 Tab 3

Panel 1

clickTab3

clickTab2clickTab1


Example: concurrency

Equivalent semantics

displayform

indicatecompletion

enter date

enter card

enter name

…

displayform

indicatecompletion

enter date

enter card

enter name

…


Example: concurrency and nesting

Equivalent behaviors:

a b

d e h i

j k

Off

Right

None

Position

Head

Fog

f gLeft

On

d e

f g

R,P

N,P

L,P

d e

f g

R,H

N,H

L,H

d e

f g

R,F

N,F

L,F

Off

a

bhi

jk

hi

jk

hi

jk

bb

b

bb

b

bb


Consistency: statecharts vs. scenarios

State machines

• Transitions represent message passing

• One statechart can represent several scenarios

aTimer


2: measure

1: notify

3: create 4: alarmCheck

anAlarm

5: alarmSound

anotherMeasWithRange6: create 7: alarmCheck

notify measure

createMeasurement

alarmCheck

alarmCheck createMeasurement

alarmSoundcreateMeasurement


Transition labels

Transitions: trigger(parameters)[guard]/actions^events

• “trigger” is the event, action, or message that triggered the transition

• “parameters” represent data values associated to the event

• “guard” is a Boolean condition that must evaluate true for the transition to occur

• “actions” is a list of actions performed as a result of the transition, such as invoking methods of other objects

• “events” is a list of events occurring in other parts of the system as a result of the transition

• any of these fields may be missing

Examples:clickTab1(xCoord,yCoord,time)[tab1Enabled] / Tabs.showTab(Tab1)^beep,flashclickTab2/Tabs.showTab(Tab2)


Example: guards

E.g.

selectpurchase

displayform

enter date

indicatecompletion

[complete] /displayReceipt

dis

pla

ying

cart

confirmtransaction

[incomplete] /restore

enter card

enter name


Transition labels

Transitions inside a state can be specified more compactly as textb

• Syntax: condition/action

Conditions can be:

• Entry: executed upon entering the state

• Exit: executed upon exiting the state

• Do: executed at random times while in that state

• Other events


Example: transition labels

SetTime

entry/blink hours

pressButton1/blink next number

pressButton2/increment current number

exit/stop blinking

blink hours

stop blinking

Entering

Acting pressButton1/blink next number

pressButton2/increment current number

SetTime


Activity diagrams

Activity diagrams are another formalism for specifying behavior

• Each activity takes time

• Transitions

• Synchronization

• Decisions


Example: activity diagram

sendGreeting

ringOperator

[key==0]

[key==1]

ringService

[key!=0 && key!=1]

playAdInfo

talkOperator

talkServicehangup

hangup


Activity diagrams

Caveat: not object-oriented!

• Fix: “swimlanes”

• Example [BD]:

ArchiveIncidentOpenIncident

DocumentIncident

AllocateResourcesCoordinateResources

ArchiveIncident

Dispatcher

FieldOfficer

OpenIncident

DocumentIncident

AllocateResourcesCoordinateResources


Diagram organization

Comments in diagrams

• Standard shape box

• May be inserted in any UML diagram

It’s not a bug, it’s a feature!

doctor or nurse

retrieve observation history

backup observation history

archive

new observation history


Diagram organization

Packages

• Group related elements together

• Standard shape

• Applicable to several models: class diagram, use case diagram, deployment diagram, etc.

ObsArchive TimerSubsystem


Object identification

Entity objects

• Roughly correspond to entities from the real world

• E.g. time, location, map, …

Boundary objects

• Define the interface of the system

• E.g. menu, button, shopping cart

Control objects

• Control the interactions with the actorsTracking the progress of a use case or a part of a use caseTracking the state of an actor

• E.g. user registration, phone connection


Object identification

Example: email-based auction system

CommandManagerauctionStatesendMailreceiveMailtimeout


BidderemailAddr

IteminitialPrice

crtWinner

1

*

compareBidsetCrtBid

1 1

1

Messagetextaddr

11


getCrtBid

1

* 1

sendMailreceiveMail, timeout

Boundary Control Entity

Entity Entity?Control?


Natural language analysis

Abbott’s rules:

• Proper noun: entity object, actor instance

• Common noun: class, actor, attribute

• Doing verb: operation, method

• Being verb: generalization

• Having verb: aggregation

• Modal verb: constraint

• Adjective: attribute


Natural language analysis

Limitations:

• Imprecision, dependency on style of writingE.g., compare:

“the TV set shall allow a selection of channels”“the TV set shall allow selection of channels”“the TV set shall allow users to select channels”

• There are more nouns than relevant classesE.g., “minutes” is as a noun, but it should be an attribute of a “Time” classSort out attributes, synonyms

• Many important entity classes are not explicitly mentioned, but can be inferred

E.g., a “transaction” class in a point-of-sale programE.g., a “coordinates” class in Satwatch


Identifying entity objects

Heuristics for identifying entity objects: similar to the initial analysis objects

• Recurring nouns

• Terms that need clarification

• Real-world entities and processes tracked

• Data sources or sinksActions: “command”, “message”, ...

• Avoid interface artifacts (boundary objects!)


Identifying entity objects

Textual clues: a noun in the textual specification of a program can be an object (O), class (C), actor (A), attribute (F), synonym of another noun (S), or of no concern to the system (N)

Example: “A city hall(N) commissions your company(N) to develop RoadRunner(O), a web-based system(S RoadRunner) to allow the citizens(A) to report the presence(N) of potholes(C) in the public roads(C). A report(C) must contain the following information(N) for each reported pothole: size(N) of the pothole (width(F), depth(F)), location(N) (street address(F)), and, optionally, a textual comment(F). RoadRunner also displays the status(F) of the repair work(C) for each pothole, as determined by the dispatchers(A) from the city hall: under assessment(N), assigned, work in progress(N), finished. The repair status of each pothole is updated simultaneously in all reports containing that pothole, and can be viewed by the public(S citizen).”


Identifying boundary objects

Specify actor interactions in an interface-neutral form

Only general aspects of the user interface:

• Do: form, view, dialog, button

• Don’t: drawing ruler, load button, frame, shadow

Example: the ECSE 321 course web page

• Do: page, hyperlink, frame

• Don’t: welcome page, menu frame, content frame, image file

Heuristics:

• System inputs: forms, windows

• System outputs: notices, messages

• Avoid visual aspects: allow some artistic freedom!


Identifying control objects

Collect info from the boundary and dispatch it to the entity objects

• Track status of interaction

• Usually not mentioned in the problem description

Examples:

• Sequencing of forms, screens presented to user

• Undo and history queues

• Event listener objects

Heuristics:

• Status of a use case

• Status of an actor in a use case

• User sessions

• If unclear, revise the use cases themselves!


Identifying associations

Possible starting point: scenarios, sequence diagrams

Heuristics for identifying associations

• Natural language cues: Manages, reports to, is triggered by, talks toAggregation: has, is part of, is contained in, includes

• Name associations and roles precisely

• For each class, examine the sequence of associations that need to be traversed to reach an instance of that class

• Eliminate (or carefully consider) redundant associations E.g. from [BD]

• Determine multiplicities only after the associations are stable

* 1writesauthor document

1

11

1triggersreports

FieldOfficer EmergencyReport

Incident Redundancy => inconsistency?


Identifying attributes

Attributes are properties of individual objects

• Only properties relevant to the system should be considered

Attributes represent the least stable part of the model

• Attributes are highly volatile, low riskEnlightened procrastination!

Heuristics:

• Examine possessive phrases

• Think of stored state

• Pay more attention to entity attributes than control or boundary attributes

• Leftover entity classes


Analysis vs. design models

Absence of implementation bias

• Focus on “what”, not “how”

• Logical view vs. physical view

• Focus on the problem, not a solutionThe problem elements stay the same for all possible solutions

Example:

HUGERAMdata: array[1T] of byteread(addr):datawrite(addr,data)

CACHEdata: array[128K] of byteread(addr):datawrite(addr,data)

DISKdata: array[64M] of byteread(addr):datawrite(addr,data)

16

1

CACHEdata: array[64K] of byteread(addr):datawrite(addr,data)

DISKdata: array[256M] of byteread(addr):datawrite(addr,data)

4

1


Analysis vs. design models

OO: smooth transition from “problem domain” to implementation

EmailAdaptor

sendMailreceiveMailinterpretMail

AuctionSessionCtrlauctionStatehandleLogonCmdinitiateAuctionhandleBidCmdtimeout

Timerdelayreset(delay)wakeup()

BidderLog

addBidderremoveBiddernotifyAll


BidderInfoemailAddrhandleNotif

IteminitialPricegetPricesetPrice

crtWinner

1

*1

*1

sendMail

handleCmd

create

1 *

timeout

reset

1 *

compareBidsetCrtBid

create

1 1

11

MessagetextaddrgetTextsetTextgetAddrsetAddr

11


set,get

receiveMail

wakeup

getCrtBid

1


Reviewing the analysis model

Analysis is done incrementally and iteratively

• Incrementally: add pieces of functionality

• Iteratively: revise previous work

• Per use case / segment of functionality

• Several review-and-revise cycles

For each increment

• Extend the model with new functionality

• Verify review criteriaUse a checklistRe-iterate for functionality from all previous increments!



Review criteria

• Consistency between analysis model and use cases“Walk through” the model for each use caseDoes each object have the necessary associations to access related objects?For each object, attribute, association: which use cases access it? create it? set it? traverse it?Auxiliary flows: maintenance, error, start-up/shut-down, application-specific, work-specific, …

• Description and naming of analysis model elementsMeaningful, understandable by usersConformant to Abbott’s rules and other conventionsUniform level of detail in the descriptions (glossary)

• Realism (feasibility): demonstrate by prototypes or feasibility studiesTarget novel features (not present in previous systems)Target non-functional requirements

• Absence of implementation biasTells you where to stop your analysis work!



E.g. email-based auction system

• Walkthroughs1. Receive mail – Bid – Send email to all bidders2. Timeout – Issue warning to all bidders3. Receive mail – Logon4. Set initial price – Notify all bidders

• Validate walkthroughs with the customerUse a UI scaffold if you can

• NamingAbbott’s rules: all classes, attributes, methodsConventions: …Ctrl class

• Realism: non-optimal, backup solutionsEmail adaptorTimer (as a backup solution)

• Absence of biasEach class, attribute, method: compulsory or not?


Reviewing a requirements specification

For each requirement

• Valid, corresponds to user need (no bias)

• Feasible, verifiable

• Clear (one standard interpretation, defined or self-explaining terms)

• If it is a use case, specifies entry and exit conditions

• Correct terms (problem-oriented, complete, accurate, proper length)

• Prioritized (importance, difficulty, technical and acceptance risk)

For the set of requirements as a whole

• Consistency among requirements (no contradictions)

• Consistency between requirements and models (walkthroughs)

• Defines each user/actor action at each interface state

• Covers non-functional requirements checklist

• Consistent style, section structure, cross-referencing and navigation


Beyond UML

Other representations for software:

• Traditional function-oriented notation: Entity-relationship diagrams (ERD), database schemas Data-flow diagrams (DFD)Call graphs (structure charts)Flow graphs, pseudocode

• Non-visual notationsRegular expressions, formal grammars, XMLAssertions, Z, OCL

• Various OO notations superceded by UMLBooch, Coad, Jacobson, Odell, Rumbaugh, Shlaer/Mellor…[Handout, fig. 1,2]

• Concurrent and distributed systemsPetri netsSpecification and Description Language (SDL)


Entity-relationship diagrams

The beginnings of ERD

• [Chen, 1976]

• Precursor to class diagrams

• No generalization, though

ERD elements

• Entities: information-holding structues

• Relationships: connections between entities

• Cardinalities: upper bounds

• Modalities: lower bounds

• Attributes: properties, adjectives,... associated to an entity

Examples: [Handout, fig. 3,4]


Dataflow diagrams

DFD: akin to activity diagrams in UML

• Less formal

• More elements

• Processes: activities (“tasks”), verbs in narrative

• External entities: actor instances

• Data stores: state-holding objects

Examples: [Handout, fig. 5]


Function-oriented analysis

Identifying entities

• Natural language analysisNouns (akin to identifying initial analysis objects)Same limitations

Identifying relationships

• Textual cues“Having” verbsTransitive verbs

• From DFDActivities


Function-oriented analysis

DFD: a task hierarchy

• Level-0 DFD: one bubble (and external entities)

• Level-1 DFD: expand the bubble into the main subsystemsTask identification from natural language description:

verbs processes (task bubbles)

• Successively refine some of the bubblesUntil design choices need to be made,

or until the algorithm level is reachedLevel balancing (“continuity”): the input and output data flows must be consistent across levels

E.g. [Handout, fig.6,7]


References

UML and other models

• BD 2.2.2, 2.4

• Sommerville 7.2.1, 7.3

Analysis element identification

• BD 5.2, 5.3.1, 5.3.2, 5.3.4, 5.4

Specifications review and sign-off

• BD 5.4.9, 5.5.5

UML links

• Complete UML specification http://www.omg.org/docs/formal/03-03-01.pdfSee Chapter 3: “UML notation guide”

• UML resource centerhttp://www.rational.com/uml/resources/documentation/index.jsp

Intro to Software Engineering - Requirements Analysis

Technology

Transcript of Intro to Software Engineering - Requirements Analysis