Prioritization and Value Maximization [Tyner Blain]

Very powerful introduction to the value-driven approach.

Writing Good Requirements: The Big Ten Rules [Tyner Blain]

There are actually twelve mentioned. We discuss the relative priorities in the comments.

There's far too much good reading on the Tyner Blain blog!

My Seilevel requirements discussion posts

I feel the need, one day, to integrate the ideas in my posts to the Seilevel forum. Until that day arrives, my contributions can be found by following the link.

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]

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).

A random blog: Seilevel Presentation

A random blog: Seilevel Presentation

I've made a few contributions to the Seilevel forum, though I'm not convinced we're on the same wavelength.

...about checking rates

...about Tom Gilb, Agile and INCOSE 2007

...about Maslow's Hierarchy of Needs, mobile phones, trading off performance

...about decision-making processes

Three Cheers for the Worry-Stack (prioritization)

Let the Market Decide (prioritization)

...how worse can be better

...the final word on Goals vs. Businesss Objectives

...to copy or link: maintainability vs. usability

Effective Requirement Process

I waited a month before replying to a question on one of Tom Gilb's forums. This is only partly because I wanted to avoid doing the student's assignment. The main reason was so that I could canvass opinions on LinkedIn's new(ish) Answers facility. Interesting results from LinkedIn were:

1. A general distrust of KPIs (Key Performance Indicators)
2. The absence of any reference to possible KPIs, however flawed or dangerous
3. A belief in the impossibility of measuring the effectiveness of requirement processes
4. A fairly low number of responses (7). Is that because it's a hard question or an uninteresting one, I wonder.

I may yet re-open the question with my own thoughts included as clarification. For the moment I must leave a little time for others to comment on my Gilb post.

Just-inTime Requirement Specification

Slightly edited for formatting, my original post follows...

[quote=achen]...savings from doing requirements right? [/quote]

I think you have to talk about "savings from getting requirements right sooner".

MTalbot is right that the costs of getting things wrong can be incalculable, but only if wrong requirements are actually implemented. It is quite straightforward to talk about the (estimated) cost of fixing a requirement during design, say, versus during acceptance testing. Only rarely, if at all, is it cheaper to fix requirements later rather than sooner.

Averaged statistics are not particularly helpful, however. Some defective requirements can be fixed almost as cheaply at the end of development. And I'm not just referring to "cosmetic" defects. Take, for example, legal caveats or wordings prescribed by statute. If we know early on that these are required but not exactly what is required, we can generally proceed with development at little additional risk while the precise text is hammered out by an army of lawyers, copywriters, focus groups and officials. Often all we really need to do is plan accordingly.

So for every requirement we can repeatedly apply what I call the "so what?" test:

[QUOTE]
This requirement may be wrong, so what?

The answer is often that it probably doesn't matter very much at this stage.

So when will it begin to matter more?
[/QUOTE]

Finalizing a requirement before it begins to matter very much saves you next to nothing. Delaying development while you try to finalize such requirements, on the other hand, can cost a very great deal, both in terms of "burned" resources and delayed, or increased risk of late, implementation.

As a general rule, we do not want to use up valuable elapsed time now unless there is a fair prospect that it will save us more elapsed time in the future. Too often, this debate refers only to cost in terms of (mythical) manhours, overlooking the simplest of critical path analyses. Even if, as is usually the case, getting the requirement right now does cost several times less in terms of effort, this "saving" may be more than outweighed by the costs of an extended critical path.

<<<--post ends

This received some positive feedback. "I think this is actually a really great point. In an SRS, how have you typically handled or called our requirements that you know are incomplete/wrong at the time of writing?"

Now I guess I'll have to come up with an answer!

Seilevel Forum

Just-in-Time Requirement Specification

http://requirements.seilevel.com/messageboard/showthread.php?p=2216#post2216

Tom Gilb's Forum

I've been contributing to Tom Gilb's forum for longer than it has existed. Some of the posts are a little difficult to find so long after the event. There are apparently 10 of them, but I can only find these 6...

Re: Theory on why it is hard to distinguish Requirements from Design, in Project Management & Product Development

Re: Gilb 88, in Project Management & Product Development

Re: Re: Definition, in Inspection, Quality Control & Defect Prevention

Re: Definition, in Inspection, Quality Control & Defect Prevention

Re: Classifying defects as Major/minor in Inspection, Quality Control & Defect Prevention

Design Methods, in Design, Industrial Design, Solutions

I also have a Gilb wiki home page, which links into my Gilb wiki contributions.

Forum Posts

I should get round to extracting specific forum posts soon enough, but contributions so far have been principally to:

Tom Gilb's website, http://www.gilb.com

The Seilevel Requirements Discussion forum, http://requirements.seilevel.com/messageboard/forumdisplay.php?f=3

LinkedIn Answers

Rob Gourdie is kind enough to publish on his blog my answer to a question of his on LinkedIn. See http://robgourdie.blogspot.com/2007/03/need-for-residual-risk-in-projects.html

Another answer of mine on knowledge management was picked as best response by Peter Nguyen: http://www.linkedin.com/answers/career-education/career-development/CAR_CRD/31514-2896748

See also my answer at http://www.linkedin.com/answers/business-operations/project-management/OPS_PRJ/29527-174352

Are you LinkedIn?

My network just exceeded 1.25 million. Check me out at http://www.linkedin.com/pub/1/382/421

If you came here from LinkedIn, please leave a comment here to say so. Thanks.

And so it begins

This is my first post to this blog.

Over the next few days, I shall create copies of, or links to, existing web content I have created.

To begin with, there are my wikipedia contributions: http://en.wikipedia.org/wiki/Special:Contributions/ARAJ.