Communicating Requirements – Effectively!

Abstract

Requirements are the language we use to communicate stakeholder needs for a system of interest to developers, designers, builders, coders, testers, and other stakeholders. Increasingly, there is debate about which means (form and media) of communications is best for communicating requirements and sets of requirements. As part of this debate, one means of communication (such as diagrams, use cases, or text‐based) is often advocated (with a lot of passion in many cases) over the other means of communication. Which side is taken in the debate depends on the specific idea or concept being communicated together with the domain, culture, people, and processes used within the specific organization. Consequently, there is no single “best” means of communication that applies to all the various types of requirements. Each means of communication has its strengths and weaknesses depending on which message is being communicated, who the sender is, who the receiver is, the needs of the receiver, and the filters used by both the sender to encode the message and the receiver who must decode the message. This paper goes back to the basics of communication theory to address this debate and concludes that, while each means of communication has value, no single means is sufficient to clearly, completely, and consistently communicate all of the various types and categories of requirements. Each of the means advocated represent a visualization (graphic or text) of the system from a perspective based on the intent of the message being communicated. With this viewpoint, rather than focusing on a single type of visualization, a set of visualizations is needed to effectively communicate requirements. This set of visualizations needs to be based on an underlying, integrated data and information model of the system of interest.

Technical debt in systems engineering—A systematic literature review

“…The implication of the confusion in definitions can be seen by examining two products from the International Council on Systems Engineering (INCOSE): Project Manager's Guide to Systems Engineering Measurement for Project Success 39 and Needs, Requirements, Verification, Validation Lifecycle Manual 40 . Each of these publications provide a different definition of technical debt: “the promise to complete a technical shortcoming in the future while declaring it complete today.” 39 “what occurs when a project team uses a quick short‐term solution that will require additional development work later to meet the needs of stakeholders.” 40 …”

“…Measurement for Project Success 39 and Needs, Requirements, Verification, Validation Lifecycle Manual. 40 Each of these publications provide a different definition of technical debt:…”

“…39 • "what occurs when a project team uses a quick short-term solution that will require additional development work later to meet the needs of stakeholders." 40 The first definition does not include the concept of technical debt interest-that there will be additional work required due to the tech-…”

Ontology for Technical Debt in Systems Engineering

“…Some authors propose alternate definitions of TD, including presenting it as a gap between the actual and should-be state of a system [6], [12], [45], the existence of incomplete or immature components [7], [46], or work not yet done [2]. We assert that these definitions do not reflect the central tenant of the Cunningham's initial concept -that the decisions made today may result in increasing consequences tomorrow.…”