On our Ask the Experts page, the following question was asked: “One subject that has been on the back of my mind is to find out how to provide a key metric to management about the stability of requirements. By this I mean like a risk factor (or something similar) that will help the program management forecasting/planning efforts.  Given a requirements hierarchy, do you think we can derive some sort of a risk factor?”

Risk is a key consideration in requirements.  For my paper “Risk and Requirements” that I wrote addressing this very topic and the accompanying checklist we developed, please email me at info@argondigital.com and I will send you a copy of each.

Two key attributes we recommend you include in your requirements management tool (RMT) and populate for each requirement is risk and priority. Priority is discussed in detail in our blogs entitled:  Why You Should Prioritize Requirements and How to Prioritize Requirements.  Risk and how to combine risk and priority is discussed below.  For a more complete discussion concerning requirement attributes you can read my three part blog on attributes.  You can also read my blog concerning features a systems engineering tool should have.

Risk Factors

From a risk standpoint, you need to consider requirement risk factors.  Assessing the risk factors will enable you to assign a risk value to each requirement.  Requirements that are at risk include requirements that:

1. Can be read more than one way.  This includes requirements that are ambiguous, unverifiable, poor grammar, wrong format, inaccurate, or are missing rationale.
2. Are incomplete.  This includes requirements that have TBD, TBRs, missing other related requirements, missing attributes. For more detail on determining the completeness of your requirements, refer to our blog entitled: How do you know your requirements are complete?
3. Are subject to change because stakeholders not in agreement, all stakeholders have not reviewed the requirements, depends on answers not yet available, depends on regulations/standards being revised, or depends on interfaces not yet identified and defined or possible changes to external interfaces.  For more detail on why requirements change and controlling and managing change, refer to our blogs entitled: Why Do My Requirements Keep Changing?  Controlling and Managing Change.  Remember – understanding and managing change is a key concept in developing a stable set of requirements.
4. Are not verifiable.  Is the requirement written such that it can be verified? If not verifiable there is a risk the stakeholders expectations will not be met.  For more detail on determining whether or not your requirements are verifiable, refer to our blog entitled: Is the Requirement Verifiable?
5. Are not attainable.  If it is not attainable, do you really need it?  For more detail on determining whether or not your requirements are attainable, refer to our blog entitled: Are the Requirements Attainable?
6. Do not have the requirement hierarchy documented.  Requirements are developed top-down: system to subsystem to assembly to components to parts.  This hierarchy needs to be documented via the concepts of allocation and traceability.  If not, there are many risks to your project including requirements not being implemented, gold plating, inadequate change impact assessment, and interfaces not identified.   For more detail on determining whether or not your requirement hierarchy is well documented, refer to our blog entitled: “How well are requirements connected?”
7. Performance depends on an immature technology.  In order to meet the expected performance documented in the requirement, a new technology may be needed.  This adds risk to your project.  Risk is directly related to the maturity of the technology.  Maturity of a technology is measured in terms of Technology Readiness Levels (TRLs).  The lower the TRL the higher the risk to your project. You can read my blog on TRLs as well as read my paper  “Developing Requirements for Technology Driven Products” which addresses this topic in more detail.

Risk as an Attribute

As an attribute, like priority, you can assign a risk value to each requirement based on the above risk factors.  We recommend you keep the risk value assignment simple; for example like high, medium, low or 1, 2, 3 with 1 highest risk.   Risk is determined by considering BOTH likelihood and impact.   The highest risk is one that is most likely to occur and has the most impact.  We recommend that you develop a 3×3 matrix with likelihood on one axis and impact the other axis.  I have also seen the scale of 1-5 used and a 5×5 matrix.  NASA uses the 1-5 scale/matrix.

Combining risk and Priority

Combining risk and priority can provide management with valuable information they can used to manage your project’s requirements and associated risks.  Knowing requirements are both high priority and high risk allows management to focus on the most important issues.  Again, you can create a 3×3 matrix but this time one axis is risk and the other priority.  If these attributes are not documented for each requirement, how will management know which ones are high priority AND high risk?

Key Driving Requirements

Another concept deals with Key Driving Requirements (KDR).  These are requirements that have a significant impact on cost and schedule.  Knowing which requirements are KDRs along with knowing the risk factor and priority gives management another piece of knowledge that helps them better manage their project.  If your project gets in trouble, how would you treat a requirement that is a KDR, high risk, but is low priority?

Leading Indicators

Another concept is Leading Indicators (LIs).  Leading indicators are measures  and metrics that provide information for evaluating effectiveness of how a specific activity is applied on a project.  LIs provide information about impacts likely to affect the system performance objectives.  LIs may be an individual measure, or collection of measures (metrics), which can be used to plot (predict future state) before the actual performance is realized.  The goal is to provide insight into potential future states to allow management to take action before problems are realized.  Examples of requirement development and management LIs include:

• Requirement Trends: percent growth, To be Determined/To Be Resolved (TBD/TBR) closures, number of requirement changes, etc.
• Interface Trends: percent interface definition documentation approved, TBD/TBR burn down (resolution/closure), number of interface requirements, number of interface requirement changes, etc.
• Verification Trends: number of requirements the system has been verified to have meet , number of deviations/waivers, etc.
• Review Trends: Review Item Descriptions (RIDs), Requests for Action (RFA), Action Items per review and burn down (closure), etc.
• Software Unique Trends: number of requirements per build/release versus what was planned.
• Problem Report/Discrepancy Report Trends:  number open/closed

All of these concepts can be used to help with project management and requirement development and management forecasting/planning efforts with regard to stability and risk.  The important thing is that management understands the need to identify and track risks due to requirements.  A high level of risk correlates directly to an unstable set of requirements.  If you don’t manage risk, risk will take over your project — dooming your project to almost certain failure.

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.