I was asked the following question from a friend of mine:

“I see a propensity to copy requirements from the Customer Specification to various levels of the requirement hierarchy in order to link between a Customer requirement written as implementation in their specification to where it is allocated to in HW/SW.  Is there any guidance documentation (best practices) for addressing ways around copying requirements?  Negotiating with the Customer is NOT an option.”  

This is a very common problem.

Short answer?  In general I do not like copying and pasting requirements stated at one level into a set of requirements at a lower level as a way to do allocation.  What needs to be done is for requirements to be allocated to the next level, and then via decomposition and derivation, develop child requirements that form a necessary and sufficient set that will meet the intent of the parent.  The children requirements will then link (trace) back to the allocated parent.  However, when a low level requirement is stated at a level higher than it will be implemented at (in the customer specification in this case) allocation, decomposition, and derivation may not be possible.  In this case, copying the requirement (assuming it is well-written) and pasting it in the set of requirements at the proper level may be the best approach. As in the previous case, the copied requirement will be linked (traced) to the requirement in the Customer Specification.

However, the issue is more complicated.

Long answer?  At INCOSE IW 2014, the Requirement Working Group  discussed the subject of where requirements come from and came up with the following definitions.  These definitions were finalized and included in the update Guide to Writing Requirements at INCOSE IW 2015.

A need is the result of a formal transformation of one or more concepts for an entity into an agreed-to expectation for that entity to perform some function or possess some quality (within specified constraints).

A requirement statement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints).

Each valid requirement statement has a set of characteristics: necessary, singular, conforming, appropriate to level, correct, unambiguous, complete, feasible, and verifiable.

I have found that in many cases the customer provided requirements do not have these characteristics.  In the above case the “appropriate to level” seems to be the issue.

What I would recommend is to treat the customer spec as “needs”, as defined above, that your organization has agreed-to meet.   Then your job is to transform these “needs” in to a set of well-formed requirements having the stated characteristics.

A requirement set is defined as: “… a structured set of agreed-to requirement expressions for the entity and its external interfaces documented in an Entity (Enterprise/Business Unit/System/System Element/Process) Requirements Specification (Document).”  In this case the “Entity” is the System the implementing organization is responsible to define, design, built, verify, validation, and deliver to the Customer.

The Customer will want proof that all of their requirements have been met (verification).

The implementing organization will create requirements for each level of the system hierarchy.  System level requirements will flow down (be allocated) to the subsystem set of requirements by either decomposition or derivation.  This level of requirements will, in turn, flow down to the next level, until you reach the point you can make a buy, build, code, or reuse decision.  The children requirements will link (trace) back to the allocated parent.

Within this context, I can now address the issue.  It is common for customers to define their needs in terms of shall statements. To them these are the requirements the system being developed must meet.  When the customer shall statements are “implementation”- how vs what, then you will need to determine which level of the architectural hierarchy they apply.

If they are well written they can be copied and pasted as is and trace back to the customer spec.  However, they will need to have a parent in the previous level of your requirement hierarchy to trace to as well.  If there isn’t one, you will have to derive one.  This requirement will also have to be traced to a parent at the previous level, and so on until you are back at your system level requirements in which case you will be tracing to the original requirement in the Customer Specification.

If the customer implementation requirement is poorly written, rather than copying the requirement, you will have to derive one or more well-written requirements that meet its intent and put them in the set of requirements appropriate to the level you are writing the requirements for.  Again, these requirements will trace to the shall statement in the Customer Specification as well as trace to a parent in the previous level of your set of requirements.  Again you may have to derive the parent if one doesn’t exist at the previous level.

In either case, the derived parents represent the “what” that the child implementation “how” requirement(s) is implementing.  One important consideration is that when you derive the parent, you need to do an analysis to determine if, to meet the parent, other architectural subsystems or components are involved.  If the answer is yes, you will have to define children requirements (via decomposition or derivation) for the other architectural subsystems or components that will need to be implemented to meet the intent of the parent.  In doing this you will be uncovering missing requirements that resulted from the customer stating implementation vs why that implementation was needed.

This is one of the reasons why stating low-level architectural requirements at too high a level is bad.  Doing so means the reason for the requirement is not stated.  You can read more about the other issues involved in stating implementation in my blogs: Avoiding Implementation and Implementation in Requirements – Internal Directive (i.e., Constraint) to use a Legacy Component.

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.