Business, stakeholder, system and technical requirements

Terminology bedevils requirements. So here are my views on some common terms.

Business requirements generally define the problem to be solved. The general term we used in Telelogic's Professional Services was "stakeholder requirements". Some people divide these up into levels and differentiate Business and Stakeholder requirements, but they are really just different levels of problem definition. For example, the CEO's view of the problem is necessarily less detailed than that of the department heads. In terms of (at the risk of re-opening a different debate) "function", these requirements define what the business (or stakeholder) wants to achieve - the capabilities. But they must also define all those other types such as performance, security, usability, etc. - and if you don't like the term non-functional for these, then we used "constraint". It's not perfect, but I think it worked better than non-functional without some of the confusing connotations of "quality requirement".

System requirements define (but not design) the solution to the problem. Again, there can be (generally are in a non-trivial system) several levels, for systems, sub-systems, components, etc. In terms of "function", these requirements define what the system must do to provide the desired capability and we were quite happy to call these functions. Again, there will also be constraints in the system requirements.

Stakeholder and system requirements, especially constraints, can be identical. For example, physical constraints, such as a maximum weight, are often identical.

Oh, it is also important to note that you can't always (probably not in general) separate constraints from capabilities or functions; most (but not all) constraints are tied to a single capability (function) or a related set.

Powered by ScribeFire.

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.