This is part 3 of the blog series “Communicating Requirements – Effectively”.
In part 2, I addressed basic definitions of requirements from each of these perspectives and discuss the various types of requirements that need to be communicated.
In this part 3, I introduce the basic communications model from a requirements perspective.
———————
Communications Model – A requirements Perspective
To address the debate concerning the best means of effective communications of requirements, we make use of the basics of communication theory as described in the following sources: “What is Communication” (SkillsYouNeed 2017), “Communication: Importance, Forms and Improving Effectiveness in Communication Process in an Organization” (Samiksha 2017); and “Effective Communication” (Sharpe 1991).
As shown in Figure 1, there is an idea or concept (requirements in this case) that needs communicating; there is a sender of a message, the message sent (requirements as intended), and the receiver(s) of the message sent, filters, feedback, and the message received (requirements as understood).
Figure 1: Requirements Communication Model
Filters: There really is no single “reality”, only what each individual perceives to be “reality”. Everyone has their own unique mind map that reflects their perception of the world around them. This mind map is a result of such aspects as the individual’s upbringing, family environment, gender, education, religion, age, work experiences, genetics, and life experiences. Included in this mind map are biases for or against certain concepts as well as preferences concerning the means used to communicate a message. These biases can result in a receiver who may not have an open mind and has personal prejudices, making false interpretations and conclusions concerning the message being sent. This mind map serves as a “filter” on how we receive, interpret, and understand information and how we encode information we are sending to communicate with others.
Means of communication: We also have a choice of the “how” or “means” to communicate a message in both the form: verbal, text, diagrams, and models and the media used: face-to-face, phone, text message, email, printed documents, electronic documents, and electronic tool(s) database or model.
Feedback: An important part of the communications model is feedback. Feedback is how the sender can determine how the message was interpreted and understood by the receiver(s). When communicating verbally, face-to-face, we can establish a dialog with the sender getting immediate feedback. However, with the other means of communication the feedback is often delayed. In the requirements world, the delayed feedback may occur in written form or during some type of review, either informal or formal. A less desirable form of feedback is when the developers come up with a design based on an alternate interpretation and understanding of the requirements that was not the intent of the sender – that is, a failure to communicate!
Our senses also are an important part of communications. Some people may communicate best via visual cues, sound, or emotions/feelings. For a person that is a “visual” person you would ask for feedback such as “How does that look to you?” vs “How does that sound to you? Or “How does that feel?” When communicating verbally, face-to-face, it has been suggested that 80% of communications is nonverbal. How our words sound, our facial expressions, our body language, odors, and our appearance all are part of communication. Facial expressions and body language also provide feedback from the receiver(s). This poses a significant challenge when communicating using other, non-verbal, forms of communication and non-face-to-face, types of media.
Time: Another key consideration is time. The senders of communication could have sent a message in the past intended for both present and future receivers of the information (i.e., business rules, standards, regulations, requirements). Senders in the present have to consider that the message they are sending to present receivers has to be equally interpreted and understood by receivers in the future. In many organizations and system development efforts, especially for projects spanning years, there will be turnover of personnel. Verbal, face-to-face communication may be desired, but when it comes to requirements, there are limitations. Verbal, face-to-face communications occur in the present. For communications to future recipients, verbal communications, even if recorded, are not an effective form of communications for requirements. For future recipients, senders need to not only communicate a message, but also the rationale behind the message and the context of the message. For requirements, including rationale as an attribute is critical for successful communications to future recipients.
Formality: Last, is the degree of formality (Samiksha 2017) of the communication. Formal communication refers to official communication both external and internal to the organization. Governance, regulations, standards, contracts, binding agreements, task assignments, granting official authority, and establishing binding goals and objectives are examples of formal communication. Formal communication generally takes place in the written form such as the issuance of a notice, letter, memo, document, etc. Informal verbal or oral channels are avoided in formal communication as there is no record or proof of such communication. Thus, the old saying “I want it in writing!” The advantages of formal communication include: 1) a well-defined and orderly flow of information; 2) the source of information can easily be determined; 3) the information itself can be easily located, and 4) it allows one to show “proof” that the information was communicated. A disadvantage is that formal communications often have to follow a formal review and approval process that takes time. Then, in turn, once the document is put under configuration control, changes also have to follow a formal review and approval process, taking additional time. Another disadvantage is that the “document” itself and control of the document can overshadow the information being communicated via the document. Feedback can also be a problem both in time and form.
Informal communication includes unofficial, nonbinding communications such as social interactions and discussions between individuals and team members, speeches, radio, television, etc. From a product development perspective, informal communications can be effective when occurring between individuals who trust each other and do not need “proof” of the exchange of information. Informal communications are often verbal or oral channels (face-to-face, phone, telecom, meeting, etc.), but may also take place via emails, text messages, and posts on social media. For informal verbal or oral channels, unless recorded, there is no official “record” that the interchange took place. For emails, text messages, and posts on social media there is a record, but unless formally controlled in some manner, the record is considered informal.
A key advantage of informal communications is speed. Informal communications generally occur very fast without the time overhead that exists for formal communications. Feedback is very fast as well. For verbal and oral face-to-face channels the feedback is immediate. For the other informal means of communication, feedback can be very fast as well. In addition, changes can be communicated quickly based on the feedback. Disadvantages of informal communication include: 1) it occurs an unsystematic manner, 2) it is not formally documented, lacking a way to show proof or cleanly disseminate the information, 3) what was communicated can be subject to debate, especially when the various filters are considered (he said/she said type of arguments), 4) informal communication can be distorted when passing from person to person – due to the various filters, and 5) it may not be binding.
Applying the Communication Model: It is very instructive when we apply this communication model to the communication of requirements since requirements development and management are effectively exercises in communication. On the left of Figure 1 are the ideas and concepts we are trying to communicate via requirements. These include the problem statement, the stakeholder need, goals, and objectives, and drivers and constraints. Although these ideas and concepts come from many sources, from a requirements perspective, we receive these ideas and concepts from the various sources through our personal filter. Then using our personal filter, we encode the requirement which we transmit via some means (form and media) to the intended receiver(s) who, in turn, decode the message via their own personal filter(s). The encoding of the message by the sender and the decoding of the message by the receiver(s) is based on their understanding of language, but also training in product development methodologies, processes, tools, culture, and work environment of the organization they are employed.
An individual may have worked in a given domain all of their career and may therefore assume that everyone does product development the same way. If an individual has only worked in a systems engineering environment that is formal, document-based and uses the traditional waterfall based processes, that individual is likely to follow that process to encode and decode requirements. In an organization that is implementing MBSE, and staff are trained in one or more of the modeling languages (e.g., UML/SysML), then they are likely to try to encode and decode requirements via various diagrams and visualizations that make up an overall model of the system of interest. In an Agile software environment, staff are likely to be guided by the Agile manifesto (Agile Manifesto, 2001) and guiding principles when it comes to the communication of requirements (which can be a mix of both formal and informal).
The challenge in communicating requirements is whether the requirement received, interpreted, and understood by the receiver reflects the same intent of the requirement that was communicated by the sender. In Figure 1, the goal is for the two boxes labeled “requirement(s) as intended” and “requirement(s) as understood”, to represent the same message – the requirement as intended by the sender is the same as the requirement understood by the recipient. When the messages are not the same, problems are going to exist such that the system under development is going to either, or both, fail system verification (not meeting requirements) and fail system validation (not meeting the needs of the stakeholders in the operational environment).
One Size Does Not Fit All!
In truth, successful product development approaches must include multiple forms and media to completely develop and effectively communicate the requirements from which a product is designed, coded/built, verified, validated, and delivered. All the various types and categories of requirements cannot be communicated effectively using a single form or media. To effectively communicate requirements, wise business analysts and systems engineers recognize the need to use whichever form and media is the most appropriate based on both what they are communicating and the audience they are communicating to – know your audience! It is the responsibility of the sender that the message or information sent is in a form that is of value to the receiver. To communicate requirements effectively, the sender must acknowledge the various filters used to encode and decode the requirement message that is being sent such that the sender’s meaning is interpreted and understood as intended by the receivers, no matter the form or media used, and development lifecycle phase.
If the source is stakeholder expectations for features and functions that will supply those features, then a functional flow block diagram may be the most effective form of communication. If the customer and developer are able to meet face-to-face frequently, then user stories, use cases, and agreed to success, evaluation, acceptance criteria can be used to communicate requirements. If a regulator is trying to communicate regulations to many present and future developers, a text-based set of requirements in a printed or electronic document would be the most effective means of communication. If a customer is developing a Request for Proposal (RFP) to be released to multiple, geographically located potential bidders, then both the technical requirements for the system as well as the Statement of Work (SOW) requirements on the bidders need to be text-based “shall” statements with the characteristics of well-written requirements as discussed in the part 5 of this blog.
The key is that not one single form and media type will be best for all the types and categories of requirements that must be communicated. Referring to Figure 1, pick one input, pick one type of sender, identify what the message is, decide who the recipient(s) is/are, whether you are communicating to current or future recipient(s), and then pick the means of communication that is the most effective and will meet the needs of the recipient(s). The answer will be different for each of the inputs listed, the specific message, and each of the recipients.
———————
In part 4 of this blog series, I discuss the advantages of text-based requirements vs alternate forms of communicating requirements.
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.
