What the agile community doesn't do with requirements

I posted this in a response to a message on the Requirements Engineering mailing list 081012. It has been mildly edited for the blog.

Here are a couple of examples of things that the Agile community tends to ignore (or perhaps does not realise) about requirements:

• Use cases (or user stories) are not requirements. Each can lead to many requirements, many of which are shared by other use cases.
• Users often don't know what they want
• What users want is often not what they need
• What users say they want is often not what they really want
• Users aren't the only stakeholders (nor are customers, the only other group commonly mentioned, nor is the combination of users and customers)
• It is important to record the requirements, why they are there and where they came from. Joe at the next desk who wrote the code based on a user story may be working for a competitor in six months (as could the customer whose user story it was). Then you can't use the "wisdom of the team".
  

There is a lot of good in the agile approach, but we must not forget that it came from the coding and design community, who tend to assume that requirements are things done by other people, if they get done at all. Therefore, not unnaturally, it is light on requirements thinking.

ScribeFire

This short post was made using ScribeFire, a way of creating blog entries directly without logging into the blog site. Maybe I'll actually post things a bit more often if it's easier!

Post in Requirements Engineering mailing list

This is a response to a post on the Requirements Engineering mailing list about the need to understand what the customer wants to do. My comments are embedded:

Roger Cauvin wrote on 01/10/2008 16.08.02:

> "Richard Zultner" (Richard@Zultner.com) wrote:
>
[snip]

>> needs of the customers (or business)? If you don't know,
>> or clearly understand, the customer needs, then you
>> cannot know if you are building the right system -
>> which then makes the technical correctness of the
>> functional spec (what we intend to build) or the
>> design spec (how we think it should work) a moot point.
>
> Yes, the only thing truly "required" is that the system, in conjunction with
> the users interacting with it, solve certain customer problems. Product
> managers and designers spend most of their time designing solutions (such as
> detailed user interactions with, and functional behavior of, the system)
> without ever clearly understanding and specifying what problems to solve.

Roger has hit the nail on the head. Part of our problem, as engineers and software developers, is that we are problem-solvers. We are very bad at problem definition.
>
>> When I review functional specs, the first thing I check
>> is whether customer needs are clearly identified and
>> understood. If they aren't (the usual case), then you
>> can spend days examining one functional requirement after
>> another, and asking, "and why does the user need this?
>> What problem does that solve for the customer?" and
>> finding out that no one, including sometimes the user,
>> knows.

Exactly. I see this often.

> One major reason for this phenomenon is that, when the typical organization
> categorizes functional specifications as "requirements", it lulls its team
> members into believing they've understood what's "required" despite never
> having understood what problems they're solving.

Yes, again

> I propose that every team serious about requirements compose a conceptual
> model of requirements concepts. For most teams, composing such a model will
> reveal numerous ambiguities and contradictions in the way the team members'
> understanding of requirements concepts. See
> http://cauvin.blogspot.com/2006/11/requirements-concepts.html for model of
> requirements concepts that I believe is relatively free of such ambiguities
> and contradictions.

I like Roger's conceptual model, but I think it misses out one vital thing (and my apologies if I am mis-reading it). This is that it does not clearly distinguish between problem definition (stakeholder requirements) and solution definition (system requirements, many, but not all, of which are functional). In my view, it is vital to have stakeholder requirements defined before working on system requirements. And note to the agilists, I do not say that the entire stakeholder requirements specification needs to be defined, just enough to allow the risks to be understood well enough to make it worth spending resource (i.e., money) on defining a solution. And notice that I talk about defining the solution, not designing it. In crude terms, stakeholder requirements are about what they stakeholders want to achieve, system requirements are about what the system must do and the design is about how it does it.