Chart of the week: Three Kinds of Requirements

You are here

February 10, 2015 — Arlington, Massachusetts
Chart 1 -- Three kinds of requirements; two kinds of knowledge.


Whatever form requirements take, they exist to provide a useful guide to delivering software value. Though "requirements" can sound like a single type of information, Tom Grant proposes that there are really three classes:

  1. Requests -- what the customer explicitly states
  2. Context -- the background behind these requests
  3. Responses -- how the team proposes to meet those requirements

According to Grant, "Both requests and responses are explicit forms of knowledge, the kinds that show up in formal communications channels, such as traditional requirements and specifications, as well as user stories and other more contemporary media. Context is tacit knowledge, the kind that is hard to elicit through these formal channels. A physician can tick off a list of features missing in her current patient records management system. Learning how a doctor's office operates -- and how that work context constrains the flow of information in and out of that application -- will take a lot longer to learn. Some of the work rules (e.g., never leave a patient's file untended in a public space) are so basic that someone who works in the office might not even think about them."

Grant continues, "The value of contextual knowledge very clear: without it, the chances of making a good decision in a reasonable amount of time diminish drastically. Both dimensions, time and accuracy, are important, because in the absence of contextual information, software professionals face a painful choice between them. How many days of research will it take to figure out whether customers will like the new capabilities we're planning? If we can't wait that long, how big is the risk that the customers will hate what we provide them? This simple return on investment for better insights -- make better decisions faster -- pays dividends nearly every day, in both big and small ways."

* Excerpted from "Software Requirements Fail Because They Are Out of Context," (Login Required) Agile Product and Project Management Executive Update, Vol. 16, No. 3