Note: This is part 2 on our discussion concerning going from system concepts to requirements.  Going from system concepts to requirements Part 1 addresses the basic concepts.  Part 2 goes more into the “How” to go from the Column A stakeholder perspective to the Column B system perspective.

There are several challenges you need to consider when going from Column A statements to Column B statements:

1. One challenge is that often the statements in Column A will include ambiguous terms and phrases like: user friendly, robust, easy to use, works fast, safe, pleasant, easy to test, etc.  When you see these kinds of statements, you will need to work with the various stakeholders to understand what they mean by these words and then put in Column B unambiguous statements that when implemented by the system result in the stakeholder expectation being met.  Ask the stakeholder, what are the characteristics they want to see in the system that will result in it being easy to use, user friendly, easy to test, etc.?
2. Another challenge is writing your system requirements to state “what” and not “how”.  When developing the concept statements in Column A and the derived system statements in column B, you need to focus on the “what” not “how”.  The “how’ is what we call implementation.  Remember, the purpose of requirements is to communicate to the developers the stakeholder (actor) expectations that were included in Column A.  It is the job of the developers to figure out all the how”. Including implementation (how) in your requirements (what) is probably the major reason for requirement bloat – hundreds of requirements for even a small application.  So when deriving the statements in Column B, focus on the “what”.  The developers will worry about the “how”.
3. When dealing with stakeholders, including users and customers, there will be both explicit AND implicit requirements.  Explicit requirements are those that are communicated and written down.  Implicit requirements are those that the customer implies or expects you to address.  In other words, the stakeholder assumes the developer will automatically design functionality because while it is not explicitly stated it is implicitly needed.  Some “implicit requirements” seem so obvious that the stakeholder may not realize they are implicit requirements.  Example: a major European country spent almost a billion dollars designing and building four submarines that in the end, could not float…they just sank to the bottom – they were too heavy.  There probably was an implicit requirement that the submarines would float, but was not explicitly stated.  Who would ever build a submarine that could not float?!?!   The moral of the story is that requirement writers need to listen between the lines as well as take from their life experiences to uncover implicit requirements and then document them to make them explicit.  Failing to do so can result in a system that meets the requirements but fails to meet stakeholder expectations.
4. Stories, scenarios, use cases, system concepts, ops concepts, concepts of operation, etc. often focus on functionality and performance, but are often incomplete, not addressing other requirements that need to be included in the technical requirements that are provided to the design team.  These include the operational requirements, quality requirements or “–ilities”, design and construction requirements, and physical characteristic requirements.  To make sure you have a complete set of requirements you need to address all the different categories of requirements.  For more information on the different categories of requirements that may need to be included (even if not explicitly stated by the customer) see our blog Requirements Categories – Part 1: General Discussion and Functional and Performance Requirements.

There are many questions you need to address when going from Column A to Column B and from Column B to the system technical requirements.  Addressing these questions are necessary to make sure you completely understand the stakeholder expectations and don’t end up with an incomplete set of requirements.  Some of the questions you need to address include:

1. Do the statements in Column A address all key stakeholder viewpoints?  If you have left out a key stakeholder, you could end up with missing requirements.
2. Do the statements in Column A address all lifecycle stages of the system lifecycles?  Again, if not you could end up with missing requirements
3. Do the statements in Column A address off-nominal situations?  If not, your system could fail to allow the users from getting the job done in manageable off-nominal situations.  “If only we would have addressed that in our concepts….”
4. Have all conflicting viewpoints been resolved?  Are all stakeholders aligned to a common vision as to what the system is to do and how well?  If not, column B statements and resulting requirements could be in conflict with one another.
5. Have the statements in Column A been prioritized?  It is important to understand the must haves vs the nice to haves or wants.  What are the key performance expectations?  How will the effectiveness of the system be measured?  How will performance expectations be measured?  In what terms?  The priorities in Column A will be carried though to column B and to the actual system requirements.
6. For each of the statements in Column A, has the expectation been decomposed and expressed clearly in unambiguous statements in Column B so that when implemented by the system, will result in the expectation communicated in Column A to be met?
7. For each function and sub-function statement in Column B, has an acceptable performance standard been defined (how many, how fast, how well, how much, etc.)?  These statements need to be measurable; if not they are ambiguous and not verifiable.
8. Are any of the measures of performance related?  Is the relationship positive or negative?  If I increase measure A, will that help or hinder measure B in achieving its desired value?  Positive relationships are when two measures help each other.  A negative relationship exists when one takes away from another.  In these cases there is a conflict.  To meet one means you cannot meet the other.  In these cases what has priority?  Is there a compromise “sweet spot” where you can partially meet each and still be successful?  These conflicts need to be addressed before writing your requirements.  Understanding the relationships will help you make trade-off decisions and identify areas where further research or trades are needed.
9. Is the implementation of each statement in column B attainable in terms of cost, schedule, and technology?  If not attainable, why make the statement?  If stakeholder expectations may not be met because they are not attainable, then that expectation needs to be reset or the entire project rethought.  If not attainable, you are not ready to write requirements.  This may not be a black and white determination.  Frequently there are degrees which can be expressed in terms of risk.  Things that you have not done before, are unique, and/or really hard to do add risk.  For each item in Column B, you need to document any issues and the associated risk.
10. If developing a commercial product, how do the defined measures relate to the competition?  This means you will have to do a competitive analysis between your measures of performance and your competitors.  Part of this assessment needs to address the relative importance of each measure from a competitive perspective.  This will help you establish priorities. (see item 5 above.]
11. Do you understand the interactions (interfaces) between your system and other systems in meeting the expectations communicated in Column A?  As you are filling in both Column A and Column B, make sure you identify all interfaces.  For each interface, you will need to make sure (1) the interaction is defined and agreed to between your system and the other systems and  (2) the necessary interface requirements are included in your requirement set.
12. Do you understand the assumptions being made by the stakeholders when they communicated their column A expectations?  If the assumption is false, their expectation may not be valid.  The worse assumption is that they assume you know what they are assuming.
13. Are you and the stakeholders speaking the same language?  By this I mean are the terms you are using understood with the same meaning and intent by all?  To make sure this happens, for key terminology, make sure you develop a glossary for your project.

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.