Requirements Modeling: An Interview with Joy Beatty

[interview]

Joy Beatty: If you create perfectly clean blueprints for a house but forget to check that there is a back door, and you end up with a house where your kids have to go out the front door to get to the back yard, are you going to be happy? No! The same is true of requirements and systems. If we have well-written requirements, that certainly helps ensure a complete system, but it does not guarantee it. For example, the development team could overcommit, the well-written requirements might be twice as big in scope as there is budget, and, further, the requirements might not solve the actual business problems.

To address this, we start by understanding the real business problems and business objectives and derive requirements to solve those problems and meet those objectives. In fact, throughout the project, the entire team needs to keep a razor sharp focus on solving those business problems. If they do that, they can help ensure a successful project—a complete system that also delivers business value.

Heather Shanholtzer: If you had to pick one requirements model to recommend, which one would it be and why?

Joy Beatty: This is a tough question because models each serve a different purpose and projects vary so much. However, almost without fail, every project needs a Business Objectives Model, and when it is used, it is the most important model. The Business Objectives Model is what allows us to ensure that every feature developed helps solve the business problems. This model also lays the groundwork for us to be able to drastically cut scope on projects in a quantitative manner, taking the emotions out of scoping decisions.

User Comments

2 comments
Keith Collyer's picture
Keith Collyer

While I completely agree with much of what Ms Beatty says, there are a few statements that are questionable, if not in fact in intent.

If you need 500 textual requirements to specify something, that is because there are 500 things to be specified. Even if you do this in a model, it is still 500. You get around this in models by structuring, hierarchy, etc. You do exactly the same thing in text. I would no more give someone a requirements document of 500 statements with no structure than I would give them a novel with all the words sorted into alphabetical order. You can maintain seven plus or minus two in text, and should strive to do so.

As for models making things easier for non-English speakers, well, up to a point. But a collection of graphics without words is meaningless, and if they have words, then those words had better be in some language.

I love the example of having to go out the front door to get to the yard. This is a clear case where a model (picture) would help. Of course, we have to be wary of imposing solutions when we start modelling, and that also applies for text. In both cases, one of the most important things to remember is to always ask "why?".

June 13, 2012 - 7:50am
Joy Beatty's picture
Joy Beatty

Thanks for the great questions and comments Keith! Let me try to respond to all of them!

Regarding using text to specify 500 things:

Sure, you can add structure to the text, for example a Requirements Mapping Model is a model to help you do that. But just saying you can group text into 7+/-2 groups is easier said than done. You have to find something to group them by, be it features, process flow steps, business objectives, etc. One of the concepts we talk about is how no one model is sufficient. The same is true if you organize 500 text statements - it's still not sufficient to fully analyze the solution and know you have no gaps. Finally, visual models are easier to look at than a list of 500 statements of text as well.

Regarding models not fully helping non-English speakers:

That's absolutely a fair statement. I think models only but help to supplement text, but do not fully address this issue alone.

Finally, your point about asking why:

Absolutely! I think this is very much the role of the person identifying requirements - to facilitate determining whether something is truly a requirement or if it is a solution that no one really "requires". We actually use some of the objectives models (Business Objectives Model, Objective Chains, and Requirements Mapping Matrix) in particular to help ensure that requirements truly help solve a business problem and add value to the business. If something isn't a requirement, but rather a piece of solution, it should become obvious in those models and can be cut from the requirements.

June 19, 2012 - 10:09pm

About the author

Heather Shanholtzer's picture Heather Shanholtzer

As Software Quality Engineering's director of publishing, Heather Shanholtzer oversees content generation and dissemination for Better Software magazine, TechWell.com, AgileConnection.com, CMCrossroads.com, and StickyMinds.com.

After nearly ten years of helping software professionals find their literary side, Heather is still excited to discover new voices and she relishes the opportunity to work with industry experts, practitioners, and craftspeople.

If you would like to write for one of our publications, email Heather at HShanholtzer@sqe.com.

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09