|
|
 |
| |
| Software Engineering Process |
| |
|
Requirements
Requirements is the most important of the SEP's disciplines. It includes the capture of the system's business and supplementary
requirements as well as the initiation of traceability activities for these requirements. For applications developing in an
iterative fashion, the iteration plan, which spells out the requirements to be tackled during a particular iteration, is also a
major artifact of this discipline.
|
| |
|
Discipline Details
The requirements discipline is the largest and, arguably, most important of the SEP's disciplines. Well-established and detailed
requirements provide a solid foundation for the construction of an application. Less defined requirements cost the project time
and money; while becoming increasingly costly the longer it takes to uncover the deficiency, reconcile the requirement, and fix
any other corresponding application functionalities tied to that requirement. During this discipline, the business use cases
completed during business modeling are elaborated into more detailed system use cases. In addition, existing use cases may be
modified to address defects or support requests for additional functionality.
Based upon whether an iterative flavor of development is being used, an iteration plan, which derives from the master project plan
and stipulates iteration-specific tasks, may or be necessary. Irrespective of the development model being used, requirements will
need to be managed over time and, more importantly, changes to requirements will need to be assessed for their impact on changes
to the application. The traceability matrix is a critical artifact that enables tracing of the impacts of requirements changes
across the other SEP disciplines.
|
| |
|
Activities
Requirements activities are completed primarily by business analysts in conjunction with Agency staff and end users. The primary
activities completed during this discipline are:
|
|
- Requirements capture
- Requirements management
- Use case refinement
- Establishing requirements traceability
|
|
Artifacts
Seven artifacts are produced or refined as part of the requirements discipline. These artifacts are:
|
|
- Defect and Request Report - The defect and request report artifact is an output of the change management process and input
into the requirements discipline. System defects and new feature requests are recorded and collected throughout the application
development lifecycle and then reviewed as part of requirements activities for modification of existing use cases, creation
of new use cases, deferral, or closure.
- System Use Cases - The system use case artifacts are the key artifacts created during the requirements discipline. These
artifacts represent the cornerstone of solid application design and implementation. The use cases establish the required system
behavior in response to external actor stimuli. The system behavior may take one of several paths based upon the varying business
conditions.
- Supplementary Specifications - The supplementary specification artifact captures requirements that are not directly associated
with a single system use case. Such requirements could include software quality attributes, cross-cutting system concerns,
overarching legal, regulatory, or organizational constraints, or other detailed technical, operational, or organizational imperatives.
- Requirements Management Plan - The requirements management plan establishes control mechanisms and specifications for the
collection, measurement, reporting, and changing of the application's requirements. The requirements management plan further refines
change management plans and procedures established as part of the project management process.
- Software Requirements Specification - The software requirements specification (SRS) aggregates the varying types of requirements,
from business use cases to requirements from the supplementary specifications. The SRS presents the complete picture of the
application's software requirements, including particular views such as the use case model, which may not be explicitly included in
other requirements discipline artifacts.
- Traceability Matrix - The traceability matrix artifact is established during the requirements discipline and is expanded with the
traceability details in each of the subsequent disciplines. This artifact details the allocation of requirements to design and
implementation elements, tests, and other artifacts, as appropriate. This artifact is especially useful in helping to ensure that all
requirements are met as well as locating affected system components when there is a requirements change.
- Iteration Plan - The iteration plan is an optional artifact in the requirements discipline that is specific to projects using an
iterative development model. The iteration plan refines project planning artifacts from the project management process, detailing
fine-grained activities that are needed to complete a particular iteration within a defined iteration time box (usually 2 - 6 weeks).
|
|
Tools
There are two primary tool groups used to support requirements activities and produce artifacts for this discipline. These tools are:
|
|
- Defect / Request Management Tools - Refers to a set of tools used to capture and report on system defects and enhancement requests.
This tool may or may not be the same tool used to manage change control activities for the larger project.
- Requirements Management Tools - Requirements management tools are used to capture detailed system use cases during this iteration. These
tools may use database and/or file-based storage to store requirements and allow for a wide range of configuration options to suit most
projects' needs.
External Dependencies
The requirements discipline is dependant upon both external processes and other SEP-internal disciplines. The requirements management plan extends
the change management plan developed during the EPMM, while the iteration plan extends the EPMM project plan. Both the system use cases and the
supplementary specifications represent further refinements of the business use cases developed as part of the business modeling discipline.
|
|
|
|
|
|
