How about a wiki?

Dear readers,

today I want to ask you a question. I'm thinking about transforming this blog to a wiki. All the principles, processes, rules shall be available in a form that is modifyable for content, by anybody.

What would you prefer, the blog or the wiki? And if you'd like a wiki, should I give authorship to anybody, without any restrictions (like wikipedia)?

Please let me know. Use the comment function of this post or email me at rolf(dot)goetz(at)gmx(dot)de. If you have any special requirements, I'd be happy to hear them!

Thanks a million!

Rolf

Update on the Credibility-Info for Estimations

I updated this post with a few more interesting quotes and most of all the beautiful idea of giving ranges backwards, like "the project will be finished in 6-4 months", as the first number of a range seems to stick in people's minds.

Basic Structure for Writing Acceptance Criteria / Scenarios

Name: Basic Structure for Writing Acceptance Criteria / Scenarios
Type: Rules
Status: final
Version: 2008-09-08
Sources: Dan North's Behavior Driven Development (RSpec). I was introduced to this by Chris Matts.

Gist: Specify scenarios in a human (and machine) readable, yet compact way.

R1: Use the following sentence structure:
GIVEN <context>
WHEN <event>
THEN <expected behavior>

Example:
GIVEN the user has proper credentials
WHEN he selects an order for deletion
THEN the system accepts the selection

Example:
GIVEN the system is running under stress profile XY
WHEN interface A sends a service request
THEN the system responds to A in 3 seconds or less

R2: If you need to specifiy more complex conditions, use AND, OR, NOT
GIVEN <context 1>
OR <context 2>
WHEN <event 1>
AND <event 2>
THEN <behavior 1>
NOT <behavior 2>

4 Strategies Towards Good Requirements

Name: 4 Strategies Towards Good Requirements
Type: Rules
Status: final
Version: 2008-09-08

Gist: Left with the 3 Most Powerful Requirements Principles, what should you do? The following 4 rules can help you adhere to them.

R1: You should get to the point.
- find the priority stakeholders and use their point of view
- don't write requirements that arbitrarily constrain the scope
- seperate strategic requirements from basics, and from solutions or designs
- ask 'why' a couple of times (root-cause analysis)

R2: You should quantify requirements. 'don't be weary, it's less work than you think, once you tried
- every quality requirement can be expressed in numbers (by definition)
- every functional requirement is associated with at least one quality requirement (just ask 'how good?')

R3: You should give your requirements time to evolve, nobody really knows them completely and consistently, now.
- you will find the real requirements by frequent delivery of your product to the stakeholders, e. g. by feedback
- don't get trapped by the idea someone knows all the requirements just because you specify an existing system ' the world kept turning in the meantime, yielding 2-10% requirements creep per month.

R4. You should analyse the value of your requirements and then focus on the ones with best ROI.
- the real requirements are the profitable ones
- it is economic to focus on the top ten (max) requirements

The 3 Most Powerful Requirements Principles

Name: The 3 Most Powerful Requirements Principles
Type: Principles
Status: final
Version: 2008-09-08

Gist: A lot has been written about how requirements should look like, on what they are and what they are not, on what you should do to capture them etc. These 3 principles take you 80% of the way. They are grounded in sound systems engineering.

P1: My requirements are re-useable.
This means
- every requirement is unique. No copying please! 'I. e. I write requirements so that they have a unique name, and use the name in order to re-use the requirement in a different context, instead of copying the requirements text to the other context. Dick Karpinsky calls this the DRY rule: Don't Repeat Yourself.
- every requirement (not the whole document) provides information on version, author, stakeholder, owner, and status
- every requirement refers to s. th. and is referred to by s. th., e.g. designs, tests, suggestions/solutions, use cases, ...

P2: My requirements are intelligible.
This means
- every requirement has a type, e. g. one of {vision, function requirement, peformance requirement, resource requirement, design constraint, condition constraint} (courtesy of T. Gilb's basic requirement types)
- every requirement has a clear structure, i. e. unique, unchanging number or tag, scale, goal (= core specification attributes)
- complex requirements have a clear hierarchy, not some cloudy abstract
- no requirement in any non-commentary part uses words that are just fraught with significance, like 'high performance', 'good reliability', 'reduced costs', 'flexible'

P3: My requirements are relevant.
This means
- every requirement clearly indicates owner, author, stakeholder (in order to be able to judge relevance)
- every requirement clearly indicates its sources (in order to be able to check them)
- every requirement clearly indicates its relative priority (for a specific release, for a specific stakeholder)
- every requirement clearly indicates its constraints and goals
- every requirement clearly indicates what happens if it is not satisfied
- no requirement states a design to some problem, but every requirement declares a future state

Suggested Reading:

4 Strategies Towards Good Requirements