The Detailed Specifications are the final output of the
requirements decomposition. These are the requirements that will be used to
build out the infrastructure, populate the configurations, and drive the
development of software where necessary.
Based on our previous example from our last
discussion, one of our High Level Requirements was “The system shall send text
messages to Agents”. This single high level requirement should be further
decomposed into the elements which will be designed/created to fulfill the
requirement:
|
FR
|
1.2
|
The system shall send text messages to Agents
|
|
FR
|
1.2.1
|
Text messages shall not exceed 140
characters
|
|
FR
|
1.2.2
|
Text messages shall be stored 120
days
|
|
FR
|
1.2.2.1
|
Text messages older than 120 days
shall be archived
|
|
FR
|
1.2.2.1.1
|
Archived messages shall be
retrievable
|
|
FR
|
1.2.2.1.2
|
Archived messages shall be retrieved
within 15 minutes
|
|
FR
|
1.2.2.1.3
|
Archived messages shall be stored on
Linear Tape File System
(LTFS)
|
And so on until the system has been sufficiently
described to know how it will be built. There is a whole science behind how the
requirements nesting is done, which I don’t fully understand but the
requirements management tools mentioned last week help to facilitate this very
well. The proper nesting will prevent missed specifications and duplicate
specifications as well as providing guidance for testing.
Even a simple system can generate hundreds of
specifications. I have worked with several teams in the past where we spent
multiple weeks churning these out in order to define the systems that we were
going to build. It can be a painstaking process but when done properly the
resulting build/test/deploy cycle can be completed with confidence that the
system will meet the business need.
As shown in the previous step, the Detailed
Specifications can have many nested layers, each of which is traceable to the
layer preceding it.
The Detailed Specifications are the requirements which
are used for testing to ensure that the system does what it was designed to do.
Once the Detailed Specifications are complete the engineer participation in the
process drops off significantly.
There are artifacts that can be useful for describing the
system separate from the requirements. However, these should all be based on the
requirements. Examples of these are:
-
Logical
Component Diagrams
-
Physical
Component Diagrams
-
Process
Flow/Swim Lane Diagrams
-
Rack
Elevation Diagrams
-
Network
cable/port Diagrams
-
Value
Stream Maps
-
Performance
Metrics
-
Bill of
Materials
-
TCO/ROI
Analysis
-
Interface
Control Document
-
Database
Design Document
-
Systems
Design Document
-
Systems
Test Plan
-
Systems
Test Cases
-
Implementation Plan
Most of these have some representation already in the PQR
process which we get into when we start to discuss the Engineering Artifacts.
The Resource
Feasibility
principle should be a huge consideration during this step and the build step. It
may become obvious earlier that there won’t be enough time, money, personnel, or
other resource factor to complete the design but this time period is where that
determination becomes critical.