|
| |
Purpose
The purposes of Requirements are:
- To come to an agreement with the customer and the users on what the
system should do.
- To give system developers a better understanding of the requirements on
the system.
- To provide a basis for planning the technical contents of iterations.
- To define a user-interface for the system.
To achieve these goals, Stakeholder Requests are gathered and analyzed, a
Vision document, a use-case model use cases and Supplementary Specification
are developed that describes what the system will do
- an effort that views all stakeholders, including customers and potential
users, as important sources of information (in addition to system
requirements).
For a complete definition of the software requirements, use cases and
Supplementary Specifications may be packaged together to define a Software
Requirements for a particular "feature" or other subsystem
grouping.
The Vision document states the overall goals of the project and main
features of the system.
Stakeholder Requests are gathered to get a "wish list" of what
different stakeholders of the project (customers, users, product champions)
expect the system to include, together with information on how each request
has been considered by the project.
The use-case model can serve as a contract between the customer, the
users, and the system developers, which allows:
- Customers and users to validate that the system will become what they
expected.
- System developers to build what is expected.
The use-case model consists of use cases and actors. Each use case in the
model is described in detail, showing step-by-step how the system interacts
with the actors, and what the system does in the use case. Use case function
as a unifying thread throughout the software lifecycle; the same use-case
model is used in system analysis, design, implementation, and testing.
The Supplementary Specifications are an important complement to the
use-case model, because together they capture all software requirements
(functional and nonfunctional) that need to be described to serve as a
complete software requirements specification.
Artifact
Requirements Management Plan
Describes the guidelines used in the project for establishing the
requirements documents, requirement types and their respective requirements
attributes
Use-Case Modeling Guidelines
Describes the use-case modeling guidelines
Business Use-Case Model
The business use-case model is a model of the business intended
functions. The business use-case model is used as an essential input to
identify roles and deliverables in the organization
Glossary
The Glossary defines important terms used in the project.
Vision
The Vision is a general vision of the core project's requirements, and
provides the contractual basis for the more detailed technical requirements
Stakeholder Requests
This artifact contains any type of requests a stakeholder (customer, end
user, marketing person, and so on) might have on the system to be developed.
It also contains references to any type of external sources to which the
system must comply.
Use-Case Model
The use-case model is a model of the system's intended functions and its
environment, and serves as a contract between the customer and the
developers. The use-case model is used as an essential input to activities
in analysis, design, and test.
Supplementary Specifications
The Supplementary Specifications capture the system requirements that are
not readily capturable in the use cases of the use-case model. Such
requirements include:
- Legal and regulatory requirements and application standards.
- Quality attributes of the system to be built, including usability,
reliability, performance and supportability requirements.
- Other requirements such as operating systems and environments,
compatibility requirements, and design constraints.
Requirements Attributes
This artifact contains a repository of project requirements, attributes
and dependencies to track from a requirement management perspective.
Change Request
Changes to development artifacts are proposed through Change Requests (CRs).
Change Requests are used to document and track defects, enhancement requests
and any other type of request for a change to the product. The benefit of
Change Requests is that they provide a record of decisions, and, due to
their assessment process, ensure that change impacts are understood project
wide.
Use Case Storyboard
A use-case storyboard is a logical and conceptual
description of how a use case is provided by the user interface, including
the interaction required between the actor(s) and the system.
User-Interface Prototype
A user-interface prototype is a prototype of the user
interface. For example, the prototype can manifest itself as:
- paper sketches or pictures;
- bitmaps from a drawing tool;
- an interactive executable prototype (e.g., in Microsoft® Visual Basic®).
Relation to Other Workflows
The Requirements workflow is related to other process workflows.
- The Business Modeling workflow provides an organizational context for
the system.
- The Analysis & Design workflow gets its primary input (the use-case
model and the Glossary) from Requirements. Flaws in the use-case model can
be discovered during analysis & design; change requests are then
generated, and applied to the use-case model.
- The Test workflow tests the system to verify the code
against the Use-Case Model. Use Cases and Supplementary Specifications
provide input on requirements used in planning and designing tests.
- The Environment workflow develops and maintains the supporting artifacts
that are used during requirements management and use-case modeling, such
as the Use-Case-Modeling Guidelines and User-Interface Guidelines.
- The Management workflow plans the project,
develops the Requirements Management Plan, and each iteration (described
in an Iteration Plan). The use-case model is an important input to the
iteration planning activities.
Concepts
Traditionally, requirements are looked upon as statements of text fitting
into one of the categories mentioned in Concepts: Requirements. Each
requirement states "a condition or capability to which the system must
conform".
To perform effective requirements management, we have learned that it helps
to extend what we maintain as requirements beyond only the detailed
"software requirements". We introduce the notion of requirements
types to help separate the different levels of abstraction and
purposes of our requirements. Each requirement type will have a unique set of
attributes associated with each requirement defined at that level.
We may want to keep track of ambiguous "wishes", as well as
formal requests, from our stakeholders to make sure we know how they are taken
care of. The Vision document helps us keep track of key "user needs"
and "features" of the system. The use-case model is an effective way
of expressing detailed functional "software requirements", therefore
use cases may need to be tracked and maintained as requirements, as well as
perhaps individual statements within the use case properties which state
"conditions or capabilities to which the system must conform".
Supplementary Specifications may contain other "software
requirements", such as design constraints or legal or regulatory
requirements on our system. For a complete definition of the software
requirements, use cases and Supplementary Specifications may be packaged
together to define a Software Requirements Specification (SRS)
for a particular "feature" or other subsystem grouping.
Test cases are ways of stating how we will verify what the system actually
does, and therefore we may also want to track these by maintaining separate
"test requirements". Similarly, we may wish to track
"documentation requirements" for those requirements relating to how
a technical writer may need to develop end-user support documentation and
training material.
The larger and more intricate the system developed, the more expressions,
or types of requirements appear and the greater the volume of requirements.
"Business rules" and "vision" statements for a project
trace to "user needs", "features" or other "product
requirements". Use cases or other forms of modeling and other
Supplementary Specifications drive design requirements, which may be further
decomposed to functional and non-functional "software requirements"
represented in analysis & design models and diagrams. "Test
requirements" derived from the above decompose to test procedures and
other testing artifacts.
Concepts: Traceability
The purpose of establishing traceability is to help:
- Assess the project impact of a change in a requirement
- Assess the impact of a failure of a test on requirements (i.e. if test
fails the requirement may not be satisfied)
- Manage the scope of the project
- Verify that all requirements of the system are fulfilled by the
implementation.
- Verify that the application does only what it was intended to do.
Traceability helps you follow how stakeholder requests are translated
into a set of key stakeholder needs and system features as specified in the
Vision document and use-case model. These in turn are detailed into use
cases and other requirements in the Supplementary Specifications. You then
need to follow how these detailed specifications are translated into a
design, how it is tested, and how it is documented for the user. For a large
system, use cases and Supplementary Specifications may be packaged together
to define a Software
Requirements Specification (SRS)
for a particular "feature" or other subsystem grouping.
A key concept in helping to manage changes in requirements is that of a "suspect"
traceability link. When a requirement (or other traceability item)
changes at either end of a traceability link, all links associated with that
requirement are marked as "suspect". This flags the responsible
worker to review the change and determine if the associated items will need
to change also. This concept also helps in analyzing the impact of potential
changes.
Traceabilities may be set up to help answer the following sample set of
queries:
- Show me user needs that are not linked to product features.
- Show me the status of tests on all use cases in iteration #n.
- Show me all supplementary requirements linked to tests whose status is
untested.
- Show me the results of all tests that failed, in order of criticality.
- Show me the features scheduled for this release, which user needs they
satisfy, and their status.
|
