We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? James Leatherman points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…
Structured Non-Functional Requirements
[Update Aug 2009: I realized the previous version of the following sentances could imply that this is “his” model – it is my interpretation of his model.] My interpretation of Karl Wiegers’ structured requirements model (explained here) is show below.
- Goals are achieved by enabling use cases.
- Use cases are enabled by implementing functional requirements.
- Functional requirements must have the characteristics defined in non-functional requirements.
- Functional requirements drive design decisions that are restricted by constraints.
- Design choices guide implementation
- Implementation is product
James realized that non-functional requirements are not getting enough attention. His solution approach is to deny that there is such a thing as non-functional requirements, thereby forcing people to deal with those requirements. By eliminating the stigma, I suspect he hopes to remove the second-class citizen status that non-functional requirements seem to have.
Here is my issue – there is no such thing as a “non-functional†requirement. In the IBM Rational world, there are Functional Requirements, encompassing business use cases, needs and features, UI specs and so forth – and whatever is left over (security, error recovery, etc.) gets heaped into “non-functional†requirements. Not only is this improper classification and a total misnomer, but it almost always gets overlooked by the project team. Bad idea, considering that, from my experience, 80% of the risk is in these neglected areas.
There is value in maintaining the classification of non-functional requirements. Requirements that represent different aspects of what shall be done should be separated, but they should also be treated with equal importance.
- Functional requirements define what the system must be able to do, without defining how this is to be accomplished. The system shall store contact information. The system shall apply shipping and tax charges when billing customers.
- Non-functional requirements define measurable, characterizing aspects of what the system must be able to do. The system shall return search results in under ten seconds. The system shall process at least 10,000 orders per minute.
Equal Rights for Non-Functional Requirements
As James pointed out, much if not most of the risk of delivery is in failure to meet these characterizing requirements. What we need to do is make sure that non-functional requirements get as much attention as functional requirements. We’ve reworked our structured requirements diagram to better reflect the importance of these requirements.
- Goals are achieved by enabling use cases.
- Goals drive non-functional requirements.
- Use cases are enabled by implementing functional requirements.
- Use cases influence non-functional requirements.
- Non-Functional Requirements define the characteristics of functional requirements.
- Functional requirements drive design decisions
- Design choices are restricted by constraints
- Design choices guide implementation
- Implementation is product
We’ve made four distinct changes to the diagram
- Non-functional requirements define characteristics because they are needed for the goals. When a characteristic is irrelevant, it should not be documented. This explicit traceability to the underlying goal helps us keep our eyes on the ball and not lose sight of the importance of these non-functional requirements.
- Use cases influence which non-functional requirements need to be defined. The use cases embody the interactions that users will have with the system. Some non-functional requirements are independent of the specific interactions, so we used a dashed line. The dashed line serves to remind us that this relationship can exist but might not.
- We’ve re-ordered the statement of the relationship between non-functional requirements and functional requirements to highlight the significance of the non-functional requirements.
- Constraints represent limitations on how a solution must be implemented (database, supported hardware, etc). We’ve moved the relationship to properly show that constraints influence design decisions, not requirements decisions.
Conclusion
Non-functional requirements are critically important. They are distinct in their structure and content. That distinction should remain, if for no other reason than to help people focus on writing good requirements.
If you came here looking for ‘leathej1’s comments – they are under the following post http://tynerblain.com/blog/2006/05/17/foundation-series-functional-testing-of-software/
Thanks for reviving the post – I missed it that day it was away.
I think the reason that non-functional requirements get short shrift is in large part because business analysts can’t get users to articulate them.
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.
Very interesting conversation on an important, yet often overlooked area. For performance related NFR, I think it is important to understand a user’s interaction with a system.
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)?”
Kevin,
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
Thinking Outside The Two Boxes
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.
Kevin, you hit it dead on. BAs do not typically ask the quantifying questions of end users and sponsors – but they should. And I don’t think that it would be especially difficult to do.
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.
This is awesome stuff guys! Sorry your comments slipped through the cracks for a month!
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.
I’ve just stumbled across this old article while looking for something else and really liked it. Here is a copy and paste job out of one of my specs. I use this as a guideline or “checklist” against EVERY requirement to try and flush out the Non Functional requirements. I can’t agree more that thinking about Non Functional requirements while documenting Use Cases with Users is a must. Waiting until functional requirements is too late in my opinion. Although there will be more to gather at that stage you’ll miss the business critical ones.
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