I recently saw the following question posed in a discussion group: “When should the formal management of requirements begin?”
My take is this – I look at Requirements Management (RM) as having three main functions:
1) Requirement elicitation and development;
2) Managing the flow down (allocation) and traceability of requirements between levels;
3) Change management.
Your RM process must be documented, made available for all to use, and compliance enforced by management.
Requirement elicitation and development
As a process, RM begins at the beginning of the project – first you develop and then baseline your product scope, then you develop and baseline your requirements. Requirements elicitation occurs as part of these activities.
As part of the RM process, requirements are normally put under configuration control after the requirements have been validated and baselined via a Systems Requirements Review (SRR). Note there are dangers baselining a requirement document before the requirement set is mature and has been fully validated. By validated, I mean that the requirements, both individually and as a set, are correct, clear, consistent, and complete. Note: you want the requirements to be somewhat stable before you put them under configuration control because of the added time and effort involved in making changes once the requirements are baselined.
As far as controlling the quality of the requirements, I believe a good RM process includes both continuous requirement validation activities as well as a formal discrete requirement validation activity (i.e., the conduct of a formal SRR). By continuously validating your requirements as they are being written, you avoid poorly written requirements from being included in the final set for review. Follow a checklist or standard as the requirements are being written and review your requirements to ensure compliance with the checklist/standard. If you do this, when you get to an SRR, you will have a much better set of requirements to baseline and put under configuration control. After baseline, requirement changes should not be due to the fact the requirements were bad to start with.
Once you have a baselined set of requirements at one level then you need to manage the flow down of the requirements as well as manage change to the baselined set of requirements.
Send me an email direct at info@argondigital.com and I will send you a copy of our “Checklist for Writing Good Requirements”.
Manage Allocation and Traceability
At the beginning of a project you are either tasked to define the problem and define your own set of requirements or you may be given an initial set of requirements from your customer as part of a contract. In the latter case, the customer requirements should have already been baselined and under configuration control prior to the contract being released.
In either case, it is then your job to implement these requirements at lower levels of the architecture. Thus, you will be defining an architecture, allocating the baselined requirements to parts of that architecture and then deriving a set of requirements at the next level that meet the allocated requirements from the previous level. These derived requirements will all be traced back to the previous level’s set of requirements.
From a RM standpoint, I find that many organizations don’t do the “manage allocation and traceability” well. In fact, many organizations do not even understand what allocation really is let alone document allocation and traceability within a Requirement Management Tool (RMT).
A disciplined allocation process is one that is done correctly and in a timely manner, and is used to analyze the requirements. In addition to ensuring that all requirements are flowed down properly, a disciplined allocation process can provide a number of other benefits to a program or project, including:
– Ensure all system level or customer requirements are allocated
– Identify possible internal interfaces
– Improve traceability analysis
– Aid in finding redundant requirements
– Aid in ensuring completeness of requirements
– Aid in accessing impacts due to changes
Allocation combined with traceability can be used to identify and correct common level problems. These types of problems can add significantly to your product’s development time and cost.
– Requirements at the wrong level
– Higher-level requirements not implemented at lower levels (missing requirements)
– Lower-level requirements that cannot be justified by higher-level requirements (gold plating)
Managing Change
From a change management standpoint, even with good requirements, change is going to happen. I address why requirements change in my blog:”Why do my requirements keep changing?” and how to control change in my blog: “Controlling and Managing Change”
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
