Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Thursday, August 23, 2007

Organizing Information – Part 1

Let’s say you have successfully gathered lots of requirements using various techniques and sources - now what? You are now faced with the daunting task of turning the chaos that we call “notes” into organized content in the form of a requirements specification.

At this point, you are likely in one of two situations:

1. You have a LOT of information that exists in either multiple documents or in many pages of one piece of documentation.

Example: A co-worker recently had been given 200 power point slides and 3
elicitation sessions worth of notes and had to turn this into clean requirements
for review by the business.

2. You have been able to run specific requirements sessions that allow you to contain the sources of the information, such that for a given topic, you only have 1-3 manageable sources of information.

Example: You ran 1 session on a topic, plus you were given 1 set of
requirements from a related project to roll-in. You need to create a
requirements specification on that topic.

You have more high-level organization to do in the first of these and lower level organization in the second. I am going to start by covering the first of these, in which you have chaos to organize.

Organization Approach

The approach is actually quite simple and engaging once you get started! Start by writing each concept or topic that you need to organize on a sticky note. Then begin to group the topics into categories. As you work through this, label the categories and add additional ones as necessary. At some point you step back to see if you need to group any categories together, break any apart or add new ones. It is an iterative approach to the organization, working at 2 different levels – the categories and where the topics go within the categories. What you end up with is a nice mapping of topics to categories and possibly groupings of categories.

You may see this model called an Affinity Diagram.



A few suggestions for executing this approach:

  • When creating the groupings, target having approximately 5-9 categories as suggested by the 7 +/- 2 guideline.
  • If you have more categories than that, that means you need to group your groups.
  • While executing this organization technique, I highly recommend you physically get up and move around to do it. Use your walls or large flip chart paper and put the sticky notes on the wall.
  • Move very quickly as you categorize topics. Trust your gut feel about which category to put an item in and do not over analyze it. Keep in mind, you can always move the items again – they are just sticky notes, not permanent marker!
  • You can apply this technique by yourself or with a team.
  • Name your groups with short names. Add a short description for others to know what you intend for the category to represent.

Practical example

We recently moved to SharePoint for our intranet content, and I had to move about 100 pieces of content over. I was unhappy with the previous structure of the content, so I really wanted to organize this one differently.

Before I started, I thought about the obvious categories – training, methodology, customer info. I worked with a small subset of the content and created additional categories to have a list that covered all of those topics. I took another step back from the topics and thought about the categories again. In doing so, I created one or two additional parallel categories, and I grouped some together. Then I went back to the topics and continued to assign them to categories. As you can see, I was just iterating back and forth between working at the category level and grouping the content into categories.

After a few iterations, I found that 95% of the content fit into the categories I had defined. I had a few pieces of content left that I had to look at again to determine - does it fit a category, do I redefine a category so it does fit or do I add a new category. And within no time at all, I had a nice organization of my intranet content on my whiteboard with sticky notes!

In other examples, you might use this approach on requirements projects to:

  • Group features into functional areas of a system and organize your documentation accordingly
  • Understand the different major components or systems of a large deployment and use them to plan your approach to gather requirements
  • Organize multiple features that appear in multiple sources within a single organized format
  • Working bottom-up, determine what the appropriate high-level features are for a system

Once the information is grouped, within each category you can apply different techniques to organize the information because you now have contained chaos. We’ll cover these in more detail in "Organizing Information - Part 2" next week!

Requirements Defined Newsletter Bookmark and Share

0 Comments:

Post a Comment

<< Home