Live from RESFQ: The Requirements Object Model (ROM), part 3

Today we have an example to illustrate what I’ve said in the past two posts from Tuesday's setup for the ROM and Wednesday's definition of the ROM.

Let’s say in this scenario we have an online gaming company that historically has only built complex role-playing games. Now let’s say the head of product management wants to build a Yahtzee game. Here’s the process to go back and figure out what the problem is that someone thinks Yahtzee will solve, working our way to the top until we get to a Business Objective.

Note the problem at the top of this diagram finally becomes one that relates to money: The competition is still growing and we aren’t. And the business Objective can now be written to quantify the desire: 25% growth in markets other than 15-30 year olds.

Now that we have a business objective, we can define strategies. There may be 5 or even 100 business strategies and someone must select the ones to be implemented. In this case, 2 possible strategies include building a game for 7-13 year olds and advertising to the retirement community. Out of that, we can believe that Yahtzee is a valid product concept, as long as they develop it to target that 7-13 year old user group.

Finally, we can complete the rest of the ROM by crisply defining our product concept (Online Yahtzee), success metrics (7-13 year olds rate the game fun), and guiding principle (create a social environment). Then we can take on the fun task of defining features that fit within this definition.

If you follow this approach, you will have a constant guide in your Business Objectives to ensure that you are creating features that you need, but only features that you need, to achieve the business value of the project.

Live from REFSQ’09: The ROM, Experiences with a Requirements Object Model

What follows is a summary of the paper I wrote with James Hulgan (also from Seilevel) and presented at REFSQ’09 last week. The paper is titled “Experiences with a Requirements Object Model”. You can get the actual paper here.


Most software projects we’ve seen develop features that don’t add value or they don’t build what they actually do need in order to achieve the intended business value. This leads to project that are over budget, late, and often canceled because they don’t really satisfy the needs. Fundamental to this, most project teams don’t know the Business Objectives that tell them why they are doing the project in the first place, so it’s not surprising they have a hard time picking the right features to develop.


Business Objectives are hard to elicit. When teams get an answer like “increase profitability” they are complacent to stop there because they don’t want to or know how to push people to give the hard answers.


Our paper discussed the basic terminology as described by many industry experts to describe this “thing”. They use business objectives, goals, needs, business requirements, user requirements, etc. And there are subtle differences behind each of these from person-to-person. But for our work, we are using “Business Objective” to mean: the desired metrics the business seeks to meet in order to solve the business problems.


Terminology is just a small part of the problem, but the bigger issue is this: If you ask a project team why they are doing this project, they often have no concrete idea. They may have a vague phrase associated with it such as “We are reducing operating costs”. Sometimes we hear them say that they are sure the executives know because there was a business case developed – but the project team has not seen it. It’s as if you can develop the business case, start the project, and never need to look at it again. And this is where the problem lies. The Business Objectives, probably in that very business case, should be driving the feature set developed.


We were looking for a model to use to identify and represent these, as well as to train our people on to elicit them. Out of that came the ROM – Requirements Object Model.


Tune in tomorrow for a description of the ROM!

Why Do We Model Software Requirements?

The other day, I was flying to California to visit my customer. On the plane, I was seated next to a gentleman who worked for a small engineering firm in the Silicon Valley.

We quickly struck up a conversation about work and when I began to explain what I do), he got this perplexed look on his face. Seeing the confused look, I decided to try and explain in greater detail what I do as a product manager.

The gentleman quickly explained that he understood the idea of requirements but did not see how there would be enough demand for someone to do this for a living. Then he said "So, tell me what your company does that is so different from what I might do."

I briefly began telling him about requirement work and when I got to modeling he just laughed. "How and why do you model a requirement?” he chuckled. “A requirement is just a statement that says what functions you want the software to do.

I compared Use cases to an assembly instruction for one of his mechanical devices, and an ERD to an exploded view of one of the fully assembled parts that he might design. We discussed benefits of modeling in opposition to just creating a lot of "System Shall" statements.

I summarized things this way:

Requirements Models Allow Us to Organize Our Data in Multiple Ways.

There are only so many ways to say that someone needs a log in screen. But who needs it? And why?

By placing information into models, such as context diagrams or organizational charts, we can see information from angles that we wouldn’t normally have. We can use the images to gain perspective that we wouldn’t normally have.

Models Help Us to See Things That Might Be Missing.

When you’re sitting down with someone, it’s pretty easy for them to take a first stab at telling you everything they want.

But how many times have you had someone say, “Yep, that’s it,” when you asked them if you’ve covered everything only to find out that that there were, in fact, a few pieces missing.

Putting things down on paper helps us arrange information visually so that we can see the gaps that we normally wouldn’t see in a long list of requirements.

Models Create a Visual Representation of What’s Expected.

Ever tried to describe a web page without building a wireframe?

You’ve probably discovered by now that even if you scratch out a design on piece of paper and hand it to someone it’s more effective than writing 1000 words.

Plus when you put a wireframe in front of your customer, you can get them to say, “Yep, that’s what I was looking for,” or “Nope. That’s not it.” In either case, you’re able to get their feedback on something solid before you give it to development.

As we continued talking, I saw the light go on.

Models aren’t just fancy drawings that product managers use to eat up time and paper. They are an effective and powerful tool that helps us communicate with our users and developers. Don’t get me wrong, you need to be able to write up functional specifications clearly and concisely.

But do yourself a favor. Add a few models to your toolkit.

How To Choose A Software Requirements Model

Do you find that you're always trying to use process flows on your projects, but they just don't seem to fit your needs?

Do you need to start modeling requirements, but can't quite decide what models to use?

There are quite a few requirements models out there to choose from, ranging from the mundane (process flow), to the amorphous (use case) to the exotic (fishbone diagram). Knowing which models may be most helpful to you can be a bit tricky, but the following tips can help!

Choosing the Right Software Requirements Model

If your application has:

• Lots of User Interaction - useful models can be Org Charts, Use Cases, System Context Diagrams
• A Complex UI - useful models can be Org Charts, Use Cases, Wireframes
• Lots of Involvement with Different Systems - useful models can be System Context Diagrams, Data Flow Diagrams
• Data Processing - useful models can be Entity Relationship Diagrams, Data Flow Diagrams, System Context Diagrams

And don't stop with these - there are many other models to explore! Take the plunge, and break away from process flows today!

Check out these detailed explanations.

• State Tables
• Decision Trees
• Click Action Response Tables
• Data Dictionaries
  

Six Requirements Models For Agile Projects

When working on any agile project, most people will agree there is still a need to understand requirements. With the quick iterations of these projects, it’s more important than ever, to use visual models to capture the requirements. When done correctly, they are easier and quicker to create and understand than a list of written requirements. Selecting the appropriate models will vary by project; however, we can suggest a few common choices that work well.

High Level Models
At the beginning of the project, it is important to get a quick picture of the breadth of the project. This picture will help the team determine where to dive for depth. It is really important that these models are done as broad strokes, with just the bare minimum information. To get a sketch of that big picture, consider these models:

• Context diagram – This diagram simply sets the landscape of the project, clearly indicating the scope boundaries.

• Org chart – This is a model that often already exists in the organization. It can quickly help identify all the possible users or user groups that should be included in the project discussions.

• Data flow diagram – This is a quick sketch of the key pieces of data flowing through the system, including where it is created, changed and deleted. The data in this diagram should only be data that is important to the users of the system. They will help to identify the most important data and systems to work with.

• High-level process flow – Let’s start by saying this is nothing fancy or complex. The flow diagram should describe the major obvious steps. Again, the purpose is to sketch it simply, to give the big picture. In no way is it meant to be comprehensive or detailed.

Imagine one of your iterations requires bringing in new users to the team. These four models will give them an opportunity to quickly see the big picture of what this project is and where it is going, without having to read a 200 page spec (since there isn’t one!). You can also use them with your users to prioritize the most important pieces of the system for the iterations.

Models in the Iterations
Once you have prioritized the work for the first iteration, the two most popular models are likely to be:

• User stories – You can write these for the most important parts of the flow. They will be less detailed than the traditional use cases, supplying just enough depth to be developed.

• Wireframes – These will be connected to high-risk user stories, when sketching an interface might be a good aid to help the users explain what they need. These should be done in a quick modeling tool, or just by hand.

There will be other models. Sometimes you won’t even use these. The common theme in all of them is to create a visual representation of the requirements because it is faster to create and read. And with them all, only do the bare minimum necessary.