Introducing Requirements Management

Tonight I'm thinking about 'requirements management' for work. I have to introduce a requirements management discipline to an existing project. I get the impression that requirements management is being seen a primarily about change control; or rather reducing scope creep. But I know that requirements management is so much more than that.

Requirements management is about coordinating the transition of high-level requirements into detailed requirements. It's about managing the inherent uncertainty of requirements specification and coordinating the transition from uncertainty to specifications (or in low risk or repeatable cases - directly to code).Â

I'm trying to working out the main theme I need to introduce the discipline into the organization.

What has requirements?

• A stakeholder (need)

• The project (scope)

• A component of the solution (detailed requirements)

• A physical application (such as a package; requires platforms and infrastructure)

• A platform (such as .NET; requires infrastructure)

You see, it's not just the project which has requirements. End-to-end (and layer-through-layer) requirements management includes the allocation of specific requirements to specific components of the solution architecture. This hooks the requirements management process into the project's design management, specification management (including modeling), and architecture management processes.

What types of requirements are there?

• Detailed requirements

• High-level requirements

• Unmanaged requirements

• Managed requirements

• In scope requirements

• Out of scope requirements

• Positive requirements

• Negative requirements

• etc

Some requirements management tenets (these do or should always remain true)

• All requirements generated outside the project are 'unmanaged' until they are assessed

• Without requirements management no separate assessment and requirements analysis can occur

• Requirements cannot be assess without a requirements management process; in such cases all requirements must be simply assessed

• Detailed requirements are the result of requirement analysis and must be managed

• Detailed requirements must apply to a specific architecture component (see MWT Book on 'Detail without Context')

• Specifications are not requirements

• Specifications are output from design processes not requirements analysis processes (if the design process was unmanaged then the specification is of poor quality)

Specification of the external behaviour of the system (such as 'functional specifications') is not requirements management. These specifications tend to be an incomplete record of an unmanaged design process.

What does it mean for something to be managed?

• You need to know how far through it you are

• You know to know where you have made compromises

• You need to know what you don't know (map uncertainty)

• You need to be able to quickly size changes in inputs