| What is a Use Case? |
| A Use Case is a procedural definition of functional
requirements written in prose. It defines a way in which a computer might be used by a
user. It is made up largely of interactions across the system boundary which define an
outside-in black box view of what the system will do
|
from a user's perspective. Use cases
were defined by Ivar Jacobson in 1992 and have since become an integral part of UML. Use
cases are easy to understand for non-technical users but hard to write properly. They can
also be used for modelling business processes. |
| What is a Use Case Diagram? |
| The functional requirements of a computer system can
be shown on a set of use case diagrams which summarise all the system will do. It shows
what use cases are used
|
by what external user roles and all systems and users
with whom the system will interact. As such it graphically defines the functional boundary
of the system. |
| A User's View |
| Use cases are designed to be a user's view of the
system and as such are for everyone, including non-technical staff, to understand.
They provide hooks for user's to hang ideas on and as such can be used as a
|
technique for eliciting vaguely understood requirements. Use
cases provide a mechanism for validating 100% coverage of user's requirements and can be
derived from, and traced back to business process descriptions. |
| Integrates with Screen Prototyping |
| Use cases can be integrated with screen prototyping as
part of a user requirement's workshop. Between the two of them they provide two orthogonal
views of functional requirements that can be cross-verified. Because use
|
cases and screen prototypes are linked, they can be
used to provide units of functionality for development. One increment in an overall
project is defined by the implementation of a number of use cases and screens. |
| Integrates With System Test |
| A use case defines a procedure by which a system can
be used and so forms the basis of a system-level test. Testers can produce a series of
scenarios in order fully to test that a use case or screen does all that it should and
nothing that it shouldn't.
|
This makes traceability of requirements through to
test results very easy. The other views that are produced in UML during system analysis
also provide comprehensive functional information to test developers and allow the
development of more effective test scripts |
| Inherent Traceability |
| Use cases trace naturally through to analysis and
design models providing documentation of the implementation of each and every functional
requirement in the code.
|
This in turn allows an impact analysis to be performed
on any functional requirements change request. |
| Use Cases Drive Incremental Development |
| Use cases can be used to schedule an incremental
development project and drive the whole development process. Most of the modelling that is
performed relates
|
to implementing Use cases and can be scheduled
as such. An increment produces a set of tested and working executables that implement a
number of Use Cases. |
