INDEX for non-functional requirements
I talked to Scott at Tyner Blain about my non-functional requirements series and he suggested that I create an index for them. As I add new posts, I'll add them to this list and make sure the index appears in the Popular posts section.
Complete list of non-functional requirements
This is a very early post containing the names of the different types of non-functional requirements. No details provided but a good starting point.
Availability
There are two key concepts for availability: Hours of operation and reliability. The first refers to what times a system will be available for production. The second refers to it's availability during the stated hours of operation. I supplemented this post with the following one, Extreme availability & reliability.
Capacity
Capacity deals with the projected load that a system will handle. This includes its growth and the timing around when heavy load conditions will occur. As companies move towards a more service oriented architecture approach it becomes very important to be able to understand capacity.
Data currency
How up-to-date does your information need to be? Do you need real-time or are delays acceptable? Data warehouses generally operate a few days or weeks behind. For general reporting needs, this situation is acceptable.
Data retention
Address your needs to store and dispose of information. There are industries which have legislation surrounding the acquisition and disposal of information. Recognize that some types of data become useless as time passes.
Disaster recovery
This non-functional requirement relates to a business' needs for a system to recover from an outage. How important is the system and how quickly does it need to be returned to production?
Error-handling
Describes a system's ability to handle unexpected situations such as purchase orders for unrecognized products. How should you account for these transactions?
Internationalization
This is an important characteristic for applications that will operate in multiple geographic regions, currencies, tax regimes and languages.
Logging
A system's ability to keep track of its activity. This provides an audit trail that can be used for problem-solving.
Security
Describes how a system handles customer privacy as well as user privileges.
*NEW* Upgradeability
This characteristic describes the ease of replacing a component in a system with another one.
*NEW* The ignored step-child - the non-functional requirement
Links to an important conversation on the importance of non-functional requirements and their neglect.
6 comments:
Marcus, this is really good stuff. Most product managers pay little attention to nonfunctional requirements and have a tendency to document a laundry list of functional "requirements" that are really design-level functions.
Another useful endeavor would be to start an index of useful metrics for each nonfunctional requirement. Inspired partially by you and Scott, I have attempted to do so for availability.
Just a clarification of my last comment, Marcus. In your treatments of each nonfunctional requirement, you do describe the different attribute details. That is an important step. Metrics are slightly different. They are the specific means of measuring the attribute details.
I don't think I'm telling you anything substantively new here, but I wanted my terminology to be clear.
Roger, a list of metrics for each non-functional requirement would be an excellent resource for a project team. I look forward to reading your posts. Thanks for participating.
Marcus,
I just posted something on my site that has been gnawing at me for a few years - the fact that in my mind there is no such thing as a non-functional requirement. as defined in the traditional RUP sense. I won't paste my rationale here - it is kinda long winded. You can see it here.
I have a question. Profiling, tracing and policy enforcing are functional requirements, nonfunctional requirements or something else?
In response to this comment, I have a question. Profiling, tracing and policy enforcing are functional requirements, nonfunctional requirements or something else?
As per your statement, there are a few things outside of functional and non-functional requirements that are important to the success of an initiative. As an example, change management to ensure that your new system will be adopted and accepted by the end-users. My initial thoughts are that policy enforcement could also be part of change management; particularly if it represents a do different. That being said, as part of the requirement (functional and non-functional) gathering process, the identification of pertinent policies and legislation that must be followed should occur.
Concerning tracing, I'm assuming you are referring to understanding how a transaction flows through a system, its touchpoints, who (or what) did something to it, etc... If this is what you meant, I do have a post on logging that may cover that off already.
In terms of profiling, can you elaborate on what you mean? I've been looking at marketing topics a lot recently so I'm thinking profiling of people and preferences. Are you thinking about application profiling?
Post a Comment