17 September 2009

Requirements taxonomy (again)

Last week I pointed you to a spirited discussion at the Requirements Engineering discussion group.  As the discussion went on Don Firesmith offerred to share a diagram showing the varous ways he classifies requirements.

A particular thing he wants you tonote is the lack of a category called "Non Functional."

Analysts - What are your thoughts?


  1. Actually, I don't see a lot of value in this type of requirements taxonomy which focuses on what the requirement is about. I am more interested in a taxonomy that focuses on the format of the requirement. These include story boards, scenarios, walk-throughs, and user stories. Also, what is missing here is marketing and technical requirements. Your readers may be interested in this introduction to requirements that includes how they relate to the Information Architecture of the system. In the end, it's not about classifying requirements as it is raising the quality of the requirements.

  2. Read a discussion on this topic at Linkedin

  3. What problem are we trying to solve here? If you can't define it leave it alone.

    Aren't we simply gazing at our own navels, here? Functional versus Non-Functional Requirements helped the IT BAs distinguish between a feature set and business rules (usually using a FURPS or FURPS-Plus template).

    The bottom line is very simple: Non-Functional Requirements are part and parcel of the project, need to be tested and inserted into the Traceability Matrix so it can be rolled up into a master document of some sort.

    This constant churn over definitions, Three Letter Abbreviations and more and more finely grained 'differences' in methods are driving many people (the undersigned included) crazy.

  4. Anonymous10:08 pm

    Ignoring non functional requiremnts like security and performance makes life a lot simpler - but these are NOT quality issues. Even of the customer is not able to explicitly articulate the non-functional requirements if they are ignored the resulting solution may work but still be totally unfit for purpose. It is thios sort of attitude that also explains why projects so often fail to deliver what the customer needs...

  5. @ Scott

    I think the problem Don is articulating and trying to address is that not all nfrs are equal, and there are a broad range of other nfrs such as the ones in the diagram.

    His push appears to be to call things what they are, and to try to drive in some higher maturity around requirements management and discussions.

  6. @ Anon

    Sorry, but I am not getting this line of argument.

    I belive what we typically call NFRs are important, and that they drive a large portion of the cost and schedule of enterprise IT projects.

    I think what we are talking about when we refer to these things is called 'grade' in pmi jargon.

    But putting the jargon aside, I think I agree with you that we have a responsibility to lead clients through these issues and get them to choose the right options for them.

  7. Donald Firesmith8:30 am

    My problem is that the different types of "nonfunctional" requirements are often equally important as the functional requirements and from a taxonomy standpoint NFR is not a legitimate category (i.e., don't define something by what it's not). By grouping several radically different kinds of things in a grab-bag like NFR does them a disservice.

  8. Thanks for the clarification Don.

  9. Regarding the first comment on "...format of a requirement statement..." I highly recommend the book by Benjamin Kovitz "Practical Software Requirements: A Manual of Content and Style" This is the absolutely best book I've read on how to actually write the text of requirements.
    --dave Blaine