Requirement Questions

My original post to the Portland Pattern Repository appears to have emerged unscathed (as at the date of this post). Comments here or there much appreciated, of course.

What are the benefits of meeting the requirement (or the consequences of not meeting it)? [Value]

Is the purpose of a required feature documented? [Purpose]

Who is accountable for the organisation's achievement of the stated purpose? [Owner]

How might the extent to which the requirement is met be ascertained? [Measure]

Who is interested in the extent to which the requirement is met? [Stakeholder]

What is the business context within which the requirement should be met? [Context]

Within what timescales should the requirement be met? [Timing]

What risks are associated with the requirement? [Risk]

Does the requirement have a single purpose? [Atomicity]

What is the immediate 'parent' requirement? [Parent]

Does meeting all the 'child' requirements equate to meeting the requirement itself? [Complete]

With what other requirements does the requirement conflict? [Conflict]

What requirements (other than its parent) does the requirement support? [Support]

What are the underlying assumptions? [Assume]

Why has the requirement been documented? [Motive]

Stakeholder Value Trade-offs

I've been thinking quite a bit recently about "knowing when to stop" or, at least, pause. My Seilevel post (title link) addresses this in a particular context from a theoretical perspective, and also suggests that practice differs from theory.

My current thinking is that this sort of low-level decision is a stakeholder value trade-off even though it is rarely treated that way in practice. Stakeholder value trade-offs are a special case of value decision or what I call value decision deltas.

In this context, a "delta" is a change rather than a dendritic multifurcation. The connotations of the latter, and the implication from calculus in the former of infinitesimal changes have influenced my settling on this term.

I have written an elucidation of the following, but for the time being, let it stand on its own many feet:

The level of “decidedness” is optimal (for the time being) when all positive and negative decision deltas have non-positive risk-adjusted net stakeholder value.

Tom Gilb's Concept Glossary

Tom Gilb has updated his Concept Glossary, including my comments on his definition of the requirement concept (below), which he is kind enough to describe as "a particularly well thought out notion of requirement".

(The numbers in parentheses, preceded by an asterisk, refer to other concepts in Tom's glossary. The numbers in brackets refer to footnotes in the original; these follow the main text.)

1. The people whose ends a system (*145) serves are one class of stakeholders. They value the actual results, or receive benefit (*009)[1].
2. The people who consider the future of a system and/or agree to the suggestions of others are a different class of stakeholders. They perceive potential value (*269).
3. If these people take ideas forward (deciding to act or persuading others to decide to act, or considering the desirability of action), they can be described as “Founders”[2] of the resultant system or course of action.
4. The arena within which action may occur is variously described as the “problem domain”, “scope” (*419) or “context”[3].
5. A perception of value within a particular context for action is a potential requirement.
6. A potential requirement coupled with authority (*005) or discretion[4] to pursue its satisfaction is a requirement. The person[5] who confers the authority is the requirement’s “Sponsor”.
7. So, a requirement is a perception of value in a particular context for action coupled with the authority to pursue[6] its satisfaction: the authorized and contextualized pursuit of value.
8. The substance of a requirement (what is required) is the value. That of which it is a requirement is a future system[7]. The context within which it is a requirement includes the project or endeavor (“development environment”) and the anticipated operating environment. Explicit or implicit authority to pursue the requirement (within a particular context[8]) is a status of the requirement (in that context).

There are footnotes in the original:

[1] Because these stakeholders can only receive benefit from an operational system, they can be referred to as “operational stakeholders”.
[2] Or “Originators”
[3] This is not the same as Context (*483). None of these terms is entirely satisfactory, but “context” comes closest to the idea of a simple “frame of reference” or environment within which action may take place (including the operation of a system).
[4] “Discretion” might best be described here as “implicit authority”. Implicit or explicit authority could be regarded as the result of “stakeholder prioritization”.
[5] Ideally, a requirement should have a single Sponsor. A group may be collectively responsible, but even then, it is preferable for one among them to take on the role of Sponsor.
[6] “…for the time being” could be added, authority always being conditional. If the conditions are not met, the authority is no longer valid and, as an immediate and automatic consequence, the “requirement” reverts to being a “potential requirement”.
[7] Strictly, either a sub-system or an attribute (*003) of the system (*145).
[8] We can distinguish here between transitional context (e.g. a project) and operational context (where “environment” is a common alternative term). If the transitional context is undefined, we can refer to the requirement as an “orphan requirement”. If the operational context is undefined, we can only say that the Requirement Specification (*508) is defective; the status of the requirement itself is undecidable (but decidedly not authorized).