• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Intro to Software Engineering - Requirements Analysis
 

Intro to Software Engineering - Requirements Analysis

on

  • 967 views

 

Statistics

Views

Total Views
967
Views on SlideShare
967
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Intro to Software Engineering - Requirements Analysis Intro to Software Engineering - Requirements Analysis Presentation Transcript

    • 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