Information Technology Reference
In-Depth Information
1. Prototyping can be used to develop early executable versions of the require-
ments model. Prototyping may be costly which is not the ultimate solution
when working with a fixed budget.
2. Quality Function Deployment (QFD) is another useful technique for validation.
QFD helps to identify user requirements that have not been addressed by the
developer, as well as developer-proposed features that do not support any
requirements. In addition to highlighting such omissions, QFD also documents
requirements that are highly rated by the user and receive little attention by the
developer-proposed features.
3. Requirement Reviews: The Requirements are analyzed by a team of reviewers.
Requirement reviews could be either formal or informal.
4. Test case generation: Requirements should be testable. If the tests for the
requirements are devised as part of validation process, this reveals requirement
problems.
5.6 Producing the Use Case Model
A 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. 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 is considered successful
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 the 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 therefore defines all behavior required of the system, defining 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. Also the increased accessibility
encourages users to be actively involved in defining the requirements.
Scenarios
A scenario is an instance of a use case, and represents a single path through the
use case. Thus, one may construct a scenario for the main flow through the use
