This is part 2 of the blog series “Communicating Requirements – Effectively”.
Part 1 of this series introduced the overall topic of communicating requirements and addressed communication of requirements from several perspectives: traditional systems engineering, model-based systems engineering, and Agile.
In this part 2, I address basic definitions of requirements from each of these perspectives and discuss the various types of requirements that need to be communicated.
Requirements Definitions
When discussing the effective communication of requirements, a key question that must be addressed is the definition of a requirement. The following definitions are included in the INCOSE “Guide for Writing Requirements” (INCOSE-TP-2010-006-01, 2017), (Ryan, Wheatcraft, Dick, Zinni 2014) and (Ryan, Wheatcraft 2017). An alternate Agile perspective is included in italics for each definition.
An entity is a single thing to which a need or requirement refers: an enterprise, business unit, system, or system element (which could be a product, process, human, or organization). (An entity could be a specific feature, feature set, or the software application of which the features are a part. The entity could also be the development team.)
A need is the result of a formal transformation of one or more concepts into an agreed-to expectation for an entity to perform some function or possess some quality (within specified constraints). (From an Agile viewpoint, the concepts for a feature are presented as user stories, use cases, tables, or graphical form. The concepts represented by the user stories, use cases, and diagrams are matured to the point the development team and stakeholders (customer/users) agree on a set of stakeholder needs that will be transformed into design and code for a specific epic or sprint cycle. Acceptance, evaluation criteria, and measures of success are defined for each epic or sprint to ensure the agreed to set of needs for that epic or sprint are met. Those that are not met are included in a “backlog” which will be addressed in future iterations. As defined in the Agile supplement to the BABOK (Agile, 2017) a “need is a problem or opportunity to be addressed.” The Agile supplement goes on to state: “Agile business analysis primarily focuses on satisfying needs. Business analysis practitioners learn to understand needs by showing increments of solutions to stakeholders and analyzing the feedback received. This ongoing collaboration with stakeholders facilitates new information about the need and constantly refines the understanding of the need until the need has been satisfied.”
A requirement statement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints). For example, “The [entity] shall [perform some function or possess some quality].” For systems engineering projects, the agree-to-obligation is often in the form of a legal contract or document, containing text-based requirement statements which drive the design and production of the system of interest. The BABOK (IIBA, 2015) defines a requirement as: “A usable representation of a need” and clearly states that requirements are a key part of software development (the terms “requirement” or “requirements” appears on 253 of the 514 pages of the BABOK. From an Agile viewpoint, stakeholder needs for a specific epic or sprint are not always first transformed into formal text-based requirement statements, which are then transformed into a design and code. Rather, the development team transforms the set of needs for the specific feature concept directly into design, which is transformed into code which is evaluated based on defined and agreed-to success, acceptance, and evaluation criteria. In this case, the acceptance, success, and evaluation criteria jointly agreed to by the stakeholders and developers represents the agree-to-obligation (requirements), even though the agreement may not be in the form of a legal contract consisting of formal text-based requirement statements. Exceptions include business rules, standards, regulations, and interface definitions which are often communicated via text-based statements in tabular form.)
It is important to understand that a “requirement” is more than just a requirement statement. The INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-01, 2017) makes a distinction between a requirement statement and a requirement expression. A requirement expression includes a requirement statement with a set of associated attributes. This may not be applicable from an Agile viewpoint although the BABOK does define and advocate the concept of requirement attributes as discussed below.
An attribute is additional information included with a requirement statement in a requirement expression, which is used to aid in the management of that requirement. (The BABOK defines attributes as: “A characteristic or property of a requirement used to assist with requirements management” which is basically the same as the INCOSE definition. From an Agile viewpoint, attributes, if defined (as the authors highly recommend), the attributes could be defined for the system to be developed, for individual features, for individual epics or sprints, and the software application as a whole. If a Business Requirements Document (BRD) is developed that contains requirement statements, attributes (e.g., the owner, critically, priority, release increment (sprint or epic), rationale, etc.) can be included for each requirement statement.)
A set of requirements is a structured set of agreed-to requirement expressions for the entity and its external interfaces documented in an Entity (Enterprise/Business Unit/System/System Element/Process) Requirements Specification (Document). (From an Agile viewpoint, rather than a set of requirement expressions for the system as a whole expressed in a document, the set of stakeholder needs for a specific epic or sprint is defined and documented electronically, along with the success, acceptance, and evaluation criteria in an electronic file of some sort (spreadsheet, requirement management tool, database, etc.) Often there is no formal “document” that is developed and put under configuration control. In this context, the success, acceptance, and evaluation criteria for the system as a whole evolves during the development lifecycle depending on evolving expectations of the stakeholders.
In Agile, there are exceptions to the “no document perspective”. Even though an organization is using Agile development processes, at the beginning of the project customer objectives and business rules/requirements are often captured in a Business Requirements Document (BRD) or Agile Requirements Document (ARD). Then intent of these documents is to be an input to the Agile software development process. These documents describe the business need and context to a sufficient extent that the Agile team can estimate, prioritize, and backlog the requirements and features described. With the understanding that requirements for an Agile project must be documented ‘early and often,’ the Agile team acknowledges that these documents represent incomplete knowledge of the subject area, and that additional engagement between the Agile team and the business stakeholders will be required to prioritize and define these requirements before and during software development. The form of the requirements in these documents can include both diagrams and text-based statements.
Types of Requirements
No matter which approach (traditional SE, MBSE, or Agile) is used, it is common to add an adjective in front of the noun “requirement” to refer to different types and categories of requirements: functional and non-functional, performance, quality (-ility) requirements, interface requirements, operational requirements, regulatory requirements, design and construction standards, and physical characteristics.
Too often, MBSE and Agile development teams place too much focus on functional requirements and not enough attention to non-functional requirements. The broader set of categories is more useful to help ensure all the various categories are addressed such that the set of requirements is more complete. Since the selection of categories is somewhat artificial, not useful, and is certainly not universally agreed, the INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-01, 2017) recommends that the type (or category of requirement) is included as an attribute of a requirement statement in order to facilitate its management. To help ensure completeness, the authors recommend organizations define a template for their sets of requirements that includes the broader set of categories discussed above.
It is also important to understand the context in which the word “requirements” is used. There are requirements that can be levied on the developing organization (statement of work) as contrasted to requirements on the system being developed (technical requirements). There are design-to requirements that communicate the “what” vs. build-to or code-to requirements that communicate the “how” design decisions. There are program/project requirements that communicate requirements on the program or project team. We also talk about “high-level” requirements as contrasted to “low-level” requirements. These “levels” can be either levels of organization, levels of detail/abstraction, or levels of architecture. The list goes on and on! With all the various uses of the term “requirements” it is easy to get confused!
In truth, there is no single “best” means of communication that applies to all the various types and categories of requirements. Each means has its strengths and weaknesses depending on what 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.
Each form has value; however, no single form is sufficient to clearly, completely, and consistently communicate all these various types and categories of requirements. Each of the forms listed represent a visualization of the system from a perspective based on the intent of the message being communicated. With this viewpoint, the set of visualizations need to be based on a common, integrated data and information model of the system of interest. This helps with consistency between the various visualizations – a change in one, can be immediately reflected in all the other visualizations, whether diagram or text-based.
———————
In part 3 of this blog series, I introduce the basic communications model from a requirements perspective.
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.
