2 Usability
2.1 Speed of Use
2.2 Required User Ability
2.3 Learnability
2.4 Training Material
2.5 Documentation
2.6 On-line Help
2.7 Consistency
3 Reliability
3.1 Maximum Failure Rate
3.2 Maximum Down Time
3.3 Ease of Recovery
3.4 Maximum Known Bugs
4 Performance
4.1 Throughput
4.2 Response Time
4.3 Resource Usage
4.4 Degradation Under Overload Conditions
5 Security
5.1 Internal Security
5.2 External Security
6 Supportability
6.1 Ease of Installation
6.2 Planned Maintenance
6.3 Ease of Configuration
6.4 Ease of Testing
7 Infrastructure Requirements
7.1 Clients
7.2 Servers
7.3 Networks
7.4 Peripherals
7.5 Web Services
8 Implementation Constraints
8.1 Languages
8.2 Operating Systems
8.3 Standards
8.4 System Interfaces
8.5 Legacy Systems
8.6 Databases

David, I think having an organizational scheme will help both in reminding BAs to ask the questions, and to make it easy for the implementation teams to find what they are looking for.

Jim, thanks for helping keep us all pulled together on this. I think we can bang out the right taxonomy and include some category descriptions.

David –
I like your classification scheme. I would like to see some descriptions of the categories you outline.

Great responses from everyone. It sounds like from the 4 or 5 of us, we are getting closer to a workable solution to bring NF requirements back into the light.

James and Marcus agree that requirements which don’t describe specific functions are very important, but propose different approaches to highlighting this importance.

Labelling requirements as functional or “something else” doesn’t support discovery (gathering) because relevant “something-elses” can be hard to find.

A third approach is to use a rich classification scheme such as:

System Requirements
* functions
* data
* qualities
Environmental Requirements
* platforms
* internationalization
* integrations
* interfaces
Operational Requirements
* installation
* operation
* access
* usage
* documentation
* training
Developmental Requirements
* verification
* design & implementation constraints
* project constraints

In the scheme above, “non-functional” denotes the 15 other types of requirements.

You can give “non-functional” a rich positive meaning by creating your own classification.

Thanks for reading and for commenting! Welcome to Tyner Blain.

You make an excellent point. User interviews are critical to gathering requirements. Users can’t, as you point out, provide good insight into non-functional requirements. Sometimes people who happen to be users as well as systems analysts can provide non-functional requirement data.

We have an article from January 2006 – Top Five Requirements Gathering Tips, where we try and cover other elements of requirements gathering. Unfortunately, it doesn’t address the question “How do we gather non-functional requirements” but it does highlight the need for poduct managers to do more than talk to users.

I think non-functional requirements do have advocates, we just tend to not talk to them about non-functional requirements. They are going to live in different areas of the organization – mostly the IT department, but also potentially in marketing, R&D, or among the project sponsors.

Thanks again!
Scott

Consider the following two scenarios: (1) “I need to compare month-over-month server load statistics for capacity planning.” (2) “I need to monitor my servers to make sure they are responsive to clients.” (2) is clearly used operationally.

Maybe the question becomes, “What is the minimum timeliness required for success (for a requirement)?”

The diagram makes it pretty clear. I get a functional requirement by going to a user and asking what they need the system to do. They’ll come back with “I want to order phone service” or “I want to produce a document” or some other goal. It’s then easy to take a look at that goal and ask your users how they need to accomplish that goal, look for failure conditions, and so on.

It’s not so easy for your typical requirements analyst (or even many developers) to remember to ask things like “what’s an acceptable response time”, “how many people can be logged on simultaneously” and so on and so forth. In most cases your business user won’t even have a clue how to answer the question. Security policies, data retention–these are important but they’re not things your typical user gives any thought to.

NFRs get neglected because unlike functional requirements, they lack an advocate.