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.