The Seilevel 2009 Software Requirements Holiday Medley

It's that time of year we all look so forward to, when we get to wish our colleagues around the requirements world a bit of SeiCheer with our holiday medley of songs. And worry not, if the 2009 collection isn't enough for you, you can go back in history and read our 2008 songs, 2007 songs, and our original 2006 songs!

Without further ado, sing along with us....

We wish you a Merry Release
We wish you a Merry Release
We wish you a Merry Release
We wish you a Merry Release and we hope it is near.
Requirements we bring to you and the team
Requirements for Release and we hope it is near.

Oh, bring us a new prototype
Oh, bring us a new prototype
Oh, bring us a new prototype and we'll love it, no fear

We won't go until we see it
We won't go until we see it
We won't go until we see it, so send the link here

We wish you a Merry Release
We wish you a Merry Release
We wish you a Merry Release and we hope it is near!

Oh Project SME
Oh Project SME! O Project SME!
Thy needs are so unchanging
O Project SME! O Project SME!
Thy needs are so unchanging
Not only at start are they clear,
But also when 'tis launch is near.
O Project SME! O Project SME!
Thy needs are so unchanging!

O Project SME! O Project SME!
Much time thou can'st give me
O Project SME! O Project SME!
Much time thou can'st give me
How often has the Project SME
Afforded us the scope for free!
O Project SME! O Project SME!
Much time thou can'st give me.

Rockin' Around the Requirements
Rocking around the Requirements
at the discovery workshop
Feature lists hung where you can see
Ev'ry executive tries to stop

You will get a validated feeling
When you hear voices saying
"Let's be jolly; Deck the walls with flows, oh golly!"

Rocking around the Requirements
Have a happy launch day
Everyone's drawing merrily
In a new best practice way

Rocking around the Requirements
Let the user stories sing
Later we'll write some data flows
and we'll do some modeling

You will get a validated feeling
When you hear voices saying
"Let's be jolly; Deck the walls with flows, oh golly"

Rocking around the Requirements
Have a happy launch day
Everyone's drawing merrily
In a new best practiced way

Rudolph the Brown-Nosing BA
Rudolph the brown-nosing BA
had a huge need to know.
And those who ever met him,
hoped they'd just let him go

All of the other BAs
used to scowl and call him names.
They never let poor Rudolph
join in any BA games.

Then one foggy release eve
VP came to say:
"Rudolph you are so very bright,
won't you guide my launch tonight?"

Then all the BAs loved him
as they shouted out with glee,
Rudolph the brown-nosing BA,
make our sponsors so happy!

First call for papers for RE'10. Can you hear the kangaroos calling us?

Pack your bags folks, we are heading to Australia in 2010! I'm excited to post the first call for papers (CFP) for IEEE's RE'10, held in Sydney Australia next September. I'll copy the key components of the CFP here, but visit the link for more details. I'm excited about this because we'll be working closely with conference organizers to ensure a very strong industry track - with many enhancements/improvements over past years conferences to help attract a great set of practitioners from the Product Management and Business Analyst communities as well!

CALL FOR PAPERS AND PROPOSALS

18th IEEE International

Requirements Engineering Conference

REQUIREMENTS ENGINEERING IN A MULTI- FACETED WORLD

September 27 - October 1, 2010

University of Technology, Sydney

http://www.re10.org

Important Dates

Technical and industrial paper abstracts due: February 12th, 2010 Full papers due: February 19th, 2010 Tutorials & Workshop proposals: March 15th, 2010.

Some Context

Software systems in today’s multi-faceted world are as diverse as the people who use them. While some are built according to rigorous government regulations, others must be delivered quickly to meet time-to-market deadlines or must be responsive to changing business needs. From a requirements engineering perspective, there is certainly no ‘one-size-fits-all’ solution.

RE’10 will explore techniques and methods for eliciting, analyzing, specifying, and managing requirements across diverse development teams where stakeholders often come from entirely different cultural, linguistic, geographical, and educational backgrounds; and across a broad spectrum of software projects that encompass both formal and informal development techniques and represent both small and very large scale projects.

Do you need help?

If you have never previously published at a major international conference, then you may be eligible for our mentoring program.

Please check the RE’10 website for further details.

Resource with Tips for Virtual Teams

I am a huge fan of Thiagi's work on games to use in training. He has made many games publicly available for use in your own training environments. In the past I've done some writing (here) about how we've adapted his games to Requirements Engineering training courses. But today I was browsing his site and found something I thought might be useful to others. He has posted a list of tips for virtual teams. There are just over 100 simple tips, that if you just skim the list I'm sure you'll find a handful of them can be applied immediately in your organization.

Does anyone have comments on ones you will start to use or additional tips to add?

Delivering Business Value with Agile Approaches to Requirements, continued

This post is a continuation of a previous post found here.

Changes Dave believes are coming with respect to agile-run projects and my own commentary on these:

• Requirements engineers make decisions, they are not just documenters. Expect to see that product owners are the BAs. They will less often be called systems analysts, and more often called product owners. A few years ago, we shifted from calling our requirements team members “Business Analysts” and started calling them “Product Managers” because that’s really what they have to do – own the product, even if it’s just an internal IT system.


• BAs/Product Owners will be empowered to make decisions and not just sit around waiting on sign-off. They must be experts in the business. They must work with development, not just document for them. Once they do this, they can start to make very smart decisions about what should or should not make it in the product.


• Agile is not a fad, even NASA is doing it. That said, we will see variations on agile as it grows and evolves.


• The development team can add value about requirements, so collaborate with them. They don’t all just want to gold-plate scope or push back on what’s in or out – they love to build products, so use that to your advantage.


• The business is not always right, so you still need to ask questions. BAs/Product Owners must push back when something doesn’t make sense.


• Agile is actually seen to increase the value of requirements – just make them more solution focused, and not just about doing lots of documentation.

And finally, Dave made my favorite quote from RE’09: The difference between UML 1 and UML 3 is that we moved the stick hands from being straight out to angled downwards. He can make jokes like this since he actually worked on it!

Creating BA Competency

As part of our Live from BAWorld: Boston series, I just heard a talk from Karen McKay at Doreen Evans Associates (DEA). She discussed building a BA competency in your organization. Her talk was focused on the high-level need for such a model and what the components of it are. I think a next level of discussion that would be interesting is tactics you could use to create one yourself - which specific tools and tactics work.

At DEA, they use a model that is very similar to the CMM, with five levels of competency: initial, repeatable, defined, managed, optimized and have helped build this at a handful of organizations. We do something similar to build BA maturity in organizations, but I haven't actually seen it laid out next to the CMM model quite like this. At the requirements process level, they use requirements models which I applaud - context diagrams, org charts, use cases, process flows, DFDs, etc. This talk further validated what I'm seeing in industry - alas, models are really the current state now. So if you write your requirements in plain old text, I fear that is really seen as out-of-date "technology" and you need to look at visualization techniques.

Something interesting that she did with her slides was to describe parts of their competency models using requirements models. For example, there is a swimlane diagram to show the BA role - clearly showing how BA activities relate to IT and PM functions. I haven't done much of this recently and think it's a great idea that I will use.

Anyway, this is a topic that I'm definitely interested in as we try to help customers build their competency around requirements as well. It seems like organizations are really recognizing the value of BAs now!

Using Use Cases To Create Test Cases

As part of my "Live from BAWorld: Boston" series, I attended a talk Monday by Matthew Leach of Doreen Evan Associates called "Leveraging Multi-Level Use Cases for Testing and Other Ways to Obtain Greater ROI on your Business Analysis Investment".

His talk went into great depth about how you could use use cases on your project in multiple ways, looking at different levels of detail in use cases. He quoted a study from VokeStream that indicated 76% of people surveyed manually build test cases still.

This is the one point I also wanted to emphasize the importance of: re-use your use cases to generate test cases, particularly user acceptance test scripts (UAT scripts). At some level this seems obvious to me, but I don't think it is all that obvious after all based on the above study, Matthew's experiences, and my personal ones as well! On a recent project I worked on, the business came to us to talk about how awful the integration and unit test cases were - that they just would not work for UAT. My immediate thought was "well of course not, those aren't meant for UAT". Apparently QA had told them to write their UAT scripts from these test cases. That's almost as challenging as writing them from code! So we walked them through how we could take the use cases we had written (which the existing test cases were generated from) and easily translate those into UAT scripts.

If you think of your use case having a happy path and alternative paths, you would want to blow out each of those paths into at least 1 test case each, by adding concrete data to the use case. So for example, if there is a step for the user to input "shipping information", then in the UAT script, you would want to supply actual shipping information including a specific name and address that would be in the test data set. It's important during UAT to also test the alternate and exception paths - to ensure the not-so-happy path and errors are handled to the business' satisfaction. That said, it's also unrealistic to think your users have time to test all possible paths. To mitigate this, I have two suggestions.

1. Pick the most important UAT scripts to test. You have to decide what "important" is, but it would be wise to look at the use cases that add the most business value and/or are most frequently used.
2. Use your BAs during UAT - particularly for the less important test cases that the users can't it.

BAs Need to Think Quietly

Also at BAWorld: Boston, Monday I heard Barbara Carkenoard talk about "ROI? Measuring the Real Value of Business Analysis" and her learning objectives were:

• Learn to talk about the specific value of a strong business analysis discipline
• Consider business analysis metrics for use in your organization
• Understand why a financial ROI is not normally calculated for business analysis

Some of the key points of interest for me were these, with my own commentary:

Business analysts should be involved in creating the business case. Most projects don't bring them in until the project is already decided upon. But business analysts inherently are good at analysis and can really think through whether a project even makes sense.

Business analysts need to figure out how to block out big chunks of time to think quietly. Analysis requires thinking...so let them think!

An interesting discussion took place around cultural differences between countries and how it relates to the use of process or lack of. This came out of a question about why organizations try to short-cut business analysis on the projects. And Barbara proposed that the US culture is one of "hurry up, slam it in, we'll fix it later" whereas a lot of other countries (she named Canada and the UK) are more likely to follow a process to get it done right. I laughed because just last week I had an executive say "It's okay if we don't get all the requirements defined, we'll just log everything not yet written down as defects and fix them in QA"...and he was very serious about it.

Live from BAWorld Boston

This week I find myself at Project Summit & BAWorld: Boston for about a day and a half.

This morning I presented our talk, "If you Build It, Will They Use It? Leveraging Business Objectives to Deliver Successful Projects". One thing I like about the BAWorld symposiums is that they make the slides available electronically to everyone, they are reviewed by a committee before you can present them, and they insist that the speakers provide learning objectives so you know what you are getting. So to that point, here are the learning objectives for my discussion:

• Understand how Business Objectives are vital to businesses
• Understand how to elicit and write good Business Objectives
• Understand how to use Business Objectives to assess measurable value of individual features

I had a blast with the audience here - great participation in some of my games (yes, we do them in presentations, not just our training classes!).

If you haven't been to one of these conferences, I recommend it if you are a practitioner doing Business Analysis, Requirements Engineering, or Product Management. Everyone else here is also practicing the "art" of BA and looking for new tips and techniques to take back to their organizations.

Anyway, I attended a few other talks of interest today that I'll blog about shortly!

Live from RE'09: New Ideas for Requirements Activities in Distributed Teams

Olly Gotel from Pace University presented work she has done with colleagues from around the world in a paper titled Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill. Olly started this talk by telling us that she had done something crazy with this project, and then went on to explain how they had essentially five different teams working on a project from five locations around the world. They were each supposed to write requirements for a software development competition, with requirements teaching and coaching help along the way from professors and experienced students. As she went on to describe the experience, many of us from industry chuckled with her out of empathy – her experience is so similar to our worlds today where the teams are distributed worldwide and chaos ensues!

There are a couple concepts from Olly’s course design that I think would be great to replicate in industry – either from a training perspective or project execution. The first one is related to creating competition to improve results. In past iterations of this learning experience, Olly explained they had issues with the students not understanding the value of producing quality requirements, which naturally resulted in poor results. So this time they had the teams compete with one another by creating the same deliverables and having the client choose which solution was best. As expected, the competition significantly increased the quality of their work products. We have done this with our training courses – introduced friendly competition through game playing and I’ve been pleased with the level of engagement. However I think there is something interesting to think about here with respect to injecting a different type of friendly competition into project execution in industry. Fundamentally the big turn-off to this idea in industry is that there are five times the costs to create the single project – so it's a lot of throw-away work. But, if we think outside the box a bit, perhaps we can divide projects into chunks (or just use multiple projects) and have the requirements sub-teams compete on quality of specifications, requirements issue resolution speeds, project success rates, etc.

In this course, they used an apprentice model with coaches who were students that had previously completed the requirements engineering classes. Now I think this is something that absolutely applies as-is! You can just have mentors who are more experienced people mentoring the more junior resources in requirements activities – ideally pairing them up on the same projects.

Live from RE’09: Taking Distance Requirements Training to a New Level

Didar Zowghi gave one of the most interesting talks at REET'09 I’ve heard in awhile titled Teaching Requirements Engineering to the Baha’I Students in Iran Who Are Denied of Higher Education. She was asked to teach a distance learning course on requirements engineering to these students from Australia to Iran.

She basically runs the course by teaching lectures using audio and displaying the lecture slides using Skype or LiveMeeting. However, they ran into issues with everything from bad audio connections, students who couldn’t see the visual slides, and even power outages. One improvement made eventually was to record her lectures so students could download them to play if they couldn’t hear for some reason during the live presentation. As a bonus, Didar said she learned of things she could work on by listening to herself lecture for the first time!

She had assignments for the students as well, but specifically she had a project where they had to interview a stakeholder to elicit and document requirements. She had a Teaching Assistant located in Iran who played the role of stakeholder – sometimes in person, sometimes by phone. She had the students use Karl Wieger’s templates since those were also easily downloadable.

Didar also makes time to chat with students – they might Skype her for example to find a time to chat verbally. I like to think of these as virtual office hours!

I found Didar’s talk to be so interesting based on the circumstances behind it – a great culture lesson that I thank her for. But I also find it quite relevant as we work to roll out global training programs. I am sometimes overwhelmed by the idea of how we will possibly have successful training with people on the other side of the world, but the reality is – you just make it work.

Live from RE'09: Contextual Requirements Experiences within the Software Enterprise

Kevin Gary from Arizona State University presented Contextual Requirements within the Software Enterprise at REET’09. He discussed their approach in having a multi-year project-based engineering course sequence, allowing for iterative exposure to all concepts - but particularly of interest: requirements engineering. This very much fits with popular learning theory – the idea we need to put concepts in front of students repetitively for them to really learn them. For their projects, they reach out to industry to find candidate projects so the students get to work with real subject experts to solve real problems, ultimately producing real deliverables. What I like about his style is that he is less interested in whether the company gets their perfect solution out of this work and instead he is more interested in whether the student is learning the concepts. But in reality, it sounds like the companies are getting a lot of value out of it!

One of the challenges Kevin spoke to involves how you assess students in courses like these. One thing I do like that I haven’t seen often is that he tries to check in with industry managers that hire his students to see if they are coming out of the ASU program more prepared.

So what I like about Kevin’s discussion first of all is that assessment of students is hard! We see that too and it was a big topic in an REET panel later in the week at RE’09. But I really think it’s great to see universities with programs really aimed at setting the students up for success in industry after graduation. And the final point I’ll make is that he’s absolutely right about needing students to practice the lessons lectured and hear them more than once. I think this is a major flaw in much of the requirements training offered to industry right now. We send students in for a class and then expect them to get it all - typically without revisiting the materials again.

REET’09 Went Off Without a Hitch!

Monday was the Requirements Engineering Education and Training (REET) workshop that I co-chaired with Ljerka Beus-Dukic. I’m always nervous about how these things will go – there are so many unknowns with the environment, the presentations, and the timing. However, I’m absolutely thrilled with the end result! We had 6 papers presented and it varies from a normal conference in that we had big blocks of discussion to really dive into some of the commonly shared issues in this field.

We had a lengthy discussion mid-afternoon around how do you really teach anything about requirements to students in a semester long class (or less!) and where does requirements training fit in the overall teaching of the software lifecycle at a university level. The thought is that most people learning about requirements in industry aren’t brand new to software development, they already understand a bit about coding and verification, so they understand the value and context for requirements. Yet trying to teach it to a freshman class would leave the students thinking “why do I need to know this?”

Another key point that is important at all levels is repetition in the lessons they receive. It came up again in the context of academia, where they may teach it to freshmen, and then they need to re-teach it throughout in other classes. This isn’t specific to requirements certainly, just a basic principle of good training.

We also talked quite a bit about how you assess the students in and after training. This is a long standing BIG problem across academia and industry. One issue with assessing whether any behaviors changed in an academic environment is that you teach it and they may use it on a project, but then you never see the students again. One participant actually tries to talk to industry contacts who hire the students to see if they see better results from his students. In industry, it’s very hard to isolate whether results are attributed to training. We can look for modified behavior, but this requires a dedicated resource to do so. I’ll probably talk about this more in a day or so, since we have a panel related to this on Thursday!

We then ended the day with 3 different sets of training activities presented with the intent on getting any participant feedback on the activities, but also leaving the workshop participants with the opportunity to take the exercises back and reuse them. At the very end, we played one of our Seilevel training games: Bet on Yourself Pictionary – it was fun because I was working with a group of people who are already familiar with requirements models in some form and so they could play our game – which basically enlists 2 “students” to act as analysts drawing requirements models for a specified scenario, trying to get the rest of the class to elicit the requirements from them. Oh and they had to do all of this without speaking. It was great fun and if nothing else, a lively way to end the day!

Live postings from RE'09 next week!

It's one of my favorite times of year, time for the IEEE Requirements Engineering conference! RE'09 is just around the corner, starting next week in Atlanta, GA.

I'll be co-charining the Requirements Engineering Education and Training (REET'09) workshop on Monday and then attending the main conference the rest of the week, with 2 panel appearances that should prove to be interesting.

And as always, I'll be blogging LIVE from RE'09! I hope to see some of you there, find me if you are attending this year!

What does "requirements sign-off" mean in agile?

I was recently working with a cusotmer on a project using an agile methodology. The organization was moving towards trying to do most of their projects in agile, so the nature of this is that they have a lot of non-agile pieces to their methodology still in place. We were cruising along in defining requirements and development was well into the first sprint, when the project manager told me we had a target date for the requirements to be signed off.

Wait a minute! Hold your horses folks! Sign-off? In an agile project?

I took it upon myself to remind her of the development methodology of choice for our project… and that she was asking me about sign-off in a methodology where it doesn’t really make sense…. one where the users have the right to prioritize whatever features they want in the backlog at any time. So if they forgot some features during our elicitation process, then that’s ok, they just need to figure out where to put it in the prioritized backlog, realizing something else may drop off. She laughed immediately reassuring me she hadn't lost it and that she understood completely, but the corporate process required this! So we began the discussion of what a “sign-off” would mean to us.

In the end, I think we got pretty creative with it. We did have lots of requirements in the form of user stories and other models like process flows, state tables, etc. And we were working closely with the users to elicit and review them. So what we asked them to do was to “sign-off” that at that moment in time, there were no major requirements missing, that they knew about, and there were no major issues with what we’d written down, that they knew about. The key is this means that they did in fact look at them, they participated in the activity and so development is not developing a prototype of something too far off basis. But it also keeps open their right to realize something new they need after they see it, think about it, sleep on it, or whatever.

What I really like about this is approach is that it doesn’t force anyone into a corner where they feel like they are signing away their life over a massive requirements document that they barely understood or that they are signing on a dotted line to say they are mostly perfect and got it all the first time around. So more or less, I think our version of sign-off allows the spirit of agile methodologies to prevail still.

Live from REFSQ: Deriving Information Requirements from Responsibility Models

Tim Storer from St. Andrews University in Scotland presented this paper. His underlying assumption is that in large scale socio-technical enterprise systems, you are constrained by the design of the platform you select, integration to other systems, and systems of systems factors. He contends that the functional requirements in these projects are more useful in the procurement process where you select the system to implement, and specifically less useful in the actual implementation. The reason for this is that the system is already constrained by behavior based on what you select. While I don’t entirely agree with the de-emphasis of functional requirements he implied, his overall point is absolutely valid in that you often are in a situation where you must configure the system and adapt business processes around the system.

This paper discusses how beyond the functional requirements, you also need what he calls “information requirements” which help you to configure the purchased system for the given context. These requirements tell you:

• What information is needed


• Who needs the information


• Who produces information for the system


• Flexibility for access to that information


• Consequences of incorrect information flow

And these requirements influence platform configuration, organizational changes, and system integration.

To identify these information requirements, they use “responsibilities” as a starting point. They have defined “responsibility” as “a duty, held by some agent, to achieve, maintain or avoid some given state, subject to conformance with organizational, social, and cultural norms.” They are not goals, but rather more abstract and less formal. They are not concerned with specific types of agents. Then for each responsibility, they determine the resource needs, ultimately leading to information requirements.

In his example, a self service check-in terminal has responsibility of “provide boarding pass”. Then they can look at the resources needs– blank tickets, ticket database which is fed by ticket server, etc.

For the information resources, you then have to look at what happens if it the resource is unavailable, inaccurate, incomplete, late, and even early. And ultimately you get to the details mentioned above to form the information requirements.

What I found useful in this paper is helped validate some of our own thinking we are applying on projects in that we look at something very closely related with data requirements. We’ve written before about our People, Systems, Data (PSD) approach to discovering all requirements using visual models from RML™. In this case, if we break down the Data component of PSD in combination with the People component of PSD, we have something very similar to what Tim spoke to. Very briefly, we use the People models (e.g. Org Charts) to identify the people using the system and then look at what stories they need to execute in the system (e.g. User Stories). Now we can also look at the top-level data model (e.g. BDD – a Business Data diagram), and for each data entity in the diagram, we look at how it is:

• Created


• Viewed


• Changed


• Removed


• Copied


• Moved

(And yes, I deliberately did not call out the CRUD because I’m not a big fan of the acronym!). In doing this, we can actually complete the list of user stories and identify system integration points. Similar to above we would also use the user stories to cross-verify the BDD was complete. Our data actions closely map to the list in Tim’s presentation:

• What information is needed -> the BDD entities


• Who needs the information -> Who views it, changes it, copies it, moves it


• Who produces information for the system -> How is the data entity created


• Flexibility for access to that information -> Who views it


• Consequences of incorrect information flow -> exceptions in the stories that come out of the list

Now in a recent example, we were working with a system that we did not know well. There were six main data objects and a list of about 10 user stories for the system. I wanted to validate whether the list of User Stories was complete, so I proceeded to walk through each of the 6 actions above against each of the six data objects. Not every data object could have those actions performed in the system, but it was useful to deliberately check each. In the end we identified about five new User Stories.

Live from CAiSE'09: The Science of the Web

The opening keynote for CAiSE'09 was Nigel Shadbolt from the Web Science Research Institute. This organization was started in 2006 to try to understand the science of the web and anticipate future developments and threats. It most certainly was a real pleasure to hear Nigel speak. More than proposing answers, he proposed the types of interesting questions they think about with regards to the science of the web.

One fun question he spoke to with regards to the science of the web is to think about how you handle the dynamic characterization of it? Perhaps it is changing faster than our ability to observe it, so literally how do you measure the web?

As an interesting demonstration of the power of the internet, he mentioned an article in Nature that looked at using Google search trends to track flu outbreaks. Apparently, when a flu outbreak happens, physicians report data to the CDC and it takes about two weeks to turnaround a plot these outbreaks. Google used its search trends around flu related phrases and was able to build a model that tracked the actual instances of outbreaks. When they retrofitted this data to actual historical data from the CDC and saw it highly correlated. Instead of two weeks per outbreak, it took them a day to do this analysis.

While I don't think this talk was terribly relevant to requirements (though much of their work is), it was still an enjoyable discussion. You can listen to a similar talk by Nigel here.

REET'09 Workshop - Call for Papers - Due June 29

This is just a reminder that the REET09 workshop, held in conjunction with IEEE's Requirements Engineering 09 conference, is in Atlanta this year on August 31!

I'd like to encourage all of you to submit papers or training activities related to educating people on requirements! If you don't feel like you have enough to do a paper, you could even just submit a fun activity you've done to teach people about them. Here is the workshop site with more details, but the important one is that papers are due June 29.

http://users.cscs.wmin.ac.uk/REET09/

If you aren't interested in this workshop, the greater RE'09 workshop should be a big one being based in the US this year, so I hope to see lots of you there!

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: The Requirements Object Model (ROM), part 2

What follows is our ROM defined. For context, you can see yesterday's post on why we have a ROM now at Seilevel.





Definitions for the items in the ROM hierarchy:

• Business Problem: Describes a problem to be solved.
• Business Objectives: Desired metrics the business seeks to meet in order to solve the problem.
• Business Strategy: Approach to meet the business objectives. It is not specific to any one product or project solution.
• Product Concept: Proposed solution to follow the business strategy to accomplish one or more business objectives. This becomes a project.
• Success Metrics: Statements about the specific desired outcomes to meet the business objectives.
• Guiding Principles: The approach to meet the success metrics for the product. Common themes to be considered in creating a product. These will drive the feature set and specific requirements.
• Product Features: A collection of functionality that provides a set of services to the users.
• Product Qualities: A collection of desired qualities about the product.

Features and Qualities are derived from business objectives.

The important thing is that your features should trace from your Business Objectives. And in the end, if you cannot make this leap directly, then you use the product concept, success metrics and guiding principles to help define them.

To that point, most projects actually start with a product concept. The team might define success metrics (i.e. a launch date). But they quickly jump in to defining features and qualities and then requirements and design. There are no agreed upon Business Objectives and development strays from the intent of the project. If we lived in a perfect world, we could start with the business level problem and objectives, then define the product level, and out of that define the product requirements. But having worked with many customers, nothing is ever this clean.


So instead, we suggest you do start with a product concept if you have one, and put any pre-defined features aside. Then work back up from the product concept to understand what problem it is supposed to solve. Continuously ask “why is that a problem?” until you find a problem that relates to money and write your Business Objectives at that level. We make it this simple so that you clearly know if you have gone high enough to say you have defined Business Objectives. The reality is that most (if not all) businesses exist to make money so all of their objectives relate to that goal – either in the form of increasing revenue or decreasing costs. Before I go on, I will say that every time I speak about this topic, someone gasps in the audience when I make this claim. That said, we have yet to see a project that doesn’t relate to money (and that’s not to say they aren’t doing other good things too!).

Once you have good Business Objectives, you can determine appropriate strategies to meet them. These strategies may or may not include building software products. But if they do, then you write a clear product concept that may or may not look like your original one. Then you continue through the ROM, developing success metrics and guiding principles for the product. Again, realize that the features may have changed from the original suggestions, in order to map back to actual objectives.

A quick example for today, but tomorrow I’ll give a more complete example:

• Proposed feature: Online training
• Problem question: Why do we need online training?
• Problem answer that relates to money: Online training leads to more trained users. More trained users leads to more sales. Now we can relate this to revenue!

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!