Worldwide Locations
Abstract
We build requirements at a quantum level to connect the vital elements, which are needed to realize a requirement. As we consider the relationships between the behaviors, actions, and responses, we begin to identify and associate the characteristics and conditions, which will drive and constrain the behaviors. Realizing a requirement means joining these elements together and noting them as elements of the requirement.
Sample
Atoms make up the observable universe. Similarly, everything in our business solutions is, in a sense, made up of requirements, which, like atoms, serve as building blocks for all that "matters" to an organization. What if we could see our requirements as atoms? What would they look like? If we could split one open, what would be inside? Einstein taught us though the special theory of relativity that time and space are two parts of the same whole. We examine requirements in this way. We observe basic elements of a requirement, which upon closer examination, link to each other to the point where they are inseparable.
Introduction
The International Institute of Business Analysis (IIBA®) writes, "Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders." (International Institute of Business Analysis, 2015, p. 10) This requires a sophisticated means of eliciting and specifying requirements.
"A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled. The nature of the representation may be a document (or set of documents), but can vary widely depending on the circumstances." (International Institute of Business Analysis, 2015, p. 48)
"[A requirement is] A condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed documents. Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer, and other stakeholders." (Project Management Institute, 2004, p. 371)
The IIBA and Project Management Institute (PMI) alike have done a good job at helping us understand the extrinsic value of requirements. Requirements are used to solve problems,satisfy needs, and build solutions. They have extrinsic value because they begin a causal chain of events that eventually brings us to realized value for the organization and its stakeholders. However, neither the IIBA nor PMI explains the intrinsic value of a requirement. The fundamental elements of a requirement give rise to its intrinsic value. Understanding the very nature of those elements is essential to eliciting, planning, analyzing, communicating, and managing them.
Because of this basic lack of understanding, we get sporadic arrangements of text, tables, and diagrams, which may or may not reside within a single document. Often conceived with minimal traceability, requirements exist as seeds spread across many packages or across many pages of the same document. What if there was a way solve this problem? It would mean we would have to abandon decades of thinking and begin redefining the very nature of the word "requirement." When we only understand requirements extrinsically, we are doing so in a classical sense. When we add an intrinsic aspect, we are understanding requirements at a quantum level.
Classical Requirements
There are two ways to think of requirements: Classical and Quantum. Requirements, conveyed to stakeholders as textual specifications or graphic images, are classical when they are elicited and recorded as a single declarative statement or image, across a single document or a collection of artifacts packaged together in separate smaller documents. In a classically defined environment, the business analyst would typically ask, "What are your requirements stakeholders?" Appendix-A details examples of classically specified requirements found within a generic Business Requirements Document. Some of these requirements may be poorly stated and disorganized. This is by design and representative of many of the requirements we come across. We also notice that many of these requirements relate to each other in some way. Figure 1 illustrates an example of requirements, that when separated by many pages within the document can cause potential design, development, and testing errors. Again, this is common amongst requirements packages and documents.