object-oriented analysis and design evolutionary requirements
TRANSCRIPT
Object-Oriented Analysis and Design
Evolutionary Requirements
UP Requirements Artifacts
Use Case Model – typical scenarios of functional requirements
Supplementary Specifications – primarily non-functional 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
The most critical question: “Is this the right system to make?”
Use Case Relationships
Domain Model
Use Case Model
Interaction DiagramsDesign
Requirements
Business Model
Objects, attributes, associations
VISION
GLOSSARY
SUPPLEMENTARYSPECIFICATION
Use Cases are not Diagrams Use Cases have a diagram associated with them
easy way for analyst to discuss a process with a domain expert
Use cases are primarily text text = important; diagram = optional
Why Use Cases?
Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals.
They keep it simple They emphasize goals and the user
perspective Focus on the essence/intent of requirements Avoid bias of reproducing the existing system
Identify Use Cases Capture specific ways of using the system as
dialogue between an actor and the system. Use cases are used to:
Capture functional system requirements Communicate with end users and Domain
Experts Test the system
Specifying Use Cases Create a written document for each Use Case
Clearly define intent of the Use Case Define Main Success Scenario (Happy Path) Define any alternate action paths Use format of Stimulus: Response Each specification must be testable Write from actor’s perspective, in actor’s
vocabulary
Use Case Template Items
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
Technology and Data Variations (I/O methods and data formats)
Frequency of Occurrence (of use case) Miscellaneous (e.g. open issues) See Use Case UC1: Process Sale p. 68
Naming Use Cases A complete process from end user viewpoint Usually in verb-object form, (e.g. Register for
Classes) Use enough detail to make it specific Use active voice, not passive From viewpoint of the actor, not the system
Use Case Name Examples Excellent - Purchase Concert Ticket Very Good - Purchase Concert Tickets Good - Purchase Ticket (insufficient detail) Fair - Ticket Purchase (passive) Poor - Ticket Order (system view, not user) Unacceptable - Pay for Ticket (procedure, not
process)
Singular or Plural?
Usually determined by context. Preference for the simplest form, but most
common form can be better. In the example of concert tickets, most people
buy more than one, but a significant number buy only one.
At a supermarket, Buy Items would be best. At a vending machine, it would be Buy Item.
Identify Actors Part of understanding a system is knowing
who uses it Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system
Specifying Actors External to the system Non-deterministic May be different roles for one individual user May be other external systems
Identifying Actors Primary Actor
Emphasis is on the primary actor for the use case – has goals to be fulfilled
Stakeholders and Interests Other actors are listed as stakeholders. The interests of each key actor should
be described.
Working with Use Cases Determine the actors that will interact with the
system Examine the actors and document their needs For each separate need, create a use case During Analysis, extend use cases with
interaction diagrams
Preconditions
Anything that must always be true before beginning a scenario is a precondition.
Assumed to be true, not tested within the Use Case
Ignore obvious preconditions (e.g. power is on)
Success Guarantees (Postconditions)
States what must be true if the Use Case is completed successfully
May include the main success scenario and some alternative paths
Stakeholders should agree on the guarantee.
Scenarios Main Success Scenario, or “happy path” is
expected primary use of the system, without problems or exceptions.
Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.
Happy Path / Sunny Day Scenario Success Scenario (or basic course) gives the best
understanding of the use case Each step contains the activities and inputs of the
actor and the system response Two column template works well for this
If three or more items, create a list Label steps for configuration management and
requirements traceability Use present tense and active voice
Extensions (Alternative Flows) Extensions or Alternative Flow Use Cases
allow the specification of Different ways of handling transactions Error processes
Sections are convenient way to handle alternative courses of action Sections are a segment of a use case
executed out of sequence
Essential versus Real Use Cases Essential (black box) use case leaves out
technology and focuses only on functionality Real (white box) use case includes technology is
fundamental. E.g., essential Withdraw Cash from ATM use
case can mention identification or validation Only real Withdraw Cash from ATM use case
can mention a key pad or card reader
Extension Use Cases Users appreciate simplicity, so most use
cases leave out alternate courses Do this by extending the use case (see Use
Case Diagramming section below) while leaving the original use case alone
Use-case driven development Requirements are primarily recorded in the
Use Case model. Iterations are planned around implementing
particular Use Cases. Use Case Realizations drive design. Use Case often influence the way user
manuals are organized.
Diagramming Use Cases
read Chapter 30
Object-Oriented Analysis and Design
Actor
An actor is an idealized user 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 Actor Actors can be users,
processes, and other systems.
Non human actors typically shown as rectangle rather than stick figure
Usually not primary users, and thus are usually shown on the right
Inventory
System
Use Case Is a coherent unit of externally
visible functionality provided by a system and expressed by a sequence of messages
Additional behavior can be shown with generalize, extend, and include use case relationships
Labeled with the use case name
System
A system is shown as a rectangle, labeled with the system name
Actors are outside the system
Use cases are inside the system
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
An association is the communication path between an actor and the use case that it participates in
It is shown as a solid line It does not have an arrow, and is
normally read from left to right Here, the association is between a
Modeler and the Create Model use case
Include Relationship
Include relationships insert additional behavior into a base use case
They are shown as a dotted line with an open arrow and the key word <<include>>
Shown is a process that I observed in an earlier career
Extend Relationship
Extend puts additional, optional behavior in a use case that does not know about it.
It is shown as a dotted line with an arrow point and labeled <<extend>>
In this case, a customer can request a catalog when placing an order
Generalize Relationship
Is a relationship between a general use case and a more specific use case that inherits and extends its features
It is shown as a solid line with a closed arrow point
Here, the payment process is modified for cash and charge cards
Use Case Example: Alarm Clock
This is a contrivedexample, to showmany relations.Your diagrams
should be simpler.