The Community Blog for Business Analysts

I have no problem with ignoring what type of NFR is under discussion and classing all NFRs as 'Supporting Requirements'.

What appears to be more of concern is the number of different requirement types that make up 'Product Requirements'. Under this scheme, there are only 2 types of requirement making up Product Requirements - 'Functional Requirements and 'Supporting Requirements'.

IMO, all others are types of Supporting Requirement or are Business Requirements.

Leslie.

Using a use case approach, the simplest for of requirement tree that I can envision, for a business driven project is as follows:

http://www.umllmu.com/pages/Blogs/Section4_files/clip_image002.gif

Leslie.

Amen!

Non-functional requirements are a way of sneaking preemptive design decisions into the requirements. At least, that's what my clients keep doing.

Simply: if it's not a use case--if it's not visible to some actor--then no one will know if it's ignored. If the use cases are comprehensive and fully described, there are no other requirements. Every valid NFR has at least one use case that will demonstrate its presence or absence to some actor. The place to describe it is in the use case.

The only things that should be outside of the use cases are the mission description (which includes quality attributes and other strategic decisions), the object model, and common preconditions and invariants; each one carrying a list of use cases affected. The only reason for doing the last is to save keystrokes. I don't like it because it separates parts of the use case from each other and makes the developer dig around for the information he needs to realize a use case. My preference is to make each use case not only ACID but completely described in one place. There's a middle ground using hyperlinks if your documentation tool allows them.

All this assumes that the use cases really are use cases and not a functional spec in disguise.

Too many definitions and opportunities for redundancy. A "contract requirement" might also be a "hardware requirement" or a "data requirement". "Operational requirements" and "business requirements" most likely will find their way into "primary mission requirements" as well. Assuming the "interface requirements" include "user interface" then wouldn't the requirements for a quality user interface also fall under "quality requirements" and/or "functional requirements" and/or "product requirements"? and so on. Instead of simplifying the requirements process this diagram makes it a lot more complicated and fraught with potential errors.
Assuming that Don has established a clear definition for all those categories, then we have an entire process devoted to the allocation of each requirement to each of the categories: a great analysis tool and one that surely will generate a lot of questions about the information and requirements collected. However, the number and complexity and overlapping definitions of the categories implies that much time and discussion will be devoted to the exercise which is usually not available in requirements definition efforts. And there is the question of cost/benefit of that expenditure of time.
Such complicated methods of categorizing requirements, especially when part of a mandatory process, are what drives many developers to an agile approach where instead of spending time categorizing to try to understand, they spend time talking with the stakeholders to get the clear picture.