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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 3
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 4
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 5
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
…
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 6
Aggregation
Aggregation
• “has-a” relationship
Pictorial representation:
• Reference field:
• Value field:
Observation
#timeAndDate: Date
+originatorName()+observType()…
Measurement
-quantity: int
…
Category
-value: String
…
ObservationHistory
-patientName: String
+addObservation()+getObservation()+setPatientInfo(String)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 7
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
+originatorName()+observType()…
* 1
Measurement
-quantity: int
…
Category
-value: String
…
ObservationHistory
-patientName: String
+addObservation()+getObservation()+setPatientInfo(String)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 8
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 9
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 10
Static analysis models
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 11
Static analysis models
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 12
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”
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 13
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 14
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 15
Sequence diagrams
Focus of control: time when an object is “alive”
aTimer aMeasWithRangeaMonitor
measure
notify
createalarmCheck
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 16
Sequence diagrams
Extensions for representing several scenarios
• Iteration: *op()
• Condition: [i>0]op()
aTimer aMeasWithRangeaMonitor
* measure
notify
create
anAlarm
alarmCheck
[emergency] alarmSound
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 17
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 18
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 19
Consistency: dynamic vs. static models
aTimer
aMeasWithRangeaMonitor
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 20
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 21
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 22
Example: concurrency
Equivalent semantics
displayform
indicatecompletion
enter date
enter card
enter name
…
displayform
indicatecompletion
enter date
enter card
enter name
…
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 23
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 24
Consistency: statecharts vs. scenarios
State machines
• Transitions represent message passing
• One statechart can represent several scenarios
aTimer
aMeasWithRangeaMonitor
2: measure
1: notify
3: create 4: alarmCheck
anAlarm
5: alarmSound
anotherMeasWithRange6: create 7: alarmCheck
notify measure
createMeasurement
alarmCheck
alarmCheck createMeasurement
alarmSoundcreateMeasurement
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 25
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)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 26
Example: guards
E.g.
selectpurchase
displayform
enter date
indicatecompletion
[complete] /displayReceipt
dis
pla
ying
cart
confirmtransaction
[incomplete] /restore
enter card
enter name
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 27
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 28
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 29
Activity diagrams
Activity diagrams are another formalism for specifying behavior
• Each activity takes time
• Transitions
• Synchronization
• Decisions
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 30
Example: activity diagram
sendGreeting
ringOperator
[key==0]
[key==1]
ringService
[key!=0 && key!=1]
playAdInfo
talkOperator
talkServicehangup
hangup
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 31
Activity diagrams
Caveat: not object-oriented!
• Fix: “swimlanes”
• Example [BD]:
ArchiveIncidentOpenIncident
DocumentIncident
AllocateResourcesCoordinateResources
ArchiveIncident
Dispatcher
FieldOfficer
OpenIncident
DocumentIncident
AllocateResourcesCoordinateResources
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 32
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 33
Diagram organization
Packages
• Group related elements together
• Standard shape
• Applicable to several models: class diagram, use case diagram, deployment diagram, etc.
ObsArchive TimerSubsystem
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 34
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 35
Object identification
Example: email-based auction system
CommandManagerauctionStatesendMailreceiveMailtimeout
AuctioncrtPricecompareBidsetCrtBidgetCrtBid
BidderemailAddr
IteminitialPrice
crtWinner
1
*
compareBidsetCrtBid
1 1
1
Messagetextaddr
11
crtBidwarningclosure
getCrtBid
1
* 1
sendMailreceiveMail, timeout
Boundary Control Entity
Entity Entity?Control?
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 36
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 37
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 38
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!)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 39
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).”
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 40
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!
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 41
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!
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 42
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?
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 43
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 44
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 45
Analysis vs. design models
OO: smooth transition from “problem domain” to implementation
EmailAdaptor
sendMailreceiveMailinterpretMail
AuctionSessionCtrlauctionStatehandleLogonCmdinitiateAuctionhandleBidCmdtimeout
Timerdelayreset(delay)wakeup()
BidderLog
addBidderremoveBiddernotifyAll
AuctioncrtPricecompareBidsetCrtBidgetCrtBid
BidderInfoemailAddrhandleNotif
IteminitialPricegetPricesetPrice
crtWinner
1
*1
*1
sendMail
handleCmd
create
1 *
timeout
reset
1 *
compareBidsetCrtBid
create
1 1
11
MessagetextaddrgetTextsetTextgetAddrsetAddr
11
crtBidwarningclosure
set,get
receiveMail
wakeup
getCrtBid
1
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 46
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!
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 47
Reviewing the analysis model
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!
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 48
Reviewing the analysis model
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?
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 49
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 50
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)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 51
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]
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 52
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]
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 53
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 54
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]
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 55
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
Top Related