This is part 5 of the blog series “Communicating Requirements – Effectively”.
In part 4, I discussed the advantages of text-based requirements vs alternate forms of communicating requirements.
In part 5 of this blog series, I conclude the series with a discussion on the characteristics of well-formed requirement statements, sets of requirements, and attributes.
———————
Characteristics of Well-Formed Requirements
All the various filters involved in effectively communicating requirements present a significant challenge to ensure that the sender’s intent of the requirement will be what is received, interpreted, and understood by the various stakeholders. A key consideration concerning requirements, no matter the means of communication, is that requirements are really about clear and effective communications. Requirements are the language we use to communicate stakeholder expectations and needs to the design, build, and code team as well as the entire range of recipients shown on the right side of Figure 1 included in part 3 of this blog series. It is important to understand when more formal communication of requirements is needed and when informal, yet effective, communication of requirements is sufficient. When it comes to a formal, binding agreement with a customer where a contract exists and there is a need to accomplish system verification as defined for systems engineering methodologies, the text-based “shall” requirement statement approach is most appropriate.
Communications – no matter the form, is inherently ambiguous. Words often have different meanings based on assumptions, context, mind map, and filters of both the sender and receiver. Context, like filters, are used to encode, decode, interpret, and understand messages. For example, the word “check” has a multitude of meanings, all dependent on the context in which the word is used. Often the validity of a message depends on the assumptions (often not explicitly stated) made by both the sender and receiver(s).
It is the requirement writer’s job to follow best practices to reduce the ambiguity such that the requirement statements and sets of requirements have the characteristics of well-formed requirements defined in “An Improved Taxonomy for Definitions Associated with a Requirement Expression” (Ryan, Wheatcraft, Dick, Zinni 2014), the INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-01, 2017) and the BABOK (IIBA, 2015). To help facilitate effective communications of requirements, these characteristics have been defined, such that if the requirements, no matter the form, have these characteristics, effective communication of the requirements are more likely to occur. The INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-01, 2017) also includes a set of rules, that if followed, will result in requirements and sets of requirements having these characteristics. Requirement writers need to be trained in the use of these rules to write well-formed requirements and sets of requirements that have the characteristics of well-formed requirement statements.
Characteristics of Well-formed Requirement Statements
The key elements of the both “An Improved Taxonomy for Definitions Associated with a Requirement Expression” (Ryan, Wheatcraft, Dick, Zinni 2014) and the INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-01, 2017) definition of a requirement statement include: formal transformation and agreed-to obligation. Each of these two elements can be elaborated further by stating specific characteristics of a well-formed requirement that will help to ensure that element of the definition is true.
Formal Transformation. Including this element in the definition makes it clear that a requirement is the result of engineering analysis of the stakeholder needs. For each “need” the Requirements Engineer or Business Analyst asks: what does the entity have to do or what characteristic must it possess in order for the need to be realized? This engineering analysis results in one or more requirements. Given the requirement is a result of a formal transformation, the following characteristics of a well-formed requirement expression include:
Necessary: The requirement defines an essential capability, characteristic, constraint, or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements.
Singular: The requirement should state a single capability, characteristic, constraint, or quality factor.
Conforming: The individual requirement should conform to an approved standard pattern and style for communicating requirements.
Appropriate: The specific intent and amount of detail of the requirement is appropriate to the level (of abstraction) of the entity to which it refers.
Correct: The requirement must be an accurate representation of the entity need from which it was transformed.
Agreed-to Obligation. Including this element in the definition makes it clear that, before a requirement is valid, both the customer and provider must agree with the requirement statement. Note: we are using the term “customer” to refer to the entity requesting a work product. The customer may be internal or external to the enterprise. Many people may want to levy requirements on a system, but until that requirement is formally agreed-to and is part of a contract (“contract” refers to the acquirer-supplier relationship), it is not a valid system requirement. Why would a rational developer agree to a requirement that does not have these characteristics? Since the requirement is to be a part of a fair agreement to meet an obligation, the following characteristics of a requirement have been derived.
Unambiguous: The requirement is stated in such a way that it can be interpreted in only one way.
Complete: The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement.
Feasible: The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk.
Verifiable: The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirement exists.
Characteristics of Well-formed Sets of Requirements
Given a requirement statement results from a formal transformation of one or more needs into an agreed-to obligation for an entity, a set of requirements results from the formal transformation of the set of needs that represents an agreed-to obligation for the entity. Again, the key elements of that definition are a formal transformation and an agreed-to obligation. Each of these two elements can therefore be elaborated further by stating specific characteristics of a well-written set of requirements.
Formal Transformation. As the set of requirements is the result of a formal transformation, the following characteristics of the requirement set have been derived:
Complete: The requirement set stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, interfaces, standards, regulations, and/or quality factors to meet the entity needs without needing other information.
Consistent: The set of requirements contains individual requirements that are unique, do not conflict with or overlap with other requirements in the set, and the units and measurement systems they use are homogeneous. The language used within the set of requirements is consistent (i.e., the same word is used throughout the set to mean the same thing).
Agreed-to Obligation. Since the set of requirements is to be a result of a fair agreement to meet an obligation, the following characteristics of the set have been derived:
Feasible: The requirement set can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk.
Comprehensible: The set of requirements must be written such that it is clear as to what is expected by the entity and its relation to the system of which it is a part.
Able to be validated: It must be able to be proven the requirement set will lead to the achievement of the entity needs within the constraints (such as cost, schedule, technical, legal and regulatory compliance).
Note that “feasible” is a characteristic of both the individual requirement statement and the set of requirements. While individual requirements may be feasible, the set of requirements may contain a quantity of requirements that is not feasible given the schedule and budget allocated to the development effort.
Also note that “complete” is a characteristic of both the individual requirement statement and the set of requirements. While complete as it applies to an individual requirement statement is fairly easy to understand, complete as a characteristic of a set of requirements is much more difficult to achieve. How do you know a set of requirements are complete? How do you know what is missing?
Another characteristic of sets of requirements is “consistency”. How do you know if your requirements are consistent, i.e., one requirement conflicts with another requirement? This can happen when a requirement has a dependency with another requirement. If one changes, then the other needs to change.
The answer to these questions is diagrams, models, and templates! If your requirement set is written as if you are writing a document, it is very difficult to determine if you missed something or if there are inconsistencies and conflicts. However, if you use diagrams, story boards, or a template as part of your requirement development process, it will be much easier to make sure you included everything that needs to be included and what is included is consistent with and does not conflict with another requirement(s).
Diagrams, whether standalone or visualizations of a model developed in a SE tool, are necessary when addressing correctness, completeness, and consistency, especially for complex systems. A functional flow diagram will result in listing all the required functions and their relationships, inputs, and outputs. An external interface diagram or context diagram with help to identify all interactions (interfaces) between your system of interest and other systems. The same is true for data flow diagrams, states and modes diagrams, swim-lane diagrams, etc. These diagrams also provide context from which the requirements are derived. A template for organizing your requirements tailored to your domain, will also help to include all the various types and categories of requirements in your requirement set. As stated previously, diagrams and models tend to focus on functional, performance and interface requirements. Using a template will address other non-functional requirements like quality (-ilities), standards, regulations, and physical characteristics.
Using an SE tool to address correctness, completeness, and consistency will result in a requirement set that comes from an underlying dataset that represents not just the requirements, but also the various diagrams and visualizations that make up an integrated data and information model of the system underdevelopment. Because all the various visualizations come from an integrated data and information model, changes in one place, will be reflected in all the other visualizations that change may affect, keeping what is being communicated by both the diagrams and requirements consistent.
Requirement Attributes
An attribute is additional information included with a requirement statement, in a requirement expression, to aid the management of that requirement. Attributes can be organized within four broad categories (Wheatcraft, Ryan, Dick 2016):
- Attributes to help define the requirement and its intent.
- Attributes associated with the entity of interest and system verification.
- Attributes to help maintain the requirement(s).
- Attributes to show applicability and allow reuse.
From a communications perspective, often there is more information that needs to be communicated, than is contained in the requirement statement, e.g., rationale, trace to parent, trace to source, criticality, priority, risk, implementation status, verification method, verification status, requirement owner, applicability, etc. Rationale is probably the most important attribute because it can include information to help ensure everyone (current and in the future) understands the reason for the requirement, its intent, the source of numbers, context, and assumptions the correctness of requirement may be based on. Requirement attributes not only aid in effective communications, they also aid in the management of not only the requirements, but the product development activities as well.
Both the INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-01, 2017) and the paper “On the Use of Attributes to Manage Requirements” (Ryan, Wheatcraft 2017) include a list of 44 attributes, along with a description of each and guidance on the use of attributes that can be used to better understand and manage your requirements. My blog series on attributes discusses each of these attributes as well.
Parting Thoughts
Requirements are the language used to communicate stakeholder needs for a system of interest to developers, designers, builders, coders, testers, and other stakeholders. Increasingly, the debate is about which means (form and media) of communications is best. The debate is usually between those that practice traditional SE, those that are adopting MBSE, and those that are following Agile principles. Depending on the specific thing being communicated, domain, culture, people, and processes within a specific enterprise, one means of communications is often advocated (with a lot of passion in many cases) over the others.
After discussing what is meant by the word “requirement”, I addressed the debate concerning the most effective means (form and media) of communications of requirements, returning to the basics of communication theory and showing that there is no single solution in all contexts such that . requirements cannot be communicated effectively using a single form or medium that is suited to all circumstances. To successfully deliver winning products, business analysts and systems engineers should use whichever form and medium is the most appropriate based on both what they are communicating and the audience to whom they are communicating.
In many contexts, text-based requirements do have many advantages over alternate forms of communicating requirements, providing that the requirement statements are unambiguous and conform to the characteristics of well-formed requirements. Several key factors need to be considered when communicating requirements, including: context, filters of the receivers, time, and formality.
In conclusion, each means of communication has value; however, no single means is sufficient to clearly, completely, and effectively communicate requirements. Each of the various means represent a visualization (graphic or text) of the system from a perspective based on the intent of the message being communicated. With this viewpoint, to effectively communicate requirements, the set of visualizations need to be based on an underlying common, integrated data and information model of the system of interest. This helps with consistency of the various visualizations – a change in one, can be immediately reflected in all the other visualizations, whether diagram or text-based.
———————
This concludes this 5-part series on “Communicating Requirements – Effectively!”
Comments 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.
References
Agile Manifesto, 2001, Manifesto for Agile Software Development; www.agilemanifesto.org.
Agile, 2017, Agile Extension to the BABOK® Guide version 1 & 2.
IIBA, 2015, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) version 3, International Institute of Business Analysis, Toronto, Ontario, Canada.
INCOSE-TP-2010-006-01, 2017, Guide for Writing Requirements, Version 2.1, International Council on Systems Engineering (INCOSE).
Ryan, M., Wheatcraft, L., Dick, J., and Zinni, R., 2014,2014, “An Improved Taxonomy for Definitions Associated with a Requirement Expression”, Systems Engineering / Test and Evaluation Conference SETE2014, Adelaide, 28-30.
Ryan, M., Wheatcraft, L., 2017, “On the Use of the Terms Verification and Validation”, 27th Annual International INCOSE Symposium, Adelaide, 17–20.
Samiksha, S., 2017 “Communication: Importance, Forms and Improving Effectiveness in Communication Process in an Organization”, YourArticlelibrary.com,
Sharpe, D., 1991 “Effective Communication”, Circular 1291, Montana State University Extension, Bozeman, Montana.
SkillsYouNeed, 2017“What is Communication?”, SkillsYouNeed.com
Wheatcraft, L., Ryan, M., Dick, J., 2016, “On the Use of Attributes to Manage Requirements”, Systems Engineering Journal, Volume 19, Issue 5, September 2016, pp. 448–458.
