ArgonDigital recently received an email from one of our clients seeking advice on levels of abstraction when stating requirements.  The email read as follows:

“What are your thoughts on the use of “shall prevent” in a requirement. I believe it’s not specific enough and should state what is actually required.  For example:

“The System shall prevent a user from transmitting on a radio that is not allocated to them.”    

When considering verification, a range of “mitigations” come up:

1. When a user attempts to transmit on a radio allocated to another user, they receive feedback that alerts that the attempt has failed. Or
2. When a user attempts to transmit on a radio allocated to another user, their transmission function is disabled.

Each of these options requires different system behavior and in my view, the requirement should specify either 1 or 2 above where it is clear how “prevention” is verified.  

I have the same issues with the use of “shall allow”. 

It would be great to know what your thoughts are.”

Abstraction deals with stating a general concept and then decomposing that concept into more specific details.  The question is really about the level of abstraction as it applies to requirements.  It is important that the wording of requirements (both noun and verb) is appropriate to the level at which the requirement is being written.  A higher-level concept expressed at the system level could be considered imprecise and is thus ambiguous and not verifiable.

When writing requirements, we go through the process of defining stakeholder needs and expectations, then do analysis to determine what the system needs to do such that the stakeholder needs and expectations are met.  From this analysis, we then write the system level requirements.

These requirements are then allocated to the parts of the architecture at the next level, and children requirements are developed though either derivation or decomposition.  The resulting requirements need to be necessary and sufficient to address the intent of the allocated parent requirement.  As viewed by the parent, these children look like “how”.

From the perspective of abstraction, there are two main perspectives that can be taken:

One approach is to state a higher-level functional requirement at the system level and write children requirements to meet the intent of the parent via decomposition/derivation at either the same or next level of requirements.   Taking this approach, a general system level requirement expressing a requirement “to prevent” or “to allow” may be acceptable as long as it is decomposed to the next level of abstraction.   The resulting children requirements then define the parent and as long as everyone (including the customer/user) agree the children are necessary and sufficient to meet the intent of the parent requirement, all ambiguity is removed.

For the example: “The System shall prevent an unauthorized user from using a radio not allocated to them.” Or “The system shall allow authorized users to use a radio allocated to them.” Either may be acceptable as long as “prevent” or “allow” is decomposed to the next level of abstraction.

At the next level of abstraction, there are several issues that would need to be addressed via requirements:

1. How does a user become “authorized” for use of a particular radio?
2. Once a user is authorized, what actions do they need to identify themselves or the system to recognize them as being authorized (or not)?
3. Does the system notify the user whether or not they are authorized to use the radio?
4. “How” will the system prevent an unauthorized user from using the radio?

These are engineering implementation decisions that result in “how” the parent requirement “prevent” or “allow” is to be implemented.  As long as the resulting requirements are verifiable and it is agreed that if these children requirements are met, the intent of the parent requirement will have been met. Verification of the parent is dependent on verification of the children first.  This works because the right side of the SE Vee is a bottoms-up integration/verification/validation process.

Another approach would be to do the decomposition/derivation earlier in the development process during the scope definition phase when we are eliciting and documenting stakeholder needs and expectations.  During scope definition we develop system concepts, user stories, use cases, operational scenarios, etc. to elicit and document stakeholder needs and expectations.   During this process, we identify ambiguities in the stakeholder information and query them as to what their real intent is.  In this case, before writing the requirement, we would ask the stakeholder what they meant by “prevent” or “allow”.   Once we understand their intent, writing the proper requirements that reflect this intent is much easier.  That is part of the transformation process between stakeholder needs and expectations and writing the requirements.

Using this approach, the system level requirements may be the result of our decomposition/derivation of stakeholder needs and expectations.  Requirements dealing with the areas of concern stated above, would then be stated at the system level and trace back to the stakeholder needs and expectations documented as part of the scope definition process.

Parting Thoughts

When writing requirements, ask yourself if the verb of a requirement is at proper level of abstraction, or would the requirement be better expressed at a lower or higher level of abstraction or decomposed and broken up into the specific functions that result in the intent of the stated function as stated by the customer/user during scope definition.

Using either approach, it is important to 1) trace the resulting requirements to their source or parent and 2) document rationale for each requirement.

To make sure the customer/user’s intent is represented by the decomposed/derived requirements make sure the customer/user are included in the baseline activities for the set of requirements.  The baselined set of requirements represent a contract between the developers and the stakeholders.  Both have to agree on the set of requirements.  The requirement reviews will aid in making sure both groups are happy with the requirements.

As with all our blog posts, your comments on this topic are welcome.

I you have any other questions, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.