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!
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!
Labels: Business Objectives, REFSQ, Requirements engineering, requirements modeling, requirements models, ROM, software requirements
posted by Joy at 6/16/2009 09:29:00 AM
2 Comments:
How does ROM differ from goal-modeling techniques? There are numerous intentional modeling languages in academia.
Great question Ernie - I just discussed this exact question at the REFSQ conference. One of the issues with much of what academia has proposed is that we've found the approaches to be overly complex for quick implementation on a project. Many of the underlying concepts are similar though you'll see (check out Wed's post for the actual ROM). Our foundation research was looking at a lot of other people's work - both from industry and academia to produce this, so it's not from scratch. We just boiled it down to the few important things we needed to use to effectively manage the scope of our projects.
Regarding the complexity of what comes out of academia - there wasn't much disagreement from all of the academic people in the room (most of them were)! Which led us into another discussion about how can we more closely collaborate (industry and academia) so they can come up with new ideas and we can make them implementable.
Post a Comment
<< Home