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

What's important... to you?

Bill Jensen forwarded me some extracts from his new book 'What is your life's work?'. You can read them too - they are available here.

The book contains many letters Bill has gathered over the years. The letters are the output of a meme where you write a letter to your loved ones which expresses with 'absolute conviction and clarity' what is important to you - 'your life's work'. But these aren't just letters about finding some ideal job or having a positive attitude at work. It's possible to fake the trappings of the dedicated employee. These letters aren't about being successful at work. These letters are about finding out what is important to you and doing that.

Another important theme that comes up in the extracts is the importance of doing less at work. The obligation to do less at work, in fact. There are two sides to this obligation which are really the same thing. Bill generally appears to come from the position that you should be doing less of what doesn't matter. He also touches on the position which I read into Slacker Manager's philosophy which is that you should be doing less as a mechanism for improving your productivity. This is the position which I tend to take.

Reducing the amount of effort it takes to achieve the same result is the very definition of productivity. Bill appears to have always been an advocate of this type of philosophy and gives compelling advice on how to it create slack (in the sense of free time) in your work day through improved simplicity. In that space between your increased personal responsibility and when take on additional responsibilities what exactly should you be doing? With his new book Bill provides some interesting answers to that question.

How things can be related

Erik Benson has created a list of how things can be related. This must already exist somewhere but it's still worth thinking about. To his list I would also add 'contains' (I would also rename some of his items). These are exactly the types of sterotypes which would be included in the visualisation tool pleaded for here.