The Community Blog for Business Analysts

Craig Brown
Craig Brown

Abandon the use of Non Functional Requirements

 

This model is provided by Don Firesmith of SEI.  Note the lack of an NFR category.

This entry was published on Sep 24, 2009 / Craig Brown. Posted in Requirements Analysis (BABOK KA) , Functional Specifications, Systems Analysis, Business Analysis, Structured Systems Analysis (DFDs, ERDs, etc.). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  4 members liked this article

Related Articles

COMMENTS

Leslie posted on Monday, November 16, 2009 8:10 PM
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.
Leslie
Leslie posted on Monday, November 16, 2009 8:13 PM
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.
Leslie
Marc Thibault posted on Friday, January 8, 2010 9:13 PM
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.
Marc Thibault
steve posted on Thursday, February 25, 2010 7:45 AM
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.
steve
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC