A common issue that frequently comes up is the use of “The system shall be capable of…..” or “The system shall be able to….” vs. “The system shall …..” People often ask: Is there a distinction? What is wrong with saying “The system shall be able to operate using 28 VDC” vs. “The system shall operate using 28 VDC.” From a requirements perspective, do you deliberately use one or the other? In which circumstance? Why are both forms not acceptable?
Other extreme variations on this are “The system shall have [or provide] the capability to allow the operator to be able to do X” or “The Operator shall have the capability to be able to do X.”
From our perspective, “be able to” and “be capable of” phrasing results in unnecessary diluting of the requirement thereby making it ambiguous. These phrases should never be used in a requirement; they are extra words that just add confusion – Able to when? Remember, requirements should be simple…less is more! Say what you want the system to do in simple, unambiguous, verifiable terms rather what the system should be able to or be capable of.
So…when you find yourself toying with the phrase “be able to” or “be capable of” STOP and ask yourself… “what do I want to verify?” Do I want to verify the system does something or do I want to verify the system is “able to” do something? If you run 100 verification tests and the system fails 99 times but passes once, it was “able to”, right? However, that is probably not your intent. I don’t want it to do what I want “sometimes”. I want to verify it does what I want, when I want. This may be all the time, or when commanded to, or under the right conditions to do so. “Be able to” and “be capable of” are not good enough – they are very weak statements.
We often see advertising statements that claim “a system is capable of doing XYZ”. Often, what is meant by “capable of” is that the system was designed to do XYZ — that is if the right interface is installed or an additional module is purchased. For example: you want a laptop to do graphic design, so you state “The laptop shall be capable of graphic design. The laptop arrives and you discover that it cannot do graphic design! After some investigation, you discover that the computer IS “capable of doing graphic design”…that is, IF a graphic design software package was purchased and installed. So remember…you don’t want a system or product to “be able to” or “be capable of”…you want it to DO IT!
I have heard many arguments floated to justify the use of “be able to” and “be capable of”:
- I have to turn a stakeholder expectation into a requirement. A stakeholder may say: “I want to be able to do something.” or “I want the system to provide me with the capability to do something.” Then someone turns this into a requirement by just adding a “shall” to the stakeholder expectation statement: “The stakeholder shall be able to do something” or “The system shall provide the stakeholder with the capability to do something.” This is a very bad practice. What the requirement writers need to do is ask themselves “What does the system have to do so the stakeholder can do something?” They then derive system requirements that result in the stakeholder having that capability. The stakeholder expectation is turned into several “system shall …” requirements that, when implemented, allow the stakeholder to be able to do what they want or provide them with the capability they expect.
- The system doesn’t have to do something all the time. For some, “the system shall….” refers to a full-time function that the system always does, while “the system shall be able to…..” is something the system does if specifically commanded to so by an operator or only when a specific condition exists. There is nothing that “The system shall be able to X when Y” says, that “The system shall do X when Y” does not. The system shall “be able to/capable of ” is often incomplete. The missing part of such a requirement is the “when”; under what condition must it do X, what is the trigger for doing X, and if it always does X, continuously, “able to” just muddies the water. Again, the requirement writer needs to derive the proper set of requirements. Instead of saying “The system shall be capable of remote power down.” You could have a requirement: “The system shall power down within 500 ms upon receipt of an operator power down command defined in ICD xxxxxx.”
A closely related argument that argues against using “be able to” or “be capable of” is that a requirement statement that says a system has to do something doesn’t necessarily imply that it has to do the thing all the time. For example: you want to buy a home office printer that can print on both sides of the paper (w/o manual intervention). In this case, you don’t need a requirement that says: “The printer shall be capable of printing double-sided.” Rather your requirements on the printer are: “The printer shall print double-sided” along with “The printer shall print single-sided.” Each requirement is verifiable, communicating a feature of the printer. There is no implication that the printer always prints double sided or single sided. It does whichever you ask it to do. You, the user, want the capability to print double-sided, when needed, and single sided at other times. Having the two printer requirements above provides you with that capability. I can use “shall” without having it mean “shall at all times”. “The printer shall print double-sided” doesn’t have to mean it will always print double-sided.
The issue is really how best to communicate what the system has to do in order to provide the users the ability or capability they need and expect. The challenge for the Systems Engineer is to properly communicate these expectations into well written, unambiguous, verifiable requirements.
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.
