One simple thing to improve your requirements – Categorize your User Stories

larry — Thu, 04 May 2006 18:48:58 +0000

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.

Sharing your marketing and communications plan with your technologists

larry — Wed, 19 Apr 2006 23:09:31 +0000

Lots of times I have customers share their marketing and communications plan with me. As I focus my work on using technology to create growth opportunities for my customers, this is pretty much expected. I need to understand what their marketing and communications efforts are saying.

I actually recommend doing this whenever your including technologists in a project that relates directly to marketing and communcations.

I would offer this caution however: The key phrase here is Understanding your plan. If they think your plan is wrong, think you should do more with technology, or think your goals, objectives or tactics are out of scale with reality, remind them that this is not their area of expertise, and that you want them to understand the plan so they can adjust their efforts accordingly.[1]

The important thing though, is to share the information. Many times technologists can suggest good ideas if they understand what the messages are that are most important for the intended audience. At the very least they will be able to review their progress with a little more insight before they show you what they have for you.

If reminding them that marketing and communications is not their area of expertise doesn’t work, and i’m amazed how many technologists consider themselves marketing gurus, ask them if they want to take responsibility for the marketing on a future project, and remind them they will have to get funding for the project as well.

Let's get started » Project Management