Requirements Analysis - The purpose of requirements analysis is to
understand some of the goals of the computer system that we will design.
•Use case model
Use cases - provide a way of describing the functional requirements through
stories of using the system.
•a use case is a text story of some actor using a system to meet goals.
•Use cases are not diagrams. They are TEXT.
•Use cases are NOT object-oriented artifacts! They feed into other OO models.
Actors - Anything with behavior that triggers use case execution.
•Three kinds of actors:
–Primary Actor accomplishes goals via use case
•Example: the cashier
–Secondary Actor provides a service to use case (often a computer system,
but could be an organization)
•Example: the automated payment authorization service
–Offstage actor is interested in use case results
•Example: government tax agency
Scenarios - a specific sequence of actions and interactions between actors and the
•It represents a one possible path through the use case.
Three possible use case formats
•Write in an ‘essential’ UI-free style.
–“Keep the interface out; focus on intent.”
•Write terse use cases, i.e., make your style “brief and to the point;
–Delete “noise” words, even if it is small word:
•Say “System authenticates ...”, rather than “The system
•Brief format: one paragraph summary usually of the main success scenario
•Casual format: multiple paragraphs that cover various scenarios.
•Fully dressed: all steps and variations are written in detail. In addition, there
are supporting sections such as preconditions and postconditions.
•Use case Name in ‘Verb Noun’ format
•Close Account, Process a Sale
•The system under design
•Stakeholders and interests
•Who cares about this use case and what they want
•What must be true on start and worth telling the reader
•Postconditions (or Success Guarantee)
•What must be true upon completion of the use case, and worth telling
•Base Scenario (or Main Success Scenario)