As you say in your post, the “as a, I want, so that” format is an excellent way to communicate the constraint in terms delivery teams are intimate with. On top of this, I found that the “as proven by” clauses were the key to flexible and pragmatic adoption across every project – without having to write them explicitly for every feature.

IHMO giving people standards to meet and philosophies to work by always beats verbose prescription!

We have some agreement that the term non-functional requirement is not a good one. I seriously suggest that the many people who use it have not yet thought very deeply about requirements. I detest it and its use.

My books, that Mike refers to above go into some depth on this matter for those who wish to go deeper than this reply can do.

I used to be confused myself, before I began to work out the terminology deeply.
One way to go deep is to access the many requirements concepts in my Concept Glossary
http://www.gilb.com/tiki-download_file.php?fileId=25

I used to think that ‘all requirements constrained’ (even function requirements). All requirements constrain our other choices (design, architecture, timing and more) but it is still not useful to call all non-function requirements ‘constraints’.

I got the necessary insight in a flash once, when I realized that some requirements are ‘primarily intended’ to constrain. And some requirements are not primarily intended to constrain.

They might just do so incidentally. They might incidentally inspire, seem stupid, waste resources, be unnecessary, and they might incidentally have many secondary unintended side effects. But I would not classify all non-function requirements as ‘inspirers’, ’stupid’, or ‘unnecessary’ because of these side effects. By the way non-functional (the -al) is bad grammar!

There are many interesting types of requirements that are not function requirements. See the Concept Glossary, under ‘Requirement’ for a chart of them. The most interesting requirement types from my viewpoint is what I call ‘quality’ requirements. Quality requirements describe ‘how well’ a function needs to be done (as Mike points out, mostly ‘ilities’).

But, and this is true of all scalar requirements, there are two basic scalar levels of requirement, and both can be applied simultaneously. I call these two classes ‘targets’ (levels of quality we might value reaching), and ‘constraints’ (levels of quality we would value not falling below).

A simple example in my Planguage:

Maintainability:
Type: Quality Requirement.
Scope: All software in products, or their support systems, that we provide to customers.
Scale: Mean Time to Completely Fix a Bug from its Existence is ascertainable.
——– Here are 2 different constraint requirements —-
Fail [2010, UK] 24 hours
Catastrophe [2009, Europe] 1 week
——— Here are 2 different Target Requirements
Goal [2011, Worldwide, Games Sector Products] 1 hour
Stretch [2013, Worldwide] 20 minutes.

The above concepts are explained in the Concept Glossary, but most of you can guess their basic meanings. Concepts like ‘Goal’ have a defined set of attributes such as: must be technically feasible, within budget, prioritized etc. ‘Stretch’, for example, does not have such requirements!

‘Fail’ and ‘Catastrophe’ level requirements are primarily intended to set clear lower limits. But ‘Fail’ simply means that ‘below that constraint level things are unpleasant’ (like ‘difficult to breathe’) but recoverable. ‘Catastrophe’ is a constraint that signals disaster, possibly irrecoverable (suffocation).

This is enough to hint at the potential, useful, distinctions in requirements. Hopefully the astute reader is beginning to see what we cannot simple declare all non-functions to be ‘constraints’. It is not logically true or useful!

more at the website gilb.com

Tom

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

When I named the company back in 1992 this was about incremental development (“the next step”) and making sure each increment was what we’d call “potentially shippable” today. Tom was indeed the original agilist in my mind.

I had the honor of having dinner with him last month for the first time. He and his equally brilliant son, Kai, through a challenge at me that I haven’t met yet. I’m planning to blog about it this weekend to see if anyone here can help me! Stay tuned.

So this Tom Gilb has a very strong opinion about how to handle such a requirements and give great hints how to measure these.

Sure. I’ll give you another example I heard a bit ago. The CTO happened to walk by when the team was planning. He stopped in for a listen. The team was discussing whether to build a new application by connecting to an existing orders database or by replicating that database to a local one every night at midnight. The CTO settled it by adding a story: “As the CTO, I want you to use the existing orders database so that we don’t end up supporting an additional database for 20 years just because it seems easier for the next few months.”

Others could be about “use C#” or “comply with the company coding standard.” Examples like these are why I really prefer the word “constraint” over “non-functional requirement.”

I find it very difficult to actually get business stakeholders in many clients to even agree on the value of “nonfunctionals”, a lot of these constraints seem to come from technical stakeholders like enterprise architects and technology owners.

In your view is it okay to add a story like

“as an architect, I want the system to be hosted using WebSphere application server so that I can simplify the management of my enterprise portfolio”

Assuming that the architect is not a team member…
Jeff

Good points. What I normally do in this situation is hang the constraint cards on the wall so that they are always visible. Then those constraints are in the team’s mind as they plan a new sprint. And yes they can add conditions of satisfaction (COS) to a user story to convey any implications of the constraints already accepted into the project.