A Use Case-Driven Approach to Requirements Gathering

1
A Use Case-Driven Approach to Requirements
Gathering

• Materials gathered from Chapter 3 (above) Kulak
  and Guiney and
• Use Case Driven Object Modeling Doug Rosenburg
  and other personal notes.

2
Guiding Principles to Requirements Gathering

• Reduce Risk
• Focus on business interactions
• Reduce volume
• Reduce duplicates and inconsistencies
• Create requirements that users can understand
  easily
• Create requirements that are useful to designers,
  developers, and project managers
• Leave a requirements trail
• Leave design until later
• Keep the plan in mind.

3
Mission, Vision, Values

• Many think this is the first document. Arguable.
  But certainly worth thinking about
• Vision What will the end product be?
• Future. Vision of operations and filling needs
• Mission What will with project do?
• Immediate now. How will it work? Will it
  fulfill the needs of the stakeholders?
• Values What principles will guide the project
  while they do what they will do and build what
  will be
• What principles underpin what we do?
  Organization seeking quality products
  integrity communications, etc.

4
Steps in Gathering Requirements

• Requirements are created iteratively.
• Iteration means doing things over and over
  enriching the value of the artifacts, etc.
• Increments refer to the gradual, piece by piece
  evolution of the application building on
  earlier work.
• Requirements specs will change frequently due to
  reliance on other peoples ideas about the
  application.
• other artifacts may tie back to requirements,
• sometimes only tie back to fuzzy ideas.

5
Steps

• We consider the Vision Document (which might
  include Mission, Vision, Values, and a host of
  other items, such as scope, objective, overview,
  user demography, constraints, assumptions,
  staffing, costs, environment, etc.) as a primary
  step.
• This defines the scope and general overview of
  work to be accomplished.
• All these documents tied to vision and initial
  business modeling include risk analyses, business
  rules, etc.
• These are essential artifacts.

6
Steps - continued Steps - continued

• Prototype
• Used to identify the user interface NO MORE!
• Will identify requirements missed.
• Recognize emphasis is on requirements not the
  specific widgets (buttons, etc.) used.
• These are implementation details which will be
  decided upon later.

7
Steps Use Case - Driven

• The Use Case model is at the conceptual center of
  the entire approach because it drives everything
  else that follows.
• Oftentimes developed in conjunction with Domain
  Model because the text of the Use Case supports
  development of the Domain Model.
• Helps to identify nouns (entities and attributes)
  and verbs (responsibilities)
• Drives Analysis Model (preliminary design)
• Drives Interaction diagrams (ahead) refine
  analysis model into a detailed design model using
  objects identified in creating the analysis model
  and showing how messages flow between objects
  within use cases.
• Requirements Tracing involves connecting user
  requirements with use cases and classes.
• Use Cases drive entire development effort.
• Discuss.

8
Use Cases

• Use Cases are sequences of actions that an actor
  (usually a person, but certainly can be an
  external entity like another system or a device)
  performs with an expectation of achieving a
  particular result gets value.
• Always use present tense very in active voice.
• Model Use Cases via Use Case Diagrams
• Capture Use Cases (that is, the interactions) via
  Use Case Narrative (Use Case Scripts)

9
Lets review and add some detail
10
Early Deliverables

• Most efforts start with a Business Modeling
  effort (domain analysis) and the capturing the
  Domain via Domain Modeling, Glossary, and
  associated artifacts .
• Related artifacts typically include some kind of
  vision document that include
• Risk Analysis (may be included in Vision
  Document or as an adjunct artifact)
• Business Rules (see textbook page 61-62) for more
  examples.
• Vision Statements short encapsulating
  statements outlining vision.
• Environmental Constraints and more
• There are a number of approaches
• ? Most uses cases are defined during the same
  iteration
• ? Typically a first cut of key use cases may be
  developed as part of the Inception Phase
  generally around 20 of use cases (key ones)
• But they are refined via subsequent iterations to
  provide increasing levels of detail
• These details are absolutely required to drive
  the entire development process.

11
Statement of Work

• Most development projects have some kind of
  Statement of Work (SOW) How the work is going to
  be accomplished work plans, assignments,
  internal deliverables, etc.
• Represents a contract between the developers and
  the users and/or a contract between a consulting
  company and the customer.
• See textbook for details.
• It is generally more than just bullets can be
  bullets, but should have more assignment
  details

12
Risk Analysis

• A list of risks that may impact the successful
  development of the application.
• You now need to revisit these and prioritize by
  impact. (probability of occurrence cost if
  occurs) other formulas
• Provides data as to whether the development
  effort should start/proceed.
• Risk MUST be addressed and mitigated.
• Risk is consistently re-addressed as part of
  assessment following every iteration

13
Business Rules Artifact

• Business Rules are both written and unwritten
  rules that govern how the company does business.
• relate to the specific application only
• Examples discounts to seniors discounts if
  order is gt some magic number corporation
  discounts
• We use use cases and business rules very closely.
• Use Case templates should have a Business Rules
  attribute (row) that cites references to any
  business rules that is associated with the use
  case
• While Use Cases address the functional
  requirements by covering interactions between the
  client and the application, these interactions
  are often governed by business rules that dictate
  the environment and constraints within which the
  application operates.

14
Closer Look on Business Rules

• May be conditions that must be true/false
• Action restricting conditions prohibiting an
  action (dont accept a bad check)
• Action triggering
• Inferences drawing a conclusion from conditions
  that may be/become true
• Calculations formulas / discounts. etc.
• Must be atomic!!
• means must be stated at the finest level of
  granularity possible.
• As stated see Use Case textbook, Table 3.3, p.
  61 for examples.

15
Prototype

• Mock-up of user interface. Storyboarding
• Graphical or pictures clearly and perhaps
  interactively.
• Introduced now refined later after the
  requirements have stabilized a bit. Avoids
  temptations to proceed solving problems before
  they are understood.
• Prototype demonstrates a proof of concept
• It also forms the rough basis for a user manual
  as if the prototype were a working system
• Prototype should be rapid.
• Means ignore many alternatives (exceptions)
• After closure on screens/windows, this greatly
  facilitates locking in the Use Cases that
  realize descriptions of the interface just
  demonstrated.
• Also greatly facilitates identification of
  boundary objects (along with Use Cases) for our
  analysis modeling effort (preliminary design).

16
Prototype

• Prototype can be simple.
• Generic symbols (buttons may later become drop
  down menu.not terribly important at this time.)
• Should contain some kind of windows navigation
  diagrams and perhaps action resulting in
  navigating to a new menu/window.
• Can link your screen designs to your use cases
  either manually or in context of a visual -
  modeling tool
• Coupling between screens and text is intuitive.
• Be careful Your use case text (coming) should
  not include too many presentation details, since
  these are design considerations, and we are
  really trying to lock in requirements not show
  implementation.

17
Warning

• Whether you use prototyping, screen mockups, or
  the results of mining legacy user manuals, its
  important that you do a thorough job before you
  start writing use case text. If you dont, you
  could end up spending a lot of extra time trying
  to pin down what your users expect to be doing
  with the new system.
• Dont try to write use cases until you know what
  the users will actually be doing!!
• Great way to learn this is through user interface
  prototyping.
• ? Note some advocate building use case text
  and prototypes (also domain model) at the same
  time or near the same time, in that they can
  act as checks (validation) on each other.

18
Role of Use Cases

• The Use Cases are clearly the major artifacts of
  Requirements Gathering efforts.
• Use Cases great for communications
• contain the essence of desired interactions.
• no jargon as found in DFDs, ERDs, etc.
• Particularly good for Functional and to a lesser
  degree (in some cases) non-functional
  requirements. (performance, extensibility,
  maintainability, backup, recovery, security,
  persistency, distribution, etc.) But these
  latter requirements are normally documented in a
  Supplementary Specs document
• Good for ensuring requirements traceability
  because they are used for design, testing,
  construction, delivery, and ...

19
Role of Use Cases

• When used to drive the lifecycle, they assure
  stakeholders that all use cases are being
  addressed in the development effort.
• Use cases discourage premature design. If the
  use cases narrative has several steps before
  responding to the user, this is a tip off that we
  are undertaking too much designingSTOP!
• Remember these are still the WHATS of the
  application!