• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Business Objectives in Requirements Engineering

I have recently started working on a new project, and we recently held our kick off meeting for the effort.  One of the standard items to review is the project summary, which is usually a couple of short statements on what the project is all about.

Since I was aware that most of the subject matter experts would be attending the kick off, including the main business sponsor, I decided to replace the project summary with the Requirements Objective Model (ROM).   This would give me an opportunity to introduce our first model, and to also get confirmation on the content of the ROM.

So for those of you who are not familar with the ROM, it is a way to create a foundation for the entire project, to help ensure the success of the effort.  The ROM consists of many parts:

  • Business Problem – describes the problem(s) to be solved.
  • Business Objectives – the desired metrics the business seeks in order to solve the problem.
  • Product Concept – the proposed solution to accomplish one or more business objectives.  This becomes a project.
  • Sucess Metrics – statements about the specific desired outcomes to meet the business objectives.  These may be at the project or product level, or both.
  • Guiding Principles – the approach to meet the success metrics for the project.  These are common themes to be considered while creating the product.

There are other parts of the ROM which can be included, but this is the basic set of information.

Now the information for each of these parts can be displayed in a  table.  But more recently, we have been displaying them like we do many of our other models, in a more graphical format:

The advantage of this format is not only does it help show the relationships between the various parts of the model, but because it is graphical, it is much more interesting to look at.  And since it is more interesting to look at, I was able to grab the attention of my business sponsor and subject matter experts, and to really review the content of the model.  This led to a very productive discussion, with tweaks, deletions and additions along the way.

The end result?  Everyone in that room had a clear understanding of what we are attempting to achieve with this project, and we have a means to measure whether or not the project is successful.  We will continue to use this model as the project progresses, to help us control scope.  If a requirement does not map back to one of the business objectives, then the question must be asked if that requirements is in scope for the project?  Chances are, the answer will be no.

 

3 Responses to Business Objectives in Requirements Engineering

  1. Neville Reynolds August 12, 2011 at 3:26 pm #

    Hi Betsy,

    Thank you for writing this article on Requirements Objective Model (ROM).

    A FEW QUESTIONS: How much detail do you give to your themes when defining guiding principles? How do enforce compliance and measure compliance? Are you using this step in ROM to gauge and monitor the level of agreement you have on the ROM with stakeholders?

    Thank you. -Neville Reynolds

  2. Betsy Stockdale August 24, 2011 at 9:05 am #

    Hi Neville, thank you for your questions!

    The amount of detail we go into for the guiding principles is generally fairly high level. These guiding principles are the overall aspects that we need to keep in mind as we go through our project. For example, for the project that I am currently working on, one of our guiding principles is that the application must be intuitive and require no formal training for a user to use the application. Thus, at every step, we need to keep in mind to keep the application as simple and easy to use as possible.

    As for compliance, we do this through traceability. Every requirements must map back to one of the business objectives. If it does not map, then a discussion must be had as to why. If it is felt that the requirement is still needed, then that is an indication that there is a missing business objective, and the ROM needs to be adjusted to accomodate that objective.

    Finally, the goal is to gain consensus amongst all of the stakeholders as to what the business objectives are for the project. If you do not have consensus amongst that group, there are larger problems on the project. I would push to gain that consensus, otherwise the project is in danger of not being sucessful, and that fact must be documented as a risk and communicated to all of the stakeholders.

Trackbacks/Pingbacks

  1. Business Objectives in Requirements Engineering | devblogging.com - July 20, 2011

    […] in Requirements Engineering By RSS FEED, on July 20th, 2011 Author: Betsy Stockdale Source: seilevel.com […]

Leave a Reply

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