|
© |
|
|
© |
|
|
© |
Functional requirements and use case |
|
© |
|
|
© |
|
|
© |
|
|
© |
|
|
|
|
|
Functional
Requirements and Use Cases |
| |
FUNCTIONAL
REQUIREMENTS |
| |
Functional
requirements capture the intended behavior of the
system. This behavior may be expressed as services,
tasks or functions the system is required to perform.
In product development, it is useful to distinguish
between the baseline functionality necessary for any
system to compete in that product domain, and features
that differentiate the system from competitors' products,
and from variants in your company's own product line/family.
Features may be additional functionality, or differ
from the basic functionality along some quality attribute
(such as performance or memory utilization).
|
| |
One
strategy for quickly penetrating a market, is to produce
the core, or stripped down, basic product, and adding
features to variants of the product to be released
shortly thereafter. This release strategy is obviously
also beneficial in information systems development,
staging core functionality for early releases and
adding features over the course of several subsequent
releases. |
| |
In
many industries, companies produce product lines with
different cost/feature variations per product in the
line, and product families that include a number of
product lines targeted at somewhat different markets
or usage situations. What makes these product lines
part of a family, are some common elements of functionality
and identity. A platform-based development approach
leverages this commonality, utilizing a set of reusable
assets across the family. |
| |
These
strategies have important implications for software
architecture. In particular, it is not just the functional
requirements of the first product or release that
must be supported by the architecture. The functional
requirements of early (nearly concurrent) releases
need to be explicitly taken into account. Later releases
are accommodated through architectural qualities such
as extensibility, flexibility, etc. The latter are
expressed as non-functional requirements. |
| |
Use
cases have quickly become a widespread practice for
capturing functional requirements. This is especially
true in the object-oriented community where they originated,
but their applicability is not limited to object-oriented
systems. |
| |
.......................................................................................................................................... |
| |
|
| |
USE
CASES |
| |
Each
use case defines a goal-oriented set of interactions
between external actors and the system under consideration.
Actors are parties outside the system that interact
with the system UML 1999, pp. 2.113- 2.123). An actor
may be a class of users, roles users can play, or
other systems. Cockburn (1997) distinguishes between
primary and secondary actors. A primary actor is one
having a goal requiring the assistance of the system.
A secondary actor is one from which the system needs
assistance. |
| |
A
use case is initiated by a user with a particular
goal in mind, and completes successfully when that
goal is satisfied. It describes the sequence of interactions
between actors and the system necessary to deliver
the service that satisfies the goal. It also includes
possible variants of this sequence, e.g., alternative
sequences that may also satisfy the goal, as well
as sequences that may lead to failure to complete
the service because of exceptional behavior, error
handling, etc. The system is treated as a "black
box", and the interactions with system, including
system responses, are as perceived from outside the
system. |
| |
Thus,
use cases capture who (actor) does what (interaction)
with the system, for what purpose (goal), without
dealing with system internals. A complete set of use
cases specifies all the different ways to use the
system, and thus defines all behavior required of
the system, bounding the scope of the system. |
| |
Generally,
use case steps are written in an easy-to-understand
structured narrative using the vocabulary of the domain.
This is engaging for users who can easily follow and
validate the use cases, and the accessibility encourages
users to be actively involved in defining the requirements. |
| |
|
|
|
|
|
