Scribd
Upload
98 views11 pages

Fully Dressed Format

This document provides guidance on formatting use cases using the fully dressed format. It outlines sections to include such as primary actor, stakeholders and interests, preconditions and success guarantees, main success scenario and steps, extensions or alternate flows, and special requirements. The main success scenario describes the typical flow, while extensions cover other scenarios and branches. Preconditions state assumptions before a scenario, and success guarantees are what must be true after completion. Special requirements note any non-functional or quality aspects related specifically to the use case.

Uploaded by

Aurangzeb Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
98 views11 pages

Fully Dressed Format

This document provides guidance on formatting use cases using the fully dressed format. It outlines sections to include such as primary actor, stakeholders and interests, preconditions and success guarantees, main success scenario and steps, extensions or alternate flows, and special requirements. The main success scenario describes the typical flow, while extensions cover other scenarios and branches. Preconditions state assumptions before a scenario, and success guarantees are what must be true after completion. Special requirements note any non-functional or quality aspects related specifically to the use case.

Uploaded by

Aurangzeb Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Fully Dressed Format

Advance Software Engineering

Primary Actor
The principal actor that calls upon system
services to fulfill a goal.

Stakeholders and Interests List


This answers the question: What should be in the
use case? The answer is: Which satisfies all the
relevant stakeholders interests
It reminds us what the more detailed
responsibilities of the system should be

For example, would I have identified a responsibility


for salesperson Commission handling if I had not
first listed the salesperson stakeholder and their
interests?

Preconditions and Success Guarantees


(Postconditions)
Preconditions state what must always be true
before beginning a scenario in the use case
Typically, a precondition implies a scenario of
another use case that has successfully completed,
such as Logging in, or the more general "cashier is
identified and authenticated."
Note that there are conditions that must be true,
but are not of practical value to write, such as "the
system has power." Preconditions communicate
noteworthy assumptions that the use case writer
thinks readers should be alerted to.

Success Guarantee
Success guarantees (or post conditions) state what
must be true on successful completion of the use
caseeither the main success scenario or some
alternate path. The guarantee should meet the
needs of all stakeholders.
Preconditions: Cashier is identified and
authenticated.
Success Guarantee (Postconditions): Sale is saved.
Tax is correctly calculated. Accounting and
Inventory are updated. Commissions recorded.
Receipt is generated.

Main Success Scenario and Steps


(or Basic Flow)
This is also called the "happy path" scenario,
or the more prosaic "Basic Flow." It describes
the typical success path that satisfies the
interests of the stakeholders.
It often does not include any conditions or
branching.

Main Success Scenario: (Example)


1. Customer arrives at a POS checkout with items to
purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. ...
Cashier repeats steps 3-4 until indicates done.
5. ...
It is a common idiom to always capitalize the actors
names for ease of identification.
Observe also the idiom that is used to indicate
repetition.

Extensions (or Alternate Flows)


They indicate all the other scenarios or branches,
both success and failure.
The Extensions section is considerably longer and
more complex than the Main Success Scenario
section; this is common and to be expected. They
are also known as "Alternative Flows.
In thorough use case writing, the combination of
the happy path and extension scenarios should
satisfy "nearly" all the interests of the stakeholders.

Extension scenarios are branches from the main


success scenario, and so can be notated with
respect to it.
For example, at Step 3 of the main success scenario
there may be an invalid item identifier, either
because it was incorrectly entered or unknown to
the system. An extension is labeled "3a"; it first
identifies the condition and then the response.
Alternate extensions at Step 3 are labeled "3b
At the end of extension handling, by default the
scenario merges back with the main success
scenario, unless the extension indicates otherwise
(such as by halting the system).

Extensions:
3a. Invalid identifier:
1. System signals error and rejects entry.
3b. There are multiple of same item category and
tracking unique item identity not important (e.g., 5
packages of veggie-burgers):
1. Cashier can enter item category identifier and the
quantity.
An extension has two parts: the condition and the
handling.

Special Requirements
If a non-functional requirement, quality attribute, or
constraint relates specifically to a use case, record it
with the use case. These include qualities such as
performance, reliability, and usability, and design
Constraints (often in I/O devices) that have been
mandated or considered likely.
Recording these with the use case is classic UP advice
Special Requirements: (example)
- Touch screen Ul on a large flat panel monitor. Text must
be visible from 1 meter.
- Credit authorization response within 30 seconds 90% of
the time.
- Language internationalization on the text displayed.
- Pluggable business rules to be insertable at steps 2 and
6.

You might also like