Modeling Requirements with Use Cases: A Picture Says a Thousand Words

1. Modeling Requirements with Use Cases:A Picture Says a Thousand Words IEEE

2. Introduction IEEE

3. Requirement • a condition or capability needed by a user to solve a problem or achieve an objective • a condition or capability that must be met or possessed by a system component to satisfy a contract, standard specification, or other formally imposed document • from user or evolves from user requirement IEEE

4. Requirements Engineering • requirements modeling • elicit • analyze • specify • validate • requirements management • project planning • baseline • prioritize • change control • trace IEEE

5. Eliciting Requirements IEEE

6. Sources of Requirements • market analysis • trends • market size and demography • competition • differentiation • business opportunities • business engineering • business process reengineering • system opportunities • needs analysis IEEE

7. Involve Stakeholders • customers • promote and sustain the vision of the product • users • participate in behavioral contracts with the system • business analysts • facilitate and write the use cases • subject matter experts • know how the business ought to work • quality engineers • process improvement IEEE

8. Contact Other Stakeholders • customer service • diagnostics • field replaceable units • remote access • marketing and sales • demo modes • whiz-bangs IEEE

9. Elicitation Techniques • existing literature • working guidelines • current workflows • previous proposals • in-house and customer visits • interviews • let people think aloud while walking through tasks • list entities that people use or reference • form, folder, image, etc. • get their attributes • concentrate on tag lines (create, read, update, delete, etc.) IEEE

10. Elicitation Techniques • questionnaires • workshops • joint requirements planning (e.g., JAD) sessions • conducted by facilitator • restates people’s words into a question • directs questions • proposes summaries of people’s judgments about aspects of a task IEEE

11. Elicitation Artifacts • vision document • system scope • problem context • competitive evaluation • product objectives • high-level features IEEE

12. Elicitation Artifacts • business case • cost/benefits assessment • return on investment • technical assessment/alternatives • staffing • schedule • risk factors prioritized • dependence on changing technology • window size • experience of team IEEE

13. Analyzing Requirements IEEE

14. Requirements Analysis • uses abstraction to understand the nature of a problem • uses models to express the requirements in the semantics of the users • complete • consistent • unambiguous IEEE

15. Requirements Analysis • models provide communication to • project managers • provides a basis for scheduling incremental releases • human factors • know what storyboards need to be prototyped • software architects • know how to create the blueprint for a system • developers • gives them an intuitive feel of the system to be realized • testers • gives them verifiable features for a test plan of the system IEEE

16. Analysis Artifacts • activity diagrams • current workflows or concepts of operation • use case model • behavioral requirements (what the software does) • represents an “outside-in” perspective • roles distributed among users • responsibilities carries out by system responses • glossary • catalog of domain terms • can evolve into an object analysis model IEEE

17. Analysis Artifacts • nonfunctional requirements • what the software is • UI usability and details • navigation diagrams • prototypes • business policies and rules • external and internal constraints that govern how a business is run • likely apply to several use cases • domain model IEEE

18. Nonfunctional Requirements • technical qualities • performance • capacity • reliability • extensibility • configurability • scalability • portability • maintainability IEEE

19. Nonfunctional Requirements • technical constraintsare restrictions on the degree of freedom to provide a solution • hardware • memory • storage • peripheral devices • media • software • operating system • language • tools • database • middleware IEEE

20. Activity Diagram • models “as-is” workflows • visualizes flow of events as an alternative to text • special state diagram • activity • statewitha non-atomic action to be performed • transition • automatic control flow between activity states • can divide into multiple transitions that create parallel activities • decision • for a set of alternate transitions with a set of conditions • condition • Boolean expression that guards a transition IEEE

21. Activity Diagram Notation start point Detect card [invalid] condition Eject card transition [valid] activity Customer Verify PIN [incorrect] decision Handle bad PIN [correct] [resolved] Withdraw amount [unresolved] Central Bank Authorize transaction IEEE

22. Swimlane • visually partitions an activity diagram • noted by a vertical solid line • represents a responsibility for part of the overall activity • corresponds to an organizational unit in a business model • separates external interaction from system response IEEE

23. Swimlane Notation Customer ATM Central Bank Insert card Detect card [invalid] Eject card [valid] Ask for PIN Enter PIN Verify PIN [incorrect] Handle bad PIN [correct] [resolved] Ask for function Enter account and amount [unresolved] Authorize transaction Check records IEEE

24. Use Cases and UML IEEE

25. UML • object-oriented modeling language for software-intensive systems • specifies • visualizes • constructs • documents • independent of • object-oriented programming languages • development processes • metamodel • establishes a conceptual framework for specifying models IEEE

26. Modeling Elements • actor • an external agent that interacts with the system • use case • a way in which the system is used by its actors expressed from their perspective • relationship • associationbetween an actor and a use case • dependencybetween use cases • generalizationamong use cases IEEE

27. Stereotype << . . . >> • an adornment that extends the UML notation • defines new semantic meaning to a model element • typically specifies the usage context of an actor or relationship • enclosed in guillemets • <<angled brackets>> are an acceptable alternative • stereotyped elements can be rendered by icons • either 0 or 1 IEEE

28. Actor • external agentthat needs to exchange information with the system • a single abstractiverole played by multiple instances • person, company, organization • another system, persistent data source, peripheral • primaryactors • directly obtain value from the behavior of the system • supportingactors • provide services that help primary actors use the system • internal actors • used if use cases describe details of how parts of a system (e.g., subsystems) cooperate IEEE

29. Actor Notation • outside of scope of system • delineates systemboundary context diagram actor name <<nonhuman>> actor name system name actor name IEEE

30. Use Case • abstracts a coherent function or feature of a system that is actor-centric • achieves the actor’s goalwhile protecting the interests of the other actors • can be completed in a single session • describes a sequence of interactions between the system and its actor(s) • expresses the behavioral requirements of the system “to be” • triggered by an event sent by an actor • can be triggered by a scheduled temporal event (clock) IEEE

31. Use Case Notation use case name use case name actor name use case name actor name use case name use case name actor name system name IEEE

32. Use Case Association • <<communicates>>type of structural connection between an actor and a use case • actor can associate with many use cases • use case can associate with many actors • bidirectional • applies to events to and from the system • usuallyunidirectionalto indicate initial flow • activefor actors that initiate a use case • initial stimulus is a triggeringevent • primary or supporting actor • passivefor actors that only collaborate in a use case • typically a supporting actor that provides a service or receives data IEEE

33. Association Notation <<communicates>> event <<communicates>> event use case name <<communicates>> event actor name use case name actor name <<communicates>> event use case name <<communicates>> event <<communicates>> event actor name system name IEEE

34. Initial Use Case Model IEEE

35. Process Outline • iteratearound • identifying system boundary with actors • identifying each actor’s goals when interacting with the system • expressing goal statements with essential use cases • reviewing with all interested parties IEEE

36. Identifying Actors • focus on primary actors first • characterize humans • who uses the system • who provides events and data to the system • who gets information from the system • which users communicate with each other • may communicate outside of system • secondary actor uses an actor as a facilitator • do not let job titles dictate actors IEEE

37. Identifying Actors • characterize nonhuman interface points • what other systems use this system • data providers • legacy feeds • what other systems does this system use • report consumers • legacy systems • off the shelf products • what other devices does this system use • does an external timer trigger system responses IEEE

38. Identifying Actors • then focus on supporting actors • who installs the system • who starts up or shuts down the system • who maintains the system IEEE

39. Specifying Actors • human actor names tend to end in “er” • brief description of • responsibilities of a human user • skill set • work environment • interface characteristics of a nonhuman actor • active or passive communication IEEE

40. Identifying Use Cases • identify before specifying • business process people specify actors and identify goals that they need to achieve • business use case • actors are all roles involved in the essential enterprise • primary actors are active (users) • supporting actors are passive IEEE

41. Identifying Use Cases • development team specifies actors and identify goals that they need to achieve • system use case • actors are roles entering into direct contact with the software system • supporting actors are active and passive • consider • startup and shutdown • installation • backup and recovery • diagnostics • report generation IEEE

42. Use Case Granularity • initial use cases are placeholders • provide functionalscopeandcoverage • granularity • relative scope of use cases compared to the application’s scope • no metrics to determine correct granularity • each use case must provide the “big picture” for a subset of system functionality without requiring an army of analysts to work on it • a medium-sized software system may have 50-75 IEEE

43. Specifying Use Cases • name with an active verb-noun phrase from primary actor’s viewpoint • “Rent a Video” • start simple, with low precision • high-level description from external perspective • reflects essential goal • specify macro-functionality • “black-box” in scope IEEE

44. Specifying Use Cases • use narrative prose • paragraph with a few sentences or probably too big • sentences are sub goals • natural language • vocabulary of user • unconstrained by technology or design decisions • focus on what and when of system and actor interactions • emphasize interaction as a conversation IEEE

45. Initial Use Case Template • Unique identifier • name and optional number • Actors • primary or supporting • Goal description • actor’s expectations of value from using the system • Nonfunctional requirements • technical qualities, constraints (Keyword: requirement) IEEE

46. Elaborated Use Case Model IEEE

47. Process Outline • iteratearound • defining primary flow of events • expanding on the what and when of system and actor responsibilities • specifying micro-functionality • more “white-box” in scope • emphasize system responses and resulting state changes • introduce concrete technology constraints • defining alternative event flows • adding preconditions and postconditions IEEE

48. Process Outline • expandingon the what and when of system and actor responsibilities • detailing the behavioral contract between the system and its actors • system sequence diagrams • reviewing with all interested parties IEEE

49. Flow of Events • a use case is a crisscrossing story line of success and failure paths related to a single goal • one primary flow of events (typically) • precondition and trigger are condition under which it runs • everything goes right (happy path) • no branching • zero or more alternative event flows • other user choices • exception to assumptions, preconditions, or postconditions that result in error paths IEEE

50. Primary Flow of Events • add precisionstep-by-step • number the steps • typically 3-15 steps in primary flow • can use a nested numbering scheme • clearly describe trigger event that initiates use case • describe when use case terminates • each step is one simple action • actor interaction • validation step • internal state change • can reference which business rules are enforced IEEE