Transcript 12.FacadeIteration

Use Case Descriptions
Chapter 4 – Facade Iteration
Initial Requirements
(Inception Phase)
17
1
First Real Cut at Application
Requirements
 Façade Use Cases
Amount to ‘placeholders’ for expanded use cases (to come).
Contain name and short description of the interaction;
contains initiating actors.
Verb…objects.
Typically, we do NOT know all the details.
Want to capture the ‘architecturally significant’ use cases…
(What are these???)
Trying to identify key functions / risks / interactions at a
global level.
2
Intro: Façade Use Cases
Ensure façade use cases are user-centric and
NOT technology-centric. Why? What does
this mean?
Again, these are the WHATS that the users
want!
Express in terms the users understand!
Involve various sources early and frequently
Many different stakeholders with diverse ‘takes’ on
the application…
3
Use Case Survey (Index) Entries
This is a Table of Contents for your Use Cases (that
will be developed). Single Sheet; table in Word
As you discover a Use Case, index it.
For each Use Case in the index (include a
designator (like UC1, US2, …), followed by the use
case name, short description (two or three
sentences), actors, level (façade, filled, focused)
date last updated (for now).
Book states (p. 73), “Façade use cases show the
basic, essential, high-level interactions that this
application must support (Constantine 1999).”
4
Façade Use case: Attributes (Rows)
Name of the use case – short name (verb, object); action words;
Actor(s) that trigger the use case…
Level (façade, filled, focused…)
Short Description – two three sentences: at the most!
Leave room for the Basic Course of Events…(happy path)
Pre and Post conditions, and more (see ahead…)
Trigger
Business Rules Link (Reference Business Rules in your Use Cases
(consider format on pg. 82 or other format)
Risk priority (reference your Risk List preferable by number or
identifier)
Link to text on non-functionals here, if desired
Date / author(s)
5
We will add attributes like Alternate Paths, Extensions…later)
Use Case Number:
03
Use Case Name:
Edit Member Account
Actor (s):
Buyer, Seller
Maturity:
Focused
Summary:
This use case is started by a Buyer or a Seller. It provides the capability for one of these
actors to edit their member profile.
Basic Course of Events:
Actor Action
1. This use case is started when a Buyer
or Seller elects to edit their member
profile.
Perform S1-Login
System Response
2. The System displays the
Actor’s member profile and prompts the Actor
to update it.
3. The Actor updates their member
profile.
4. The System validates the information
entered by the
Actor.
{Validate Information}
5. The System prompts the Actor for
confirmation.
6. The Actor confirms that the
information is correct.
{Profile Change}
8. This use case concludes when the
Actor receives visual confirmation of the
update.
7. The System updates the
Actor’s member profile to the member
repository and informs the Actor that the
information was updated successfully.
6
Continuing….
Alternate Paths:
A1 Change Member Profile
At {Profile Change} the Member indicates that he/she entered incorrect information.
The System immediately returns to the step 2.
Exception Paths:
E1 Handle Invalid Information
At {Validate Information} if any fields are entered incorrectly.
The System indicates the fields that were entered incorrectly and prompts the Buyer or
Seller to make the necessary corrections.
The flow of events is resumed at Basic Flow Step 2.
Extension Points:
{Change Profile }, {Validate Information}
Triggers:
The Buyer or Seller would like to edit their member profile.
Assumptions:
The Buyer or Seller is aware of the steps required to edit their member profile.
Preconditions:
The System is functioning properly.
Actor already has a Profile stored in the Profile Database???
Post Conditions:
The member profile was successfully updated to the member repository. Actor sent email
to confirm changes.
Reference - Business Rules:
See Business Rules section: 2.3.1 and 2.3.5.
Reference - Risks:
See Risks List sections: 2.1 and 2.4.
Author (s):
Team3
Date:
11-04-04
7
Think About Non-Functional
Requirements
Note the significant list of non-functional requirements on
pp. 76-77.
Be aware of a number of examples of non-functional
requirements that may be addressed in your application.
Availability, compatibility, data integrity, extensibility,
interoperability, maintainability, performance, portability, reliability,
robustness, scalability, security, usability / achievability
Know these! (be able to identify them…)
Document these per use case, as shown on page 4.1.
Non-functionals normally not tied to specific use cases;
normally threaded through a number of use cases.
In RUP: Analysis Mechanisms…
Capture in a Table
Go into Supplementary Specifications Document…
8
Verbiage in Use Case
Use Verb-object phrases (stated before…)
Sell Houses, Enroll in Course; Maintain Book…
Should not be instances of classes
Should not be tied to an organization structure, paper forms
or computer implementation
Refer to Prototype to see actions an actor expects to
undertake…(ahead)
Use phraseology from Prototype and Domain Model in text.
Interface items and domain entries will become objects ahead….
Nice technique: Bold items in Use Case Specifications for which
there is a glossary entry or a business entity in the Domain Model
9
Candidate Use Case List
Ensure each Use Case is ‘in scope.’
Actors must reflect the roles that people play – not the
actual names of people.
Note: Use Cases will often have multiple actors.
Again: (repeating…)
Use Cases must provide or receive a value from the system
Do not tie your actors to your organization chart.
10
User Interface Prototype
Use storyboarding to elicit major, high-level enduser requirements.
Document the interactions as seen in the
storyboards as high level text to identify the
Façade Use Cases.
The details of the interactions (and likely more
detailed user interface prototypes) will be used to
capture the interactions for focused and filled use
cases later.
More on prototyping in the next series of slides.
11
Verb Filter and Noun Filter
Use strong verbs (See table in textbook)
Use strong, concrete nouns. (See table)
Avoid weak nouns such as data, report,
system, form, template, paper…
12
Façade Filter
Façade use cases represent the most important
interactions between the actors and the system.
Don’t worry too much about non-functional
requirements at this time. Will address more later.
Façade use cases should be relatively abstract – so
that they will cover a number of actual proposed
interactions (scenarios).
Certainly no implementation details.
Façade use cases contain NO basic course of
events….Only trying to identify significant Use
Cases – for their functionality, their actors, pre and
post conditions, triggers, and key attributes…
13
Reviews
Peer Reviews:
Review the use cases carefully.
Have a ‘SME’ available for business domain questions.
Have reviews often and informally
User Reviews:
User review of your Façade use cases is critical.
Every hour you spend in review could save many hours of
work later!!!
I RECOMMEND THAT TEAMS REVIEW EACH
OTHER’S USE CASES!!
Use Cases capture functional requirements…
Sometimes called Requirements Analysis…I like to keep
‘Requirements’ and ‘Analysis’ somewhat separate. 14
Packaging
You need to build packages of Use Cases (do
this in Rose) to group Use Cases of similar
‘value’ or ‘functionality’
Create packages of Actors too in the Use Case
View
Name your packages. These are essential
components of your architecture!!
15