ObjectOriented Analysis and Design Evolutionary Requirements UP Requirements

Object-Oriented Analysis and Design Evolutionary Requirements

UP Requirements Artifacts n Use Case Model – typical scenarios of functional n n requirements Supplementary Specifications – primarily nonfunctional requirements Glossary – noteworthy terms including a Data Dictionary (a recording of data requirements) Vision – high-level requirements and business case summary Business Rules – (aka Domain Rules) requirements or policies which apply to many projects required by business or domain (e. g. tax laws)

Object-Oriented Analysis and Design Use Cases Read chapter 6

Define the Problem n The most critical question: n “Is this the right system to make? ”

Use Case Relationships Business Model Objects, attributes, associations Domain Model VISION Use Case Model Requirements Design GLOSSARY SUPPLEMENTARY SPECIFICATION Interaction Diagrams

Use Cases are not Diagrams n Use Cases have a diagram associated with them n easy way for analyst to discuss a process with a domain expert n Use cases are primarily text n text = important; diagram = optional

Why Use Cases? n Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals. n They keep it simple n They emphasize goals and the user perspective Focus on the essence/intent of requirements n Avoid bias of reproducing the existing system n

Identify Use Cases n Capture specific ways of using the system as dialogue between an actor and the system. n Use cases are used to: Capture functional system requirements n Communicate with end users and Domain Experts n Test the system n

Specifying Use Cases n Create a written document for each Use Case Clearly define intent of the Use Case n Define Main Success Scenario (Happy Path) n Define any alternate action paths n Use format of Stimulus: Response n Each specification must be testable n Write from actor’s perspective, in actor’s vocabulary n

Use Case Template Items n n n n n Use Case Name Scope (the system under design) Level ("user-goal" or "subfunction") Primary Actor (calls on system to deliver its function) Stakeholders and Interests (Who cares? What do they want? ) Preconditions (what must be true at use case start) Success Guarantee (aka Posconditions; what must be true on successful use case completion) Main Success Scenario (happy path/sunny day) Extensions (alternative scenarios) Special Requirements (non-functional requirements)

Suggested Other Use Case Items n Technology and Data Variations (I/O methods and data formats) n Frequency of Occurrence (of use case) n Miscellaneous (e. g. open issues) n See Use Case UC 1: Process Sale p. 68

Naming Use Cases n A complete process from end user viewpoint n Usually in verb-object form, (e. g. Register for Classes) n Use enough detail to make it specific n Use active voice, not passive n From viewpoint of the actor, not the system

Use Case Name Examples n Excellent - Purchase Concert Ticket n Very Good - Purchase Concert Tickets n Good - Purchase Ticket (insufficient detail) n Fair - Ticket Purchase (passive) n Poor - Ticket Order (system view, not user) n Unacceptable - Pay for Ticket (procedure, not process)

Singular or Plural? n Usually determined by context. n Preference for the simplest form, but most common form can be better. n In the example of concert tickets, most people buy more than one, but a significant number buy only one. n At a supermarket, Buy Items would be best. n At a vending machine, it would be Buy Item.

Identify Actors n Part of understanding a system is knowing who uses it Direct users n Users responsible to operate and maintain it n External systems used by the system n External systems that interact with the system n

Specifying Actors n External to the system n Non-deterministic n May be different roles for one individual user n May be other external systems

Identifying Actors n Primary Actor n Emphasis is on the primary actor for the use case – has goals to be fulfilled n Stakeholders and Interests n Other actors are listed as stakeholders. n The interests of each key actor should be described.

Working with Use Cases n Determine the actors that will interact with the system n Examine the actors and document their needs n For each separate need, create a use case n During Analysis, extend use cases with interaction diagrams

Preconditions n Anything that must always be true before beginning a scenario is a precondition. n Assumed to be true, not tested within the Use Case n Ignore obvious preconditions (e. g. power is on)

Success Guarantees (Postconditions) n States what must be true if the Use Case is completed successfully n May include the main success scenario and some alternative paths n Stakeholders should agree on the guarantee.

Scenarios n Main Success Scenario, or “happy path” is expected primary use of the system, without problems or exceptions. n Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.

Happy Path / Sunny Day Scenario n Success Scenario (or basic course) gives the best understanding of the use case n Each step contains the activities and inputs of the actor and the system response n Two column template works well for this n If three or more items, create a list n Label steps for configuration management and requirements traceability n Use present tense and active voice

Extensions (Alternative Flows) n Extensions or Alternative Flow Use Cases allow the specification of n Different ways of handling transactions n Error processes n Sections are convenient way to handle alternative courses of action n Sections are a segment of a use case executed out of sequence

Essential versus Real Use Cases n Essential (black box) use case leaves out technology and focuses only on functionality n Real (white box) use case includes technology is fundamental. n E. g. , essential Withdraw Cash from ATM use can mention identification or validation n Only real Withdraw Cash from ATM use can mention a key pad or card reader

Extension Use Cases n Users appreciate simplicity, so most use cases leave out alternate courses n Do this by extending the use case (see Use Case Diagramming section below) while leaving the original use case alone

Use-case driven development n Requirements are primarily recorded in the Use Case model. n Iterations are planned around implementing particular Use Cases. n Use Case Realizations drive design. n Use Case often influence the way user manuals are organized.

Object-Oriented Analysis and Design Diagramming Use Cases read Chapter 30

Actor n An actor is an idealized user n n of a system Actors can be users, processes, and other systems Many users can be one actor, in a common role One user can be different actors, if in different roles An actor is labeled in singular with the name of the role

Non-human Actors can be users, Inventory System processes, and other systems. n Non human actors typically shown as rectangle rather than stick figure n Usually not primary users, and thus are usually shown on the right

Use Case n Is a coherent unit of externally visible functionality provided by a system and expressed by a sequence of messages n Additional behavior can be shown with generalize, extend, and include use case relationships n Labeled with the use case name

System n A system is shown as a rectangle, labeled with the system name n Actors are outside the system n Use cases are inside the system n The rectangle shows the scope or boundary of the system Don’t forget the boundary and the system name, unless you are using Rational Rose!

Association Relationship n An association is the communication path between an actor and the use case that it participates in n It is shown as a solid line n It does not have an arrow, and is normally read from left to right n Here, the association is between a Modeler and the Create Model use case

Include Relationship n Include relationships insert additional behavior into a base use case n They are shown as a dotted line with an open arrow and the key word <<include>> n Shown is a process that I observed in an earlier career

Extend Relationship n Extend puts additional, optional behavior in a use case that does not know about it. n It is shown as a dotted line with an arrow point and labeled <<extend>> n In this case, a customer can request a catalog when placing an order

Generalize Relationship n Is a relationship between a general use case and a more specific use case that inherits and extends its features n It is shown as a solid line with a closed arrow point n Here, the payment process is modified for cash and charge cards

Use Case Example: Alarm Clock This is a contrived example, to show many relations. Your diagrams should be simpler.