The set of Use Case descriptions specifies the complete functional requirements of a system. Describe Business process. It can be written only for functional requirements. Not good for specifying user interfaces, data formats, business rules, non-functional requirements.
Use Case is
- easy to read.
- It is written in the language of the user.
- Can be visually represented as diagrams.
- Used for creating acceptance test cases in coordination with customers.
Actors in Use Case
- Actors are entities that interact with the system.
- Actors live outside the boundary of the system.
- Actors can be human beings, hardware device, software service or other organization.
Type of Actors
- Primary actor triggers the execution of use case in the process.
- Primary actor is one who calls the system to deliver a service.
- User – Insert ATM card to initiate withdrawal of money.
Supporting actor provides service to the system and helps the primary actor to achieve the goal.
Helps in identifying external interfaces to the system.
- Printer Drivers
- Web Service
- It is state of the application which needs to be set prior to the execution.
- It should always be true before beginning.
- Is assumed to be true and it is not tested.
- It must be true on successful completion, either the main success scenario or some alternate path.
- A post condition should be true regardless of which alternative flows were executed.
Paths / Flows
- Normal Path
- Alternate path
- Exceptional Path
- Error Path
- Use common template.
- Create a list of primary actors and their goals.
- Make it is clear, short and easy to read. Use active voice, present tense, make sure actor and actor’s intent are visible in each step.
- Every use case has two possible endings success or failure. Don’t forget to gather both.
- It restricts to capture system behavior.