• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

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.

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

  1. Roger L. Cauvin June 19, 2009 at 3:14 pm #

    I like the emphasis on problems to be solved in the ROM. Problems we are trying to solve and avoid are the foundation of requirements and of successful products.

    I think it's important to distinguish between problems for the business and problems for the customer.

    A couple of years ago, I published a model of requirements concepts.

    In my model, a requirement is essentially a statement of a stakeholder problem in terms of the conditions that would indicate its absence.

  2. Joy June 22, 2009 at 1:32 pm #

    Roger, interesting – I hadn't seen your model previously, so thanks! Have you looked much at goal modeling, mostly found in academic papers?

    So your distinction of business and customer problems is interesting – I think that's valid in producing products for the market. Much of our work is on internal systems where the customer is the business in a sense – maybe different parts of the hierarchy, but basically the same group.

Trackbacks/Pingbacks

  1. Seilevel Software Requirements Blog - October 1, 2010

    […] the most to the business objectives. In 2009 we gave a talk at REFSQ’09 which I summarized here where I defined the Requirements Object Model (ROM) and how features trace to business objectives. […]

  2. Get ready for the newest Business Analyst Book of Knowledge! - May 16, 2016

    […] In general this section is pretty new and therefore seems less developed.  I think there is a lot to be added, specifically around using Business Objectives. […]

Leave a Reply

Your email address will not be published. Required fields are marked *