Comments on: Non-functional Requirements as User Stories

By: Mike Cohn

Mike Cohn — Fri, 18 Nov 2011 03:43:21 +0000

Hi Drew-
I don’t have any objections to these formats. I used to do non-functionals more like this but for the last few years I’ve written them more often as user stories. I don’t think doing so adds a ton of value (although it does for functional stories). But, I wrote this post to show that it can be done as a lot of people think it can’t. And, I do find that many teams prefer all their requirements to be written in a consistent manner.

By: Drew Jemilo

Drew Jemilo — Thu, 17 Nov 2011 20:13:36 +0000

Hi Mike,

In terms of format, I like to express NFRs in a format other than the User Story to distinguish them from Backlog items. I don’t include them in the backlog. Rather, they are reviewed as new features are built and part of the “Definition of Done” for a potentially shippable increment and/or release.

In terms of format, I’ve worked with the below ones but have a preference for #2:

(1) Traditional (Old School) Format — a statement.
E.g., New third party content must be integrated and available in search results within one hour

(2) Traditional Format with Value to the User — A statement with the value stated separately.
E.g., New third party content must be integrated and available in search results within one hour. Value: The end user can receive fresh search results using our search engine

(3) User Story Format — self-explanatory.
E.g., As a subscriber, I can receive fresh search results so that I don’t have to go to other sites when I need the latest content

Format 2 contains the same information as a User Story (provided that the user is clearly defined in the value statement). However, the format more strongly suggests that it isn’t a feature on the backlog which can be discarded once the conditions of satisfaction are met. Instead, it is persistent.

Thoughts?

Drew

By: Mike Cohn

Mike Cohn — Wed, 09 Nov 2011 01:24:44 +0000

Hi Sonali–
Yes, NFRs can be viewed as part of the definition of done. That’s a good point I often fail to mention so thanks. I usually start by thinking of a non-functional as it’s own user story. Once we do that story and “accept” the non-functional requirement, it becomes part of the definition of done and is applied to every story from then on.

By: sonali

sonali — Tue, 08 Nov 2011 09:25:48 +0000

Hi Mike,

Very very informative and interesting comments. Could the NFR also be taken as part of Condition of Satisfaction as for each functional US we could then check as part of Done or Demo if these are also met or not.

By: Mike Cohn

Mike Cohn — Tue, 01 Nov 2011 16:41:45 +0000

Hi Aeomer–
I think that writing stories in first-person for non-functional requirements is fine. I see programmers talk this way all the time, “OK, if I’m the loan approval system and you pass me bad data, I should first….” So writing a story in a similar way has always seemed fine to me.

By: Aeomer

Aeomer — Tue, 01 Nov 2011 14:42:06 +0000

Describing non-functional requirements often means there is no ‘wetware’ as the consumer. The examples given in the blog neatly avoid the issue altogether by coming back to how a physical person (wetware) is affected; noble but very contrived.

The solution for me is to personify the consumer of the non-functional system. Let us say we have a SOAP interface call “Sudsey” that is consumed by another service called ‘MyCoolConsumer’, I would personify the consuming client by using its name as if it were ‘wetware’. eg. “As “MyCoolConsumer” I need to be able to securely obtain information from Sudsey.
It is perfectly fine to use the name of the consumer (MyCoolConsumer) as it is a role with needs. Its needs are much easier to scope with a User Story than any real-world person
Further, this method does not break the Scrum-way and neatly prevents arguments from some of my more Luddite colleagues.

Comments?

By: Prasantha

Prasantha — Mon, 17 Oct 2011 06:38:13 +0000

Thanks so much Mike.

By: Mike Cohn

Mike Cohn — Thu, 13 Oct 2011 04:15:36 +0000

Hi Prasantha-
In general, I do think constraints include development work–a performance story, a usability story, etc. You’re correct about the “As the CTO, I want the system to use the existing orders database” but that is not the most common type of constraint or non-functional requirement.

I tend to hang constraints on the wall in the team room or put them on a project home page where they remain visible. Many do, however, start on the product backlog because there is work to be done. This is covered in more detail in the Succeeding with Agile book, which talks about the two costs involved with nonfunctionals–the cost of initial compliance and the ongoing cost of supporting a constraint, which is really best thought of as something like a tax.

By: Prasantha

Prasantha — Thu, 13 Oct 2011 01:55:36 +0000

Thanks Mike. When I write a user story, I always get the feeling that this is something to be developed during the project. But these constraints even though written as separate user stories are nothing to do with developments. Rather they are for the team so that you do not violate them while you develop other stories during the project.
For example “•As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don’t have one more database to maintain.”. There’s no development involved, but a reminder for the team.
Am I correct in the interpretation of constraints? So, where should we place these constraints? I dont feel it should be in the Backlog.

By: Mike Cohn

Mike Cohn — Thu, 29 Sep 2011 18:03:05 +0000

Hi Prasantha–
Yes, these could be written as tests. Any user story could be rewritten as a test–users can log in would be a rewrite of “as a user, I must login before accessing parts of the application.”