One simple thing to improve your requirements - Categorize your User Stories
Managing a software projects is, to a large degree, about managing your requirements.
The one simple thing every project can benefit from in managing their requirements is understanding how to categorize your requirements.
I often see projects that have requirements at all sorts of different levels of detail mixed together. Often these different levels confuse the team because one high level requirement actually contains many lower level requirements, yet they are not explicitly associated together that way.
4 Categories of Requirements
I like to use the more agile User Stories approach to hold a project’s requirements but you substitute Use Cases if you prefer.
The 4 categories of Requirments are easiest to classify if you think of them in terms of altitude above the projects deliverables. I learned this technique from Alistair Cockburn’s excellent book Writing Effective Use Cases. They are Sky Level, Kite Level, Sea Level, Fish Level and in this entry I’ll introduce these catagories and give you an idea when to apply a category.
The 4 Categories Described
Why the Altitude Metaphor?
The more astute reader will notice that these categories relate very strongly to the familiar Goal, Strategy, Objective and Tactic approach to classifying work efforts. So why not just use those?
The short answer is simply, the Altitude Metaphor is less confusing and friendlier for the team. For example many people will discuss at length whether something is a Strategy or an Objective. These same people can very easily agree if a requirement is at Kite Level or Sea Level. These means they can get to work completing the project quicker.
1 Sky Level / 10,000 ft. view
This is usually one requirement and it is concerned with what the overall Goal of the project.
2 Kite Level
These requirements are concerned with the Strategies that will be used to achieve the Goal of the project.
Sea Level
These requirements are focused on the Objectives that must be met to succesfully complete the project. At this level you start to see user interactions with the system.
I like to think of these types of requirements as “Black Box� user stories, so that it’s easy to remember that at this level we are not describing how the system will internally operate to complete the interaction. So the system is attributed the ability to do something but the requirement does not specifically call out the way the system does it.
Fish Level
These requirements are where you spend most of your time as a developer and a project manager. These requirements capture the detailed Tactics that will be used.
I like to think of this level as the “White Box� user stories. Where at the Kite Level, we did not describe how the system operaties interally, here we must describe the systems internal operations.
Two major types of Requirements
One of the other things that is helpful at the Kite Level and below is to make sure you know when you are talking about Functional and Non-Functioanl requirements.
Functional Requirements
These are what you normally think about when you think about what you need to do build. The system does this, the system does that, kind of requirements.
Non-Functional Requirements
These are sometimes mixed in with the other requirements or not captured at all. They can be critically important for the success of a project and should be seperated from the Functional Requirements.
Non-Functional requirements are often called the �ities� as they most often relate to qualitative metrics like: security, usability, reliability etc.
