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.
||Glossary Vision Use case model Requirements management plan Requirements attributes
|Understand stakeholder needs
||Capture a common vocabulary, develop vision, elicit stakeholder requests, identify end users and manage dependencies.
||Glossary Vision Actor (user) list Stakeholder requests Storyboard Use case model
Supplementary specifications Requirements attributes
|Define the system
||Develop vision, capture a common vocabulary, identify end users and manage dependencies.
||Glossary Use case model Supplementary specifications Requirements attributes
|Manage the scope
|| Develop vision, manage dependencies and prioritize user goals.
||Vision Software architecture document Requirements attributes
|Refine the system definition
||Detail user goals and detail software requirements.
||Supplementary specifications Use case Software requirements specification
|Manage changing requirements
||Review requirements, manage dependencies and structure user goal modeling.
||Review record Use case model Requirements attributes
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 Change request
||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