Requirements discipline throughout the SDLC
What two documents come after the requirements specification document?
Let's start by discussing requirements as a discipline performed in the context of a software application development process such as the Rational Unified Process (RUP) -- just to name one as a common reference. A documented, repeatable process such as Rational Unified Process places structure around the activities performed and the resulting artifacts, also known as deliverables. Related to the analyst's role, RUP includes the following disciplines: Business modeling: Provides guidance for the analyst on how to understand and visually depict a business.
Requirements: Involves finding, maintaining and managing requirements for the business application. The business models developed in the business modeling discipline are a key input to these activities.
Analysis and design: Transforms the requirements into a design of the system-to-be and adapts that design to match the implementation environment, designing it for performance. The analyst can discover flaws in design. Change requests are generated and applied. Business entities in the business modeling discipline are also an input to identifying analysis and design solutions.
Implementation: Defines the organization of code, implements classes and objects, tests the resulting implementation elements, and integrates them into an executable system. This discipline includes developer testing -- that is, testing done by developers to verify that each developed element behaves as intended. This behavior derives ultimately, although often indirectly, from requirements captured by the analyst.
Test: Validates the system against (amongst other things) the requirements, ensuring that the system works properly. Requirements artifacts provided by the analyst are the basis for the definition of the evaluation activities.
Deployment: Describes the activities associated with ensuring that the software product and related materials are available for end users. The analyst produces the software requirements specification, which is one of the key inputs to development end user support and training materials.
Configuration and change management: Supports the analyst with the process of change, ensuring that changes are effectively documented and accepted during the lifecycle of the project. This also allows the analyst and those in other roles to do impact analysis.
Project management: Plans the project and each iteration and phase of the project. The requirements artifacts, particularly the requirements management plan, are important inputs to the planning activities. The driving forces behind the assessment and management activities are the requirements.
Environment: Develops and maintains the supporting artifacts that the analyst uses during requirements management and modeling.
Requirements discipline artifacts
Now let's focus specifically on the activities and resulting artifacts of the requirements discipline -- again using Rational Unified Process as a common frame of reference:
||Key resulting artifacts
|Analyze the problem
||Capture a common vocabulary, develop vision, identify end-user classes, and develop requirements management plan.
Use case model
Requirements management plan
|Understand stakeholder needs
||Capture a common vocabulary, develop vision, elicit stakeholder requests, identify end users and manage dependencies.
Actor (user) list
Use case model
|Define the system
||Develop vision, capture a common vocabulary, identify end users and manage dependencies.
Use case model
|Manage the scope
|| Develop vision, manage dependencies and prioritize user goals.
Software architecture document
|Refine the system definition
||Detail user goals and detail software requirements.
Software requirements specification
|Manage changing requirements
||Review requirements, manage dependencies and structure user goal modeling.
Use case model
The requirement artifacts as key inputs
The artifacts resulting from the requirements discipline are inputs to the activities for the subsequent disciplines (for example, analysis and design) in the project lifecycle as shown in Figure 1. Within each of these subsequent disciplines are their respective activities and resulting artifacts.
FIGURE 1: Rational Unified Process discipline relationships
There are numerous artifacts (deliverables) that follow the software requirements specification. That is, the software requirements specification is a key input to multiple activities and resulting artifacts within an application development process. A short list of examples of resulting artifacts from activities performed in disciplines that follow the requirements discipline is included in the table that follows. Each organization should define their application development process, which includes defined roles, activities and artifacts. The process should also indicate relationships between the roles and activities that span across each discipline in order to understand the order that activities are performed.
|Discipline following requirements
||Example RUP resulting artifacts
|Analysis and design
||Software architecture document
Design model (e.g. data model, class diagram)
Use case realization
||Integration build plan
Test log/test results
Implementation element (e.g. source code)
||Test plan Test strategy Test script Test results Change request
|Configuration and change management
||Change control plan Project repository
||Deployment plan Training materials Test evaluation summary Installation artifacts
This was first published in April 2008