Uploaded byRadu_Negulescu
PDF, PPTX3,300 views

Intro to Software Engineering - Requirements Analysis

The document discusses requirements analysis and modeling techniques in software engineering. It introduces various modeling approaches like class diagrams, sequence diagrams, statecharts and activity diagrams that can be used to analyze and represent requirements. These modeling approaches help understand requirements, consolidate inconsistencies, and prepare for the design stage by identifying essential elements. Examples are provided to illustrate how different modeling constructs like classes, objects, relationships and behaviors can be represented.

Embed presentation

Download as PDF, PPTX
Requirements analysis McGill ECSE 321 Intro 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 observations Updates RN, 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, directional Attributes, as for a class • To each association end, we can assign: Multiplicity or multiplicity range Role: 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 system Bids and notifications sent by email CommandManager auctionState sendMail receiveMail timeout Auction crtPrice compareBid setCrtBid getCrtBid Bidder emailAddr Item initialPrice crtWinner 1 * compareBid setCrtBid 1 1 1 Message text addr 11 crtBid warning closure getCrtBid 1 * 1 sendMail receiveMail, 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 instrument A piano is an instrument with a keyboard ... Piano Keyboard Instrument Keyboard 1 1 Piano Musical Instrument Keyboard 1 1
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 12 Object diagrams Elements • Objects Program Real-world Virtual • Attributes Types (optional) Values (optional) • Relationships Association Aggregation Usage • Snapshot of the data Analysis 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]: 1 2 1 1 1 1 1 1 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 create alarmCheck
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: create 4: alarmCheck anAlarm 5: alarmSound anotherMeasWithRange 6: create 7: 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/sequence diagrams must be consistent with static models of the system parent:expr left:expr 1:evaluate right:expr 2:evaluate expr evaluate* 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: create 4: alarmCheck anAlarm 5: alarmSound anotherMeasWithRange6: create 7: alarmCheck Timer MeasWithRangeMonitor measure create Alarm alarmSound 1 * * * 1 1 alarmCheck notify 1 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 substate A transition to the superstate = a transition to the local initial substate • Concurrent states: Several threads of control Synchronization 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 Panel2Active clickTab2 clickTab1 Panel3Active clickTab1 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 display form indicate completion enter date enter card enter name … display form indicate completion 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 g Left 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 b h i j k h i j k h i j k b b b b b b b b
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 alarmSound createMeasurement
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,flash clickTab2/Tabs.showTab(Tab2)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 26 Example: guards E.g. select purchase display form enter date indicate completion [complete] / displayReceipt displaying cart confirm transaction [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 talkService hangup 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]: Archive Incident Open Incident Document Incident Allocate Resources Coordinate Resources Archive Incident Dispatcher FieldOfficer Open Incident Document Incident Allocate Resources Coordinate Resources
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 actors Tracking the progress of a use case or a part of a use case Tracking 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 CommandManager auctionState sendMail receiveMail timeout Auction crtPrice compareBid setCrtBid getCrtBid Bidder emailAddr Item initialPrice crtWinner 1 * compareBid setCrtBid 1 1 1 Message text addr 11 crtBid warning closure getCrtBid 1 * 1 sendMail receiveMail, 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 writing E.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 classes E.g., “minutes” is as a noun, but it should be an attribute of a “Time” class Sort 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 program E.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 sinks Actions: “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 to Aggregation: 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 * 1writes author document 1 11 1 triggersreports 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 risk Enlightened 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 solution The problem elements stay the same for all possible solutions Example: HUGERAM data: array[1T] of byte read(addr):data write(addr,data) CACHE data: array[128K] of byte read(addr):data write(addr,data) DISK data: array[64M] of byte read(addr):data write(addr,data) 16 1 CACHE data: array[64K] of byte read(addr):data write(addr,data) DISK data: array[256M] of byte read(addr):data write(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 sendMail receiveMail interpretMail AuctionSessionCtrl auctionState handleLogonCmd initiateAuction handleBidCmd timeout Timer delay reset(delay) wakeup() BidderLog addBidder removeBidder notifyAll Auction crtPrice compareBid setCrtBid getCrtBid BidderInfo emailAddr handleNotif Item initialPrice getPrice setPrice crtWinner 1 *1 * 1 sendMail handleCmd create 1 * timeout reset 1 * compareBid setCrtBid create 1 1 11 Message text addr getText setText getAddr setAddr 11 crtBid warning closure 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 criteria Use a checklist Re-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 case Does 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 elements Meaningful, understandable by users Conformant to Abbott’s rules and other conventions Uniform level of detail in the descriptions (glossary) • Realism (feasibility): demonstrate by prototypes or feasibility studies Target novel features (not present in previous systems) Target non-functional requirements • Absence of implementation bias Tells 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 • Walkthroughs 1. Receive mail – Bid – Send email to all bidders 2. Timeout – Issue warning to all bidders 3. Receive mail – Logon 4. Set initial price – Notify all bidders • Validate walkthroughs with the customer Use a UI scaffold if you can • Naming Abbott’s rules: all classes, attributes, methods Conventions: …Ctrl class • Realism: non-optimal, backup solutions Email adaptor Timer (as a backup solution) • Absence of bias Each 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 notations Regular expressions, formal grammars, XML Assertions, Z, OCL • Various OO notations superceded by UML Booch, Coad, Jacobson, Odell, Rumbaugh, Shlaer/Mellor… [Handout, fig. 1,2] • Concurrent and distributed systems Petri nets Specification 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 analysis Nouns (akin to identifying initial analysis objects) Same limitations Identifying relationships • Textual cues “Having” verbs Transitive verbs • From DFD Activities
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 subsystems Task identification from natural language description: verbs processes (task bubbles) • Successively refine some of the bubbles Until design choices need to be made, or until the algorithm level is reached Level 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.pdf See Chapter 3: “UML notation guide” • UML resource center http://www.rational.com/uml/resources/documentation/index.jsp

More Related Content

PDF
Software project management requirements analysis
byAntony Alex
 
PPTX
Scenario based methods
byJoshuaU1
 
PPT
Requirements analysis
byasimnawaz54
 
PPT
Requirement analysis and specification, software engineering
byRupesh Vaishnav
 
PPTX
Requirement analysis
byBro Shola Ajayi
 
PPT
Requirement Analysis - Software Enigneering
byuniversity of education,Lahore
 
PPTX
Object oriented analysis &design - requirement analysis
byAbhilasha Lahigude
 
PDF
System requirements analysis
bySharmila Duraipandian
 
Software project management requirements analysis
byAntony Alex
 
Scenario based methods
byJoshuaU1
 
Requirements analysis
byasimnawaz54
 
Requirement analysis and specification, software engineering
byRupesh Vaishnav
 
Requirement analysis
byBro Shola Ajayi
 
Requirement Analysis - Software Enigneering
byuniversity of education,Lahore
 
Object oriented analysis &design - requirement analysis
byAbhilasha Lahigude
 
System requirements analysis
bySharmila Duraipandian
 

What's hot

PPT
Modeling System Requirements
byAsjad Raza
 
PDF
Software Engineering Important Short Question for Exams
byMuhammadTalha436
 
PPT
Analysis modeling
byPreeti Mishra
 
PDF
Structured Analysis and Structured Design
bySanjay Kumar Chakravarti
 
PPT
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
bymohamed khalaf alla mohamedain
 
PPT
System design
byAnand Grewal
 
PPT
Modelling System Requirements: Events & Things
bywmomoni
 
PDF
Requirement analysis
byShyam Bahadur Sunari Magar
 
PPT
Software engg. pressman_ch-6 & 7
byDhairya Joshi
 
PPTX
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
byDhivyaa C.R
 
PPT
Requirement specification
byAbdul Basit
 
PPT
Abbott's Textual Analysis : Software Engineering 2
bywahab13
 
PPT
Requirements Engineering Process
byJomel Penalba
 
PPT
Requirement Analysis
byWebx
 
PPTX
Requirements Engineering (CS 5032 2012)
byIan Sommerville
 
PPT
Requirement Engineering
byUniversity of Haripur
 
PPT
Software requirements and analysis
byPhanindra Cherukuri
 
PPTX
Requirement Analysis & Specification sharbani bhattacharya
bySharbani Bhattacharya
 
PDF
ODD: Extending Requirements Analysis 1.2
byJonathan Herring
 
PPTX
Requirements analysis 2011
bybernddu
 
Modeling System Requirements
byAsjad Raza
 
Software Engineering Important Short Question for Exams
byMuhammadTalha436
 
Analysis modeling
byPreeti Mishra
 
Structured Analysis and Structured Design
bySanjay Kumar Chakravarti
 
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
bymohamed khalaf alla mohamedain
 
System design
byAnand Grewal
 
Modelling System Requirements: Events & Things
bywmomoni
 
Requirement analysis
byShyam Bahadur Sunari Magar
 
Software engg. pressman_ch-6 & 7
byDhairya Joshi
 
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
byDhivyaa C.R
 
Requirement specification
byAbdul Basit
 
Abbott's Textual Analysis : Software Engineering 2
bywahab13
 
Requirements Engineering Process
byJomel Penalba
 
Requirement Analysis
byWebx
 
Requirements Engineering (CS 5032 2012)
byIan Sommerville
 
Requirement Engineering
byUniversity of Haripur
 
Software requirements and analysis
byPhanindra Cherukuri
 
Requirement Analysis & Specification sharbani bhattacharya
bySharbani Bhattacharya
 
ODD: Extending Requirements Analysis 1.2
byJonathan Herring
 
Requirements analysis 2011
bybernddu
 

Viewers also liked

PDF
A Bidding System In Football "Football Fantasy"
byAnit Thapaliya
 
PDF
Requirement analysis and specification
byM.E. at GTU- PG School
 
PPTX
Auction website design phase_prs
byZeliya Dsouza
 
PPT
Requirements Engineering
byEhsan Elahi
 
DOC
SRS on online auction system
bysagar_paperwala
 
DOCX
FRAUD DETECTION IN ONLINE AUCTIONING
bySatish Chandra
 
PPTX
Avl Tree Implementation
byEhsan Elahi
 
A Bidding System In Football "Football Fantasy"
byAnit Thapaliya
 
Requirement analysis and specification
byM.E. at GTU- PG School
 
Auction website design phase_prs
byZeliya Dsouza
 
Requirements Engineering
byEhsan Elahi
 
SRS on online auction system
bysagar_paperwala
 
FRAUD DETECTION IN ONLINE AUCTIONING
bySatish Chandra
 
Avl Tree Implementation
byEhsan Elahi
 

Similar to Intro to Software Engineering - Requirements Analysis

PDF
Intro to Software Engineering - Module Design
byRadu_Negulescu
 
PDF
SE@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.ppt.pdf
bytimoemin50
 
PDF
Software Engineering : OOAD using UML
byAjit Nayak
 
PPTX
SE - Lecture 6 - Software Design n Construction.pptx
byTangZhiSiang
 
PDF
Software Engineering Tools and Practices.pdf
byMeagGhn
 
PPT
Sw Software Design
byjonathan077070
 
PPT
uml123 copy
byAmit Sachan
 
PPTX
05 fse requirementsengineering
byMohesh Chandran
 
PPTX
Interaction modelling is further classified into two types: Use case diagram....
byKarthik Rohan
 
PPTX
Software Engineering - System Modeling.pptx
byMasterHackerx
 
PPT
Introducing Uml And Development Process
byTerry Cho
 
DOCX
Case tool lab-Reg2013 by Karthick Raja
byursKarthick Raja
 
DOCX
Ooad unit 1
byraj kumar
 
PDF
Intro to Software Engineering - Software Design
byRadu_Negulescu
 
PPTX
AN introduction to Software Engineering and Data.pptx
byPatrick460353
 
PPTX
Lec5-RequirementModeling (uet software engineering lectures.pptx
byabdulrehmansafdar292
 
PPTX
01_IT4557.pptx
byjohnmichael314688
 
PDF
Lesson #04 - Software Engineering - Lecture.pdf
byBeksultanMustafin
 
PDF
M azhar
byMazhar Saleem
 
PDF
Object Oriented Analysis
byPramod Parajuli
 
Intro to Software Engineering - Module Design
byRadu_Negulescu
 
SE@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.ppt.pdf
bytimoemin50
 
Software Engineering : OOAD using UML
byAjit Nayak
 
SE - Lecture 6 - Software Design n Construction.pptx
byTangZhiSiang
 
Software Engineering Tools and Practices.pdf
byMeagGhn
 
Sw Software Design
byjonathan077070
 
uml123 copy
byAmit Sachan
 
05 fse requirementsengineering
byMohesh Chandran
 
Interaction modelling is further classified into two types: Use case diagram....
byKarthik Rohan
 
Software Engineering - System Modeling.pptx
byMasterHackerx
 
Introducing Uml And Development Process
byTerry Cho
 
Case tool lab-Reg2013 by Karthick Raja
byursKarthick Raja
 
Ooad unit 1
byraj kumar
 
Intro to Software Engineering - Software Design
byRadu_Negulescu
 
AN introduction to Software Engineering and Data.pptx
byPatrick460353
 
Lec5-RequirementModeling (uet software engineering lectures.pptx
byabdulrehmansafdar292
 
01_IT4557.pptx
byjohnmichael314688
 
Lesson #04 - Software Engineering - Lecture.pdf
byBeksultanMustafin
 
M azhar
byMazhar Saleem
 
Object Oriented Analysis
byPramod Parajuli
 

More from Radu_Negulescu

PDF
Intro to Software Engineering - Software Testing
byRadu_Negulescu
 
PDF
Intro to Software Engineering - Life Cycle Models
byRadu_Negulescu
 
PDF
Midterm Exam Solutions Fall03
byRadu_Negulescu
 
PDF
Final Exam Questions Fall03
byRadu_Negulescu
 
PDF
Final Exam Solutions Fall02
byRadu_Negulescu
 
PDF
Intro to Software Engineering - Software Quality Assurance
byRadu_Negulescu
 
PDF
Intro to Software Engineering - Coding Standards
byRadu_Negulescu
 
PDF
Midterm Exam Solutions Fall02
byRadu_Negulescu
 
PDF
Software Engineering Practice - Configuration management
byRadu_Negulescu
 
PDF
Software Engineering Practice - Software Metrics and Estimation
byRadu_Negulescu
 
PDF
Intro to Software Engineering - Software Quality Assurance
byRadu_Negulescu
 
PDF
Software Engineering Practice - Software Quality Management
byRadu_Negulescu
 
PDF
Software Engineering Practice - Advanced Development Methodologies
byRadu_Negulescu
 
PDF
Software Engineering Practice - Project management
byRadu_Negulescu
 
PDF
Software Engineering Practice - Software Business Basics
byRadu_Negulescu
 
Intro to Software Engineering - Software Testing
byRadu_Negulescu
 
Intro to Software Engineering - Life Cycle Models
byRadu_Negulescu
 
Midterm Exam Solutions Fall03
byRadu_Negulescu
 
Final Exam Questions Fall03
byRadu_Negulescu
 
Final Exam Solutions Fall02
byRadu_Negulescu
 
Intro to Software Engineering - Software Quality Assurance
byRadu_Negulescu
 
Intro to Software Engineering - Coding Standards
byRadu_Negulescu
 
Midterm Exam Solutions Fall02
byRadu_Negulescu
 
Software Engineering Practice - Configuration management
byRadu_Negulescu
 
Software Engineering Practice - Software Metrics and Estimation
byRadu_Negulescu
 
Intro to Software Engineering - Software Quality Assurance
byRadu_Negulescu
 
Software Engineering Practice - Software Quality Management
byRadu_Negulescu
 
Software Engineering Practice - Advanced Development Methodologies
byRadu_Negulescu
 
Software Engineering Practice - Project management
byRadu_Negulescu
 
Software Engineering Practice - Software Business Basics
byRadu_Negulescu
 

Recently uploaded

PDF
Strengthening cybern resilience for a leading indian Financial Services group
bypandeydevika621
 
PDF
Achieving Interoperability in Healthcare IT: A Strategic Guide
byHart, Inc.
 
PDF
Azure Identity, Governance, and Monitoring solutions
byVICTOR MAESTRE RAMIREZ
 
PDF
Beyond BBB: Practical Alternatives to Posterior Approximation in Bayesian Neu...
byTomasz Kusmierczyk
 
PPTX
Scrape YouTube Video Data for Influencer Analytics.pptx
byWeb Data Crawler
 
PPTX
Information about Trusted Platform Module(TPM)
bynewtoknowtechs
 
PDF
Industrial RFID Landscape for 2025 - Readers, Tags, Antennas, Printers, etc
byRich Rogers
 
PDF
The map to conquer linear algebra for IT engineer
byakipii ogaoga
 
PDF
Xemelgo - RFID Industry Predictions for 2026
byRich Rogers
 
PPTX
Corporate AI Training to AI Enable a Company Workforce
byStélio Inácio
 
PPTX
Spacecraft Guidance Quick Research Guide by Arthur Morgan
byArthur Morgan
 
PPT
HDTV and DTV Standards: The United States Opts for a Digital HDTV Standard
byJeffrey Hart
 
PDF
Navigating the Spectrum of Advanced AI – Agentic, Autonomous, and Autopoietic...
byScott M. Graffius
 
PDF
Small Business Automation: A Comprehensive Cost and ROI Guide
byAmelia Swank
 
PPTX
Document Reconstruction using AI & Deep Learning
bysonjuktaweb
 
PDF
Top Benefits of Using KVM VPS Hosting for Growing Businesses
byEthernet Servers
 
PDF
Regenerative Agriculture Finance : Environmental impact
byrose mason
 
PPTX
Digital transformation success powered by EPM and NexInfo.pptx
byjayasuryanexinfo
 
PDF
250 Prompts - ChatGPT acting as your Assistant
byMihir Nagarkar
 
PPTX
AI Bot Traffic Surge: Retail Fraud Threat for Age-Restricted Websites
byFTx Identity
 
Strengthening cybern resilience for a leading indian Financial Services group
bypandeydevika621
 
Achieving Interoperability in Healthcare IT: A Strategic Guide
byHart, Inc.
 
Azure Identity, Governance, and Monitoring solutions
byVICTOR MAESTRE RAMIREZ
 
Beyond BBB: Practical Alternatives to Posterior Approximation in Bayesian Neu...
byTomasz Kusmierczyk
 
Scrape YouTube Video Data for Influencer Analytics.pptx
byWeb Data Crawler
 
Information about Trusted Platform Module(TPM)
bynewtoknowtechs
 
Industrial RFID Landscape for 2025 - Readers, Tags, Antennas, Printers, etc
byRich Rogers
 
The map to conquer linear algebra for IT engineer
byakipii ogaoga
 
Xemelgo - RFID Industry Predictions for 2026
byRich Rogers
 
Corporate AI Training to AI Enable a Company Workforce
byStélio Inácio
 
Spacecraft Guidance Quick Research Guide by Arthur Morgan
byArthur Morgan
 
HDTV and DTV Standards: The United States Opts for a Digital HDTV Standard
byJeffrey Hart
 
Navigating the Spectrum of Advanced AI – Agentic, Autonomous, and Autopoietic...
byScott M. Graffius
 
Small Business Automation: A Comprehensive Cost and ROI Guide
byAmelia Swank
 
Document Reconstruction using AI & Deep Learning
bysonjuktaweb
 
Top Benefits of Using KVM VPS Hosting for Growing Businesses
byEthernet Servers
 
Regenerative Agriculture Finance : Environmental impact
byrose mason
 
Digital transformation success powered by EPM and NexInfo.pptx
byjayasuryanexinfo
 
250 Prompts - ChatGPT acting as your Assistant
byMihir Nagarkar
 
AI Bot Traffic Surge: Retail Fraud Threat for Age-Restricted Websites
byFTx Identity
 

Intro to Software Engineering - Requirements Analysis

  • 1.
    Requirements analysis McGill ECSE321 Intro to Software Engineering Radu Negulescu Fall 2003
  • 2.
    McGill University ECSE321 © 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
  • 3.
    McGill University ECSE321 © 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
  • 4.
    McGill University ECSE321 © 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 observations Updates RN, 3 Jan. 2010 ObservationHistory
  • 5.
    McGill University ECSE321 © 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 …
  • 6.
    McGill University ECSE321 © 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)
  • 7.
    McGill University ECSE321 © 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)
  • 8.
    McGill University ECSE321 © 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, directional Attributes, as for a class • To each association end, we can assign: Multiplicity or multiplicity range Role: string describing how the related objects relate in the association • It is possible to indicate constraints between associations
  • 9.
    McGill University ECSE321 © 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 system Bids and notifications sent by email CommandManager auctionState sendMail receiveMail timeout Auction crtPrice compareBid setCrtBid getCrtBid Bidder emailAddr Item initialPrice crtWinner 1 * compareBid setCrtBid 1 1 1 Message text addr 11 crtBid warning closure getCrtBid 1 * 1 sendMail receiveMail, timeout
  • 10.
    McGill University ECSE321 © 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
  • 11.
    McGill University ECSE321 © 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 instrument A piano is an instrument with a keyboard ... Piano Keyboard Instrument Keyboard 1 1 Piano Musical Instrument Keyboard 1 1
  • 12.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 12 Object diagrams Elements • Objects Program Real-world Virtual • Attributes Types (optional) Values (optional) • Relationships Association Aggregation Usage • Snapshot of the data Analysis vs. design Jazz Rock Salsa ... UIWindow RockPane PopPane SalsaPane Tab1:Tab Text = “Jazz” Tab2:Tab Text = “Rock” Tab3:Tab Text = “Salsa”
  • 13.
    McGill University ECSE321 © 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]: 1 2 1 1 1 1 1 1 SimpleWatch Display Battery TimePushButton SimpleWatch Display Battery TimeRightButton LeftButton
  • 14.
    McGill University ECSE321 © 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
  • 15.
    McGill University ECSE321 © 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 create alarmCheck
  • 16.
    McGill University ECSE321 © 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
  • 17.
    McGill University ECSE321 © 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: create 4: alarmCheck anAlarm 5: alarmSound anotherMeasWithRange 6: create 7: alarmCheck
  • 18.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 18 Consistency: dynamic vs. static models When used to illustrate system behaviors, collaboration/sequence diagrams must be consistent with static models of the system parent:expr left:expr 1:evaluate right:expr 2:evaluate expr evaluate* 1
  • 19.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 19 Consistency: dynamic vs. static models aTimer aMeasWithRangeaMonitor 2: measure 1: notify 3: create 4: alarmCheck anAlarm 5: alarmSound anotherMeasWithRange6: create 7: alarmCheck Timer MeasWithRangeMonitor measure create Alarm alarmSound 1 * * * 1 1 alarmCheck notify 1 1 1 1
  • 20.
    McGill University ECSE321 © 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 substate A transition to the superstate = a transition to the local initial substate • Concurrent states: Several threads of control Synchronization on entry and exit of the superstate
  • 21.
    McGill University ECSE321 © 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 Panel2Active clickTab2 clickTab1 Panel3Active clickTab1 clickTab3 clickTab3 clickTab2 Panel1Active Panel2Active Panel3Active clickTab1 clickTab3 clickTab2 Tab 1 Tab 2 Tab 3 Panel 1 clickTab3 clickTab2clickTab1
  • 22.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 22 Example: concurrency Equivalent semantics display form indicate completion enter date enter card enter name … display form indicate completion enter date enter card enter name …
  • 23.
    McGill University ECSE321 © 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 g Left 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 b h i j k h i j k h i j k b b b b b b b b
  • 24.
    McGill University ECSE321 © 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 alarmSound createMeasurement
  • 25.
    McGill University ECSE321 © 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,flash clickTab2/Tabs.showTab(Tab2)
  • 26.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 26 Example: guards E.g. select purchase display form enter date indicate completion [complete] / displayReceipt displaying cart confirm transaction [incomplete] / restore enter card enter name
  • 27.
    McGill University ECSE321 © 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
  • 28.
    McGill University ECSE321 © 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
  • 29.
    McGill University ECSE321 © 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
  • 30.
    McGill University ECSE321 © 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 talkService hangup hangup
  • 31.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 31 Activity diagrams Caveat: not object-oriented! • Fix: “swimlanes” • Example [BD]: Archive Incident Open Incident Document Incident Allocate Resources Coordinate Resources Archive Incident Dispatcher FieldOfficer Open Incident Document Incident Allocate Resources Coordinate Resources
  • 32.
    McGill University ECSE321 © 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
  • 33.
    McGill University ECSE321 © 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
  • 34.
    McGill University ECSE321 © 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 actors Tracking the progress of a use case or a part of a use case Tracking the state of an actor • E.g. user registration, phone connection
  • 35.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 35 Object identification Example: email-based auction system CommandManager auctionState sendMail receiveMail timeout Auction crtPrice compareBid setCrtBid getCrtBid Bidder emailAddr Item initialPrice crtWinner 1 * compareBid setCrtBid 1 1 1 Message text addr 11 crtBid warning closure getCrtBid 1 * 1 sendMail receiveMail, timeout Boundary Control Entity Entity Entity? Control?
  • 36.
    McGill University ECSE321 © 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
  • 37.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 37 Natural language analysis Limitations: • Imprecision, dependency on style of writing E.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 classes E.g., “minutes” is as a noun, but it should be an attribute of a “Time” class Sort 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 program E.g., a “coordinates” class in Satwatch
  • 38.
    McGill University ECSE321 © 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 sinks Actions: “command”, “message”, ... • Avoid interface artifacts (boundary objects!)
  • 39.
    McGill University ECSE321 © 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).”
  • 40.
    McGill University ECSE321 © 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!
  • 41.
    McGill University ECSE321 © 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!
  • 42.
    McGill University ECSE321 © 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 to Aggregation: 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 * 1writes author document 1 11 1 triggersreports FieldOfficer EmergencyReport Incident Redundancy => inconsistency?
  • 43.
    McGill University ECSE321 © 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 risk Enlightened procrastination! Heuristics: • Examine possessive phrases • Think of stored state • Pay more attention to entity attributes than control or boundary attributes • Leftover entity classes
  • 44.
    McGill University ECSE321 © 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 solution The problem elements stay the same for all possible solutions Example: HUGERAM data: array[1T] of byte read(addr):data write(addr,data) CACHE data: array[128K] of byte read(addr):data write(addr,data) DISK data: array[64M] of byte read(addr):data write(addr,data) 16 1 CACHE data: array[64K] of byte read(addr):data write(addr,data) DISK data: array[256M] of byte read(addr):data write(addr,data) 4 1
  • 45.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 45 Analysis vs. design models OO: smooth transition from “problem domain” to implementation EmailAdaptor sendMail receiveMail interpretMail AuctionSessionCtrl auctionState handleLogonCmd initiateAuction handleBidCmd timeout Timer delay reset(delay) wakeup() BidderLog addBidder removeBidder notifyAll Auction crtPrice compareBid setCrtBid getCrtBid BidderInfo emailAddr handleNotif Item initialPrice getPrice setPrice crtWinner 1 *1 * 1 sendMail handleCmd create 1 * timeout reset 1 * compareBid setCrtBid create 1 1 11 Message text addr getText setText getAddr setAddr 11 crtBid warning closure set,get receiveMail wakeup getCrtBid 1
  • 46.
    McGill University ECSE321 © 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 criteria Use a checklist Re-iterate for functionality from all previous increments!
  • 47.
    McGill University ECSE321 © 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 case Does 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 elements Meaningful, understandable by users Conformant to Abbott’s rules and other conventions Uniform level of detail in the descriptions (glossary) • Realism (feasibility): demonstrate by prototypes or feasibility studies Target novel features (not present in previous systems) Target non-functional requirements • Absence of implementation bias Tells you where to stop your analysis work!
  • 48.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 48 Reviewing the analysis model E.g. email-based auction system • Walkthroughs 1. Receive mail – Bid – Send email to all bidders 2. Timeout – Issue warning to all bidders 3. Receive mail – Logon 4. Set initial price – Notify all bidders • Validate walkthroughs with the customer Use a UI scaffold if you can • Naming Abbott’s rules: all classes, attributes, methods Conventions: …Ctrl class • Realism: non-optimal, backup solutions Email adaptor Timer (as a backup solution) • Absence of bias Each class, attribute, method: compulsory or not?
  • 49.
    McGill University ECSE321 © 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
  • 50.
    McGill University ECSE321 © 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 notations Regular expressions, formal grammars, XML Assertions, Z, OCL • Various OO notations superceded by UML Booch, Coad, Jacobson, Odell, Rumbaugh, Shlaer/Mellor… [Handout, fig. 1,2] • Concurrent and distributed systems Petri nets Specification and Description Language (SDL)
  • 51.
    McGill University ECSE321 © 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]
  • 52.
    McGill University ECSE321 © 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]
  • 53.
    McGill University ECSE321 © 2003 Radu Negulescu Introduction to Software Engineering Requirements analysis—Slide 53 Function-oriented analysis Identifying entities • Natural language analysis Nouns (akin to identifying initial analysis objects) Same limitations Identifying relationships • Textual cues “Having” verbs Transitive verbs • From DFD Activities
  • 54.
    McGill University ECSE321 © 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 subsystems Task identification from natural language description: verbs processes (task bubbles) • Successively refine some of the bubbles Until design choices need to be made, or until the algorithm level is reached Level balancing (“continuity”): the input and output data flows must be consistent across levels E.g. [Handout, fig.6,7]
  • 55.
    McGill University ECSE321 © 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.pdf See Chapter 3: “UML notation guide” • UML resource center http://www.rational.com/uml/resources/documentation/index.jsp