As product managers, we talk about creating the right solutions with our products. Understanding the very real problems our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.

Other than being “not as good,” how expensive is it to build the wrong product?

The Cost of Poor Quality

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality.  This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.”  The primary conclusion of that research is that ten dollars spent on fixing bugs:

• Costs and saves $10 when you catch (and fix) the bug during implementation.
• Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
• Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process.  Of course, be pragmatic about it - if the cost of testing exceeds the cost of bugs, don’t test.

This is not a solved problem, by any stretch, but the solutions and methods to solve this problem are well understood now.  In fact, a 2001 article by Barry Boehm and Victor Basili shows that in some cases, the labor costs to resolve bugs can be as low as 5:1 – when considering a subset of smaller systems, when using more “agile” processes.  That lowered ratio does not take into account the lost market opportunities and the costs of cleaning up collateral damage to your product – just the immediately realizable (and measurable) costs of resolution.

One very real problem, when talking about “bugs” is in defining what a “bug” is. And the definition of a bug is a matter of perspective. A developer can reasonably assert that “if it meets the spec it is not a bug, it is working as designed.” What if the spec is wrong? The developer may not be guilty, but collectively, your team screwed up. There’s a “bug” in the requirements.

What Is A Requirements Bug?

Now things are getting interesting.

If you wrote a requirement that you interpret as “A” and your developers interpret as “B” – you definitely have a bug – the team won’t build the right product. For each $1 you could spend making sure you have bug-free requirements, you could:

• Make sure you have a shared understanding of the documented requirements through active listening before development begins ($1). Following the Rules of Writing Requirements will help prevent this miscommunication.
• Wait until the engineering team is ready to demo their progress ($10). They will have to build it again, because they built the wrong stuff.
• Wait until development is complete and QA is validating that the code meets the spec ($100). This gets tricky if you are thinking “A”, the developers are thinking “B”, and QA is thinking “C.”
• In classic throw-it-over-the-wall mode, wait until the product is launched, and it is the wrong product ($1000). Assuming “A” was the right problem to solve, the cost of entering the market with a solution to “B”, leaving “A” unaddressed, is impressively high.

This gets interesting because the above assumes that “A” was the right problem to solve. What if “G” was the right problem to solve, and “A” was the wrong market problem? Even if everything (else) is working perfectly – you document requirements for “A”, the engineering team creates a marvelous “A” and it launches without implementation errors – you still fail, and incur the 1,000x cost of a failed product launch.

There is an even larger opportunity in front of your product team – a 1,000x payback on discovering and choosing to solve the right problems for your customers and markets.

• Would Palm still be independent if the Pre had solved a compelling problem?
• Why did Intuit have to buy Mint.com – could they have embraced the same customers with Quicken?
• What is Garmin going to do now that “free” GPS mapping and turn-by-turn directions are becoming ubiquitous? If it is “more of the same,” how much are they wasting?

Wrapping Up

I’m not aware of any studies that show that “requirements bugs” fit the same 1/10/100/1000 cost explosion model that “implementation bugs” exhibit. Emotionally, it “feels about right” to me – it passes my “sniff test.”

There are times when days of research would have been required to avoid or redirect a few hours of implementation effort on projects I’ve worked on. And I’ve seen man-years invested solving problems that didn’t involve much more research.

My intuition from products and teams I’ve worked with is that it probably averages out somewhere around 10x.

What does your gut (or your data – if you have some, post a link below!) tell you?

One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements.  His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”

What you call your requirements is less important than how you communicate them.

Labels

I’ve worked with a lot of companies that use different labels to describe their descriptions of the problems that need to be solved. This is not another article about requirements versus specification (specification = design constraint, btw).

If you’re not a long time reader who’s followed the debates and discussions on this topic in the past, check out these articles and comments, where we’ve had some great discussions on that topic – with particular thanks to Roger Cauvin for keeping the debate front and center.

• Requirements Versus Design: Which is Which and Why
• Requirements Docs – One Man’s Trash is…

The central theme is that the debate about “what versus why” centers around differences in people’s perspective on the problem.

This challenge is not really about that (but it makes for good background).  The complaint my colleague received was really a critique of the way that the why of a set of requests was communicated and labeled.

Actionable Goals

Companies have strategic goals (increase shareholder value, gain market share, etc) that serve to guide the investments and activities of the organization.  However, for the teams that are creating products, those goals are too vague to be actionable.  I guess this is where my set of labels comes in.  I don’t think the labeling of a goal as a goal (versus labeling it as a requirement) is abstractly important, however, when people value making a distinction, here’s how I do it.

A goal is something your business (or user) is trying to achieve.  It is too abstract to have a single valid solution approach.  Once your business stakeholder(s) decide on a strategy by which they will achieve that goal, the business will define requirements for the actionable project(s) that execute this strategy.  This is an ideation step that lives inside the “why” box from a business analyst’s perspective.  Here’s an example:

Warehouse Manager

You’re in the IT department of a large company.  You’ve been assigned to support the warehouse manager (or COO, or vice president of order fulfillment or whatever).  Your warehouse manager is responsible for procuring the products that your company sells, keeping inventory on hand, and delivering those products to customers when they have been purchased.

Your warehouse manager is measured (or promoted) based on her performance relative to the following:

• The time that a customer has to wait between placing an order and receiving the product.
• The cost impact of warehouse operations on the products.

Your warehouse manager focuses on these two metrics because of your company’s goals – provide good customer service, be profitable, and grow revenue.  Those abstract goals influence product pricing – it must be low enough to grow revenue in the target markets, and be high enough to be profitable.  Since market pressures drive pricing decisions, typically a profitability target will then create cost-reduction pressures (profitability also influences pricing decisions, selection of markets, positioning within that market, etc).  A customer service strategy can also include a “you get your product quickly” component – as it does in this example.

Your warehouse manager now comes to you and says “I have an initiative to lower costs.”

Is this a goal or is it a business requirement?

Ultimately, it doesn’t matter what you call it, but for you to actually do something you need to know more.  That’s why my approach is to call it a goal.  Your warehouse manager’s problem is to lower costs.  You need to decompose that problem to understand how you (and your team) can do something to help her achieve that goal.  The reason you have to do that is that you need a problem statement at the right level of abstraction.

In elicitation conversations with your warehouse manager, you learn that all of the costs of operating the warehouse are allocated to the different business units, who operate as profit centers.  The warehouse operates as a cost center.  The warehouse manager treats each business unit as a customer, and provides a service of “fulfilling product orders” in exchange for funds that cover the costs of operation.  The allocation of costs is done per product that appears in the warehouse.  Since allocation is per product, it could be something like $1.30 per product in “warehouse costs.”  There are multiple sources of those costs (that are then allocated per product), and there are multiple ways to approach reducing the cost per product.

Your warehouse manager develops a strategy (probably a “mini-strategy” from the company’s perspective) to lowering costs.  She rules out “sell more products” as an approach, because she can’t control that.  She also can not affect her fixed costs (rent, depreciation, labor).

Eventually you discover that there is another cost hidden in the provisioning model – products are purchased, they sit in the warehouse for a while, then they are sold and delivered, and eventually money is collected from customers to pay for the products.  Your company has to pay in advance for the products, and doesn’t get their money back until funds are collected from the customers.  That money is “tied up in inventory” when it could have been invested otherwise – so there is a cost associated with high inventory levels, that directly correlates with the amount of inventory in stock.  When a new version / revision of a product is introduced, your inventory may become obsolete (it is definitely devalued).  And since markets are moving targets, your prospects of selling a product change over time – a risk that you will not be able to sell all of your inventory.

At the end of the day, the amount of inventory you have on hand has a cost.  The more you have, the more it costs.  A rule of thumb I heard 20 years ago was that inventory costs could be as high as 1/3 of the cost of the product for each year you keep it around.  If that is true, that is something like 0.5% added cost for every week the product is in inventory.  Here’s something the warehouse manager can potentially control.

Currently, your warehouse manager has 8 weeks of inventory on hand (on average) for products, which allows her to ship quickly.  She realizes she is adding 4% to the cost of the product.  She decides that if she can cut those costs in half, she will be a heroine.

Her business requirement is to reduce inventory levels from 8 weeks (on average) to 4 weeks (on average).  She also has a constraint that no more than 1% of orders be delayed by more than a day (due to running out of inventory).

Now you have requirements that are unambiguous and measurable.

Conclusion

Don’t trap yourself in worrying about the labeling of goals / requirements, but if you have to work with someone who does find that really important, before you call it a requirement, make sure it is at the right level of abstraction.  And of course, make sure you follow the rules of writing requirements.

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Deep Dives

If you’re new to Tyner Blain, you may be surprised by the length of the articles here.  I joke that they are long because I don’t have time to edit.  Stewart Rogers jokes that they are long because I’m incapable of writing a short article.  If you’ve been here a while, you know what you’re in for.  If you’ve been here a long while, then you’re glad (like me) that I don’t write one per day any more.

Product Management is simultaneously a broad and deep discipline, requiring us to have a breadth of perspective combined with a depth of insight.  We then have to apply that in a market context, effectively navigating the political waters of our organizations.  Most of the articles here either try to skim the breadth of a range of related topics, or plumb the depths of a single topic.  Doing that in under a thousand words is pretty hard.  Most of the articles here also link to other articles, to try and provide even more depth and context, and encourage additional critical thinking.

One measure of the quality of the articles here is how often they stimulate readers to read further, or dive deeper into the topics.  While web analytics won’t allow us to measure how thought-provoking an article is, we can look to see how many people dive into the linked articles, versus how many people move on to something else.  We can measure the bounce rate of an article to see how often people leave a page without following any of the “tell me more” links.

Looking at ~170,000 page views at Tyner Blain in 2009, narrowed down to only those articles with at least 100 page views, here is the top-ten list of most engaging (or “least abandoned” if you’re a “cup is half empty” person) articles:

1. Use Case Series: Introduction: A collection of articles on the “traditional” forms of use cases – informal, formal, UML.
2. Agile Development of Use Cases: A dive into the dynamics and cadence of an agile process for developing use cases.
3. How Do You Manage Market Data?: A collection of articles exploring different market-immersion techniques in depth.
4. Scheduling Requirements Changes – Part 2: A focus on practical techniques for managing change with an agile development process.
5. Yesterday’s BPMN Post Was A Big Fat Lie: A mea culpa and clarification of interest to folks following the BPMN Series.
6. Everything I Needed To Know I Forgot in Kindergarten: Why asking why? is important.
7. Plan Your Next Sprint by ROI – Part 1: Prioritizing by Bang for the Buck, not just Bang.
8. Ten Common Mistakes of Going Agile: A collection of articles about common pitfalls encountered when adopting agile practices.
9. Perpetually Almost Finished Projects: Organizing a project with discrete deliverables and rolling-wave planning to avoid the “90% done, 90% remaining” problem.
10. How To Use Timeboxes for Scheduling Software Delivery: One of my personal favorites.  A rational approach to making trade-offs when your “perfect” plan has to change.

OK Stewart, that’s only 519 words.

There’s really only one way to travel down a waterfall – in a barrel.  A lot of people died this way, but some survived.  Software projects have been predominantly waterfall projects since the start of software projects.  And stakeholders rode down those projects, basically in a barrel.  The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.  Stakeholders in waterfall projects don’t know if they will succeed until the end.

An agile project is dependent upon tight interaction (and feedback) with stakeholders.

If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?

Expectations, Documentation, and Communication

The success of any project is dependent on setting and managing stakeholder expectations.  In Managing Stakeholder Goals, we talked about assuring that those goals are addressed by our requirements.  And in a later article, we proposed a way to balance the goals of different stakeholder groups when those goals are in opposition.  Those are good tools for making sure we are initially aligned with what we are hearing from stakeholders.

We need to also apply active listening techniques to assure that what we thought we heard is what the stakeholders thought they said.  One way to do that is to write use cases (or user stories) so that we can communicate the intent of the product back to the stakeholders.  This still primarily helps with kicking off a project, in the desired direction, with the correct goals.

There are many ways to document this initial intent of the project and stakeholder goals.  It is analogous to a stakeholder selecting a sturdy barrel and picking a good spot on the river bank to push off.  We’re well positioned to eventually succeed, assuming nothing changes.  After a harrowing fall, we find out how well we did.

A well-run waterfall project will provide status updates to the stakeholders along the way.  Imagine your stakeholder wearing one of those in-helmet headsets that NFL quarter backs use.  We publish effective status reports to let the stakeholder know what’s going on.  Like the falling barrel, however, a waterfall project has inertia.  The project, barring significant outside influence, will keep going in the direction it started.  Projects have change control boards to manage that change, but emotionally, I find that a formal change-approval process tends to inhibit change, rather than encourage it.  That barrel will keep falling.

Some project teams will try and do very heavyweight documentation to maximize the likelihood that the project will end up where it should.  The problem is, this heavyweight documentation only improves the chances that the project will end up where we used to think it should go.  It does not help us change the trajectory of the project as new insights are gained.  Just as responding to those changes provides a competitive advantage, ignoring those changes exposes a competitive weakness.  Someone will come along and exploit your weakness if you don’t respond to change.

From these dynamics, we can conclude that “big up-front requirements”, while better than “no requirements,” are actually a waste of energy and time, relative to an ongoing adaptation to change.  That adaptation to change, however, should also be documented.  It needs to be documented for two reasons – to manage expectations of stakeholders, and to keep the implementation team focused on creating the most valuable capabilities in your product.  As you get smarter about what is valuable, you need to apply that knowledge and change the path of the project.

This is where communication becomes critical with stakeholders too.  Especially the old-school barrel-riders.  They are used to being in the barrel, maybe with an occasional “looking good – you’re still falling straight down” message along the way.  They are not used to hearing “we’ve decided that gliding over the rocks is more valuable than falling – please extend your wings now” messages.  The shocked “what wings?!” response is what they immediately think.

Agile Expectations

An agile project will avoid the big up-front requirements, and gather just enough requirements for right now.  What your stakeholder might hear is “agile is magic – we don’t need detailed requirements.”  The real message is “agile is better – we don’t need details about the requirements yet.  But we will need them later.”

A given team needs the same amount of specificity in requirements to achieve the same result, regardless of project approach.  One team I worked with would not set the tab-order in a form to go from top to bottom if you didn’t specify that.  It simply didn’t occur to them.  Another team was very effective with “gather the following data in a form…” – and they would layout the form, manage tab order, add reasonable field validation, assure proper markup and support for screen readers (for visually impaired users), and implement a candidate error-message/feedback design for users.  The first team would never succeed without details, the second team would view those details as wasted effort by me to write them, and by them to read them.

I think most of the initial creators, proponents, and early adopters of agile processes are members of the second camp.  They designed agile to not require detailed documents, but to allow it when needed – because they acknowledged that some people need the details.  They were reacting to heavyweight processes that were designed to work for “any team” at the cost of slowing down the best teams.  Kent Beck told me once that when people tell him about the importance of testing, his response is “so, lack of testing burned you before?”  When people stressed the importance of gathering requirements, his response was “you’ve been burned by a disconnect with stakeholders.”

Enough is the operative word here.  You have to document enough.  You have to communicate enough.  You have to set expectations with your stakeholders that things will change.  And as those things change, you have to stay joined at the hip with your stakeholders to validate those changes.

While your team is responding to changes (based on feedback from stakeholders and the market and competition and implementation discoveries) with new plans, you have to feed that information back to the stakeholders.  It is a two-way communication.  And it needs to be a continual communication.

I joined a six month project once in the last month of the project.  Here’s a sanitized sequence of events describing what happened.

1. Initial vision for the project was defined and requirements defined and tied to goals and value.
2. The estimates came back and said “no way it will happen before the business-imposed deadline.”
3. The team said “let’s be agile” and chose a component of the vision to do first.  That component could be completed by the deadline, and stakeholder expectations were set – (a) do this visible thing first, “meet” the deadline, and then (b) regroup, re-prioritize, and then do the next thing next.
4. The team started developing the solution, and worked for 5 months.  After 5 months, someone concluded “we won’t finish by the deadline.”  A couple weeks later, the estimate was that the team still had between 1/3 and 1/2 of the work remaining to complete the first component of the vision.
5. In presumably unrelated events, all but 2 of the internal stakeholders left the company.  Literally.
6. When the CIO and president of the company engaged the project team, they weren’t thinking “we have an over-run on the first component of our vision” – they were thinking “not only is it not done, but what you’re trying to do is not the right thing.”
7. Project was stopped one week after the original deadline for the first component (which was not completed).

It may be that this was unavoidable, but one thing was clear – the “build the first thing first” expectation was not communicated effectively.  It didn’t help that the team did not track velocity, so it wasn’t until the end of the project when the “you’re going to hit the rocks” message was first heard by the stakeholder in the barrel.  Way too late to affect change.  For this and other reasons, I contend that the project was not agile.  It was a Chevrolet with a Ferrari sticker on it.

We can ignore the labeling of the process and focus on the lack of ongoing expectation management as the ultimate doom of the project.

Evolving Expectations

Patrick Masi had a couple great comments on our Simple Agile Model article.  Patrick pointed out a problem with simple documentation artifacts like this.  The early “here’s all we need right now” artifacts were insufficient to capture the full extent of what the stakeholders needed.  I’m not sure exactly where things broke down, but Patrick implied that the ongoing clarification with stakeholders was not happening.

This is a completely different manifestation, I suspect, of the exact same problem described above.  Thinking about Patrick’s comments is what got me heading down the whole “barrel rider” path in the first place.

I don’t believe I’ve worked with any stakeholders who would say “yes, ignore what we learned this year – it is more important to build last year’s product.”  I’ve definitely worked with stakeholders who did not have time to commit to the support of an agile project.  The ironic thing about agile projects is that they may do more requirements work through the course of the project than non-agile projects.  An agile project will respond to change.  That means some work is re-done.  It also means that some valueless work is avoided.  You can’t categorically say which influence is larger.

One possible source of the pain Patrick’s team felt is mis-set expectations of what is being delivered when.  Imagine developing a checkout-process for an eCommerce website.  The complete checkout process is too large for a single sprint, so you break it down into valuable atomic deliverables for each sprint:

1. Registered customers can buy any products, using previously saved billing / shipping info.
2. Individual product and “per order” discounting works and customers can use gift cards to pay for all or part of the order.
3. Anonymous customers can place orders (without accounts) and registered customers can modify billing and shipping information.
4. Orders can be placed as gifts (with gift receipts and wrapping services), and online call-center reps can interact with customers real-time to help with the process.

This is a nuanced message – basic checkout in sprint 1, with increasing capabilities in each sprint, until “complete checkout” is done in sprint 4.  That is a reasonable plan, but requires a more detailed conversation with stakeholders so that they know what is coming and when.  You don’t want someone freaking out after the 3rd sprint when they can’t place gift orders.

Another possibility is that the elicitation process before the third sprint (re-visiting checkout again with the same stakeholder) did not tease out that anonymous users must provide an email address (for order confirmation email, and to secretly create a “shadow account” for that customer).  All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front.  This is just incomplete discovery, but with delayed (and recurring) impacts.

In User Stories Applied, Mike Cohn stresses that the brevity of user stories is intentionally designed to facilitate (and I would add “dependent upon”) conversation.  I find it to be both a strength and a weakness of user stories.  It is strong because you can cover a lot of ground quickly (breadth) and capture a number of stories, much like the list above.  It is weak because the requirements documentation does not stand on its own – it requires conversation to fill in the details.  I’ve had some success using the “Verify that…” user acceptance tests as the method of documenting those details (depth), in conjunction with the brief, easily consumable stories.

You can write the stories quickly to decompose and schedule across sprints (revisiting the schedule as things change), and then write the verify statements as UAT for each sprint as it occurs.

Another benefit of the UAT is that it is explicit and cuts through the walls of the barrel for a stakeholder who “doesn’t get agile” as Patrick puts it.  “Here’s our lightweight multi-sprint plan – now lets define the specific acceptance criteria you need” is a pretty effective conversation.

Conclusion

You have to stay closely connected to your stakeholders – not just for messaging, managing, and changing the big-picture direction of the project, but also to drill down into the details at the last practical moment.

A business process is not just a sequence of steps.  A business process is a series of decisions and actions.  Some decisions are obvious and can be actively managed.  Some decisions are hidden, and until you discover them, you can’t manage or improve them.  Here is a real-world example of the discovery of a hidden enterprise decision.

Enterprise Decision Management

Over the past couple of years, I’ve collaborated with and become friends with James Taylor, an enterprise decision management guru.  He and Neil Raden wrote the book, Smart (Enough )Systems , you should get it if you don’t already have it.    It is sitting on my desk right now, and every time I pick it up I have to mark another page with a post-it note so I can find that good idea again later.  If you aren’t convinced, listen to this interview with James about their book.

James and I developed a presentation, Getting It Right: Rules and Requirements in Software last fall for the International Business Rules forum.  Below is a slideshare of a shortened version of the presentation, delivered to the Austin IIBA this spring.

A large portion of that talk was dedicated to discovering hidden business rules within use cases.  The reason we dedicated so much time to rules discovery is that the first step to managing decisions across your enterprise is to discover and isolate those decisions!  In this article, we will look at an example of a decision hidden within a simple business process.

A Simple Business Process

The following is a simple real-world business process.  The details of the steps in the process have been modified to clarify this example.

The process flow example above depicts an automated process that involves searching internal systems for an existing customer (record).  There are three possible outcomes from the search, shown above from left to right: no results are returned from the search, a single result is returned, or multiple results are returned.  When no results are returned, a new customer (record) is created, and the automated process continues.  When a single result is returned, that customer is used and the process continues.  When multiple results are returned, a new customer (record) is created and used, but the automated process is interrupted and a manual intervention is required before the process can continue.

This third path confused me when it was initially presented to me this way by the subject matter expert who explained the process to me. The business creates a new customer (record) even when multiple results are found because they don’t have time to determine which result is the right one, within the automated process.  They would rather create a duplicate customer (record), continue with the automated process, and clean up the mess later.  That’s much better than losing a sale (a very real risk because of delays due to manual oversight.

As part of this elicitation session, I applied a variation on active listening by talking to the diagram above (on a whiteboard) and enhancing it.

Impacts and Decisions

One technique that is effective in reaching agreement, generally, is to inspire the other person to “have your idea” so that it becomes their idea.  Once I understood the process above, I realized that there was an implicit decision in the process.  Instead of making the statement – “you have a hidden decision in your process” and then hoping the business stakeholder (also in the room) would care, I chose to start with the impact.  Presenting the impact of a hidden decision first might expose that decision and trigger acknowledgment of the hidden decision by the stakeholders.  The following diagram shows how I first modified the flow on the whiteboard.

The subject matter experts had told me that when there is a manual intervention in the otherwise automated process, the process is sometimes abandoned.  Imagine customers walking away from an online sale because (for some reason) the sale cannot be completed without an unexpected delay.  I represented this with the “Abandon Process?” decision in the flow.  This decision was never drawn before, because it is the customer’s decision, and it can not be controlled by the business.

I also pointed out that the business makes money only through the last step in the process, “Continue Automated Process.”  My goal was to accentuate that this abandonment decision has a very real value.  The stakeholder and subject matter experts agreed – this was something they had told me previously.  But they had never drawn it directly within their process.

As it turns out, this did not trigger any additional insights.  It did however, set the stage for describing the relevance of the hidden decision.

The Hidden Decision

After setting the stage, I updated the process flow diagram to expose the hidden decision.

The hidden decision is the decision of picking one of the many search results (top right corner of the diagram).  Your first response may be that the business is not picking any of the results.  My response is that choosing none of the provided results is a choice, just as picking any one of them would be.

This view of the process highlights that if the business could automatically choose a “best” result when searching returns multiple results, the business would avoid the risk of abandoned processes due to manual oversight.

With the current process, the business stakeholder acknowledged that the hidden business rule is ” pick none of the results 100% of the time”.  With current project schedules, there is nothing that can be done about that in time for the immediate software release (of the software that embodies this process).

Before our meeting was over, the business stakeholder added determination of future-state business rules to define the “how do we pick one?” decision to the deliverables for the next release.

A Smart (Enough) Decision

James and Neil (I would guess) will tell you that ideally, the decision (should we pick one, and which one should we pick) should be informed by the process.  A feedback loop can be created where we identify the customers (the people who might abandon the process), and determine statistically which ones are most likely to abandon the process.  For those people, it is especially important that we be able to “pick one” from a set of search results, thus completely avoiding the opportunity to abandon the process.  For those people who are unlikely to abandon the process, the “pick one” decision is less important.

If it were easy to “pick one”, we would consider changing the way search is handled to never return multiple results.  In this real world example, that is not an option (I’m intentionally not sharing the reasons, to avoid disclosing too much).  The only option in this case is for the business to respond intelligently (enough) when presented with multiple search results.

Conclusion

This process flow example has two primary outcomes – generate profits, or don’t generate profits.  The first modification of the process flow makes that possibility explicit.  That allows for an analysis to determine if there are any hidden decisions in the flow (there are) that impact the outcomes of the flow.  There may be other hidden decisions, but they do not impact the profitability of this process, so they were not explored.

Your strategy should be driven by the needs of the market.  Becoming market-driven is critical to intentional product success.  But it is not enough to understand your market.  You have to sustain your understanding, and take advantage of it, competitively.

Markets Evolve Over Time

We all acknowledge that markets are not completely static.  If they were, there would be no impetus for innovation.  Customers change, their environment changes, and the competitive landscape changes.  All of these changes cause a market to change.  Even if a given market were static, you don’t have perfect information about it.  Your understanding of that market increases over time.

The market is an abstract concept, and you have to make decisions about something tangible.  What is tangible is your understanding of the market.  And you make decisions based on your understanding of the market. You can visualize the market in a way that may cause you to rethink (or solidify) your approach to solving market problems.

In the chart above, we are showing that there is some amount of information (think of information as an understanding that we haven’t developed yet) about a market.  It represents the potential of what could be understood about the market.  Over time, the amount that can be understood increases.  Also note that there is already a non-zero amount of “understanding” at the start of the chart.  The market did not spontaneously spring forth from an oyster the moment you decided to look at it.

You Affect Your Markets

There is also an important dynamic to consider – you affect your markets by introducing solutions.

Whenever someone introduces an innovative solution to a market problem, the market changes.  Solving that problem exposes another problem.  Or it may introduce another problem.

• When cars replaced horses, they introduced atmospheric polution problems.  Before that, we only had to worry about horse waste.
• When airplanes solved the problem of traveling long distances in a short amount of time, more people began traveling further.  And those people discovered a need (desire) to stay connected (phone, internet, etc) while en-route.
• When it became convenient to carry music around with you on a portable player, the problem of carrying all of your music around with you was discovered / created.

You can argue that these problems were introduced because of innovative solutions, or that the problems were latent, and were only discovered because of the innovations.  It doesn’t matter.  What matters is that these problems were previously unaddressable, and now solutions to these problems have value.

Your Knowledge of Your Markets

Using the diagram above as a baseline of what can be known, and overlaying your knowledge looks like the following:

At the moment when you decide to understand a market, you don’t know anything about it.  Your knowledge rapidly approaches what “can be known”, and assuming you have perfect research, elicitation, and synthesis skills, you eventually understand all that can be understood about the needs of the market.

So much advice has been written about being market focused, that it is easy to think that this is all you need.  As soon as you understand “everything” you define requirements and start creating products.  Being market focused is extremely important.  But you have to sustain that focus.

Competition in Your Market

In the diagram above, you see the dynamics of your market.  You develop an understanding of your market, a competitor delivers an innovative solution to a problem, and you have to play catch-up.  Note – this is only talking about playing catch-up in your understanding of the market.  You also need to continue to develop new solutions for the market in order to capitalize on your understanding.

The next diagram shows what this will look like when there is active competition in the market.

The diagram above shows three disruptive events.  You innovate, someone else innovates, and you innovate again.  Each time someone else innovates, they have an edge on understanding the market.  They just solved a problem, uncovering new problems that can be solved, and you have to gain that knowledge too – it wasn’t available (or didn’t exist) previously.

Competitive Advantage

Each time you innovate, you establish a temporary competitive advantage.

When you introduce a novel solution to a problem, the market uncovers new problems.  Presumably, you have already thought about the next steps.  You have already engaged the market (through prototyping and other elicitation activities) to get feedback on your solution.  Hopefully, as part of that exercise, you’ve also explored “what’s next” and incorporated that into your plans.  This is the advantage you have created.  If you don’t explore “what’s next,” you waste that opportunity.

The opportunity won’t last forever.  Your competition will see your solution, talk to your customers, and otherwise explore “what’s next.”  It will take time, but they will catch up.  Over the long term, you benefit from exploiting a series of these opportunities.  Look at the iPod and the Zune.  Apple has delivered a series of disruptive changes, continually building on what they have learned.  Microsoft is playing catch-up with the Zune.  Each version of the Zune shares a lot of design cues and features with earlier iPods.  To Microsoft’s credit, they are trying to innovate too – like with the “squirt” technology that lets you share a song temporarily with another Zune user.  Either this is not a valuable problem, or the solution is not effective – because it has not taken off (in buzz, market share, or general clamoring for an iPod-based equivalent).

Fast Follower Competition

Some competitors intentionally act as second movers.  Instead of focusing their efforts on discovering problems or developing innovative solutions, they focus on playing catch-up very very well.

A fast-follower reduces (but does not eliminate) your temporary advantage.  At the same time, the fast follower creates their own advantage relative to every other competitor in the market.  This can be a very effective strategy, especially when there are multiple innovators in a single market.  The fast follower can follow the best ideas of each innovator, possibly even ending up with a better overall product than any of the innovators (who are slow followers of other companies).

Microsoft is clearly a follower of Mozilla when it comes to browsers.  The tabbed navigation concept introduced in Firefox was a game changer, at least for the tech-savvy who need to juggle multiple web pages at the same time.  Personally, I was thrilled to move from multiple Internet Explorer windows to a single Firefox window with multiple tabs.  IE7 has that capability now too.  I don’t know the browser market well enough to know if I would characterize Microsoft as a fast follower, but my guess is no.

After the post-World War 2 reconstruction in Japan, the Japanese automakers definitely acted as fast followers.  They did it with assistance from the US, and even moved past the US automakers by choosing to listen to Deming (a guru on efficiency and quality) instead of ignoring him like the US big 3 (automakers) did.  And it did indeed pay off for them – Toyota is poised to unseat GM as the number one automaker in the US for 2008.  There are certainly other factors at play, but the Japanese companies would never have had a chance if they had not been competitive in the first place.

Business Agility

Business agility is one of the hotter buzz-phrases these days.  The business-rules-automation market is thriving on the desire of businesses to become more agile.  Why does agility matter?  Because it can make you dramatically more competitive.

Business Agility is not the same as agile development!

Business Agility is a measure of the ability of a business to adapt to the changing needs of the market.  To adapt quickly, your company has to accomplish two things:

• Quickly identify and understand the changes in your market.
• Quickly deliver new and improved solutions that address the changing needs of your markets.

[How to quickly execute is covered in other articles in the business rules (including their impact on agility) and agile development categories on Tyner Blain.]

In the diagram above, you (the red curve on the top) are innovating repeatedly.  You are also adapting to the changes in your market from other innovations (and other sources of change, not shown).  You are practicing agile product management.  Your competition (the green curve on the bottom) is not.  As this trend continues, you see that your exploitable advantage becomes a sustained advantage.  You will have an ever-increasing advantage as you stay tapped into your market.  If you are executing (to deliver product) and communicating (to educate), you will be able to leverage your insights into a position of thought leadership.  [Note: "thought leader" is a title that can not be self-annointed, it has to be earned and perceived within your market / community.]

The end result is that you will be consistently aware of unserved market needs that you can serve before your competitors can.  That translates into increased demand for your products, which you can use to grow share, grow profits, etc.

That’s why business agility matters.  It isn’t cost reduction that is important, its top-line growth.

Agile Product Management

Staying tapped into your market like this is a strategic component of agile product management.  While continuously staying tapped-in (or Tuned-In), you regularly interact with your internal stakeholders to make agile development processes work.  Enthiosys has a great introduction to agile product management (free download with registration), if you’re getting frustrated with the many “empty presentations” about agile product management, then definitely check that one out – it has meat.  Relative to their onion, the topics in this article map to the portfolio and product layers.

If you aren’t already convinced of the value of a tight market focus, consider the following diagram, contrasting the impact of agile product management and traditional, waterfall product management.

• The red curve on the top (same as previous slides) represents an agile product manager staying tapped into her market.
• The grey curve in the middle represents a product manager staying tapped into the market, but not as tightly.
• The green curve on the bottom shows what happens when your organization is trapped in a waterfall delivery model.

The green curve, instead of reflecting understanding, reflects the understanding against which the team executes.  When you lock in or “freeze” the requirements, then begin a sequential development process, you stop taking advantage of market insights.  You essentially decouple your implementation team from the market – “we know enough already.”  So even though your product manager may be learning more (the grey curve), you aren’t taking advantage of that knowledge, so it is adds no value.

As an agile product manager, working with an agile implementation team, you will run circles around your waterfall competition.  Not only will you establish thought leadership, but you will be creating a distinctive competence for your company.  Your ability to understand the market, and quickly respond to changes in the market with valuable solutions will differentiate your company.

You also effectively change the dynamics of your sales over time.  Your accelerated insights allow you to release products (or capabilities) earlier.  Here’s a diagram from an earlier article on the ROI of agile that highlights the impact of this:

If we take the most conservative approach to modeling sales with an agile process, the graph would look like the following:

The sales volume curve is shifted to the left without changing its shape. The exact same growth curve applies to the product (this is the conservative assumption). The decline in sales continues to decline. The difference is that our previous time horizon (which remains fixed) now includes additional sales.

Product Life Cycle and the ROI of Agile Development

Agile Without Product Management

There are people who suggest that product management has no place in an agile environment.  Those people believe that markets can’t be understood until they are served.  They will argue that customers “don’t know what they want” based upon the feedback they get from prototypes.  Customers change their minds.  Yup.  But it isn’t that the customers don’t know what they want, nor is it that markets don’t have shared needs/problems/goals/requirements – they do.  Providing solutions to those problems drives next-level thinking, and the identification of new and different problems.

If you don’t have product management, you can only succeed through luck.  Throw stuff against the wall and see what sticks.  If something sticks, you win.  This is better than a waterfall model that ignores the market (for long periods of time where release plans are “set in stone”).  But it falls well short of driving a very efficient, adaptable implementation team directly towards identifiable market needs.

Great product management starts with an insightful understanding of your market.  Not just understanding a customer, and not even understanding all of your customers, but understanding your target market.  What works for you?

The Needs of The Many…

Mr. Spock was on the right track in Wrath of Khan, when he said “logic clearly dictates that the needs of the many outweigh the needs of the few.”  And Captain Kirk apparently took Pragmatic Marketing’s training, since he responded, “Or the one.”  [That was their original mantra circa 1982, before the more common "Your opinion, while interesting, is irrelevant."]

It isn’t just the crew of the starship Enterprise that believes an understanding of your target market is critical to product success.  I believe it, Pragmatic’s folks teach it, every good product manager I’ve run across embodies this belief.  [Note: Steve Yegge has a very intense article where (I think) he believes it too, but believes that it is futile to try and understand a market that doesn't include you.]

Tools and Techniques

We have a lot of articles here that help you communicate ‘an understanding of the market needs’ with your implementation team – where implementation equals development AND testing.

1. Documenting market needs (existing and new markets)
2. Making strategic decisions to address those needs
3. Engaging with stakeholders to validate needs
4. Prioritizing / planning product releases / roadmaps to align a release schedule with targeted needs
5. Engaging with stakeholders to clarify needs
6. Gathering and documenting requirements details and inter-dependencies
7. Validating feasibility / communication of intent with implementation (development and test) teams
8. Prototyping and eliciting user feedback

To name a few.  We’ve also written about several techniques you can use

• Gathering requirements via interviews
• Applying (and improving) your active listening skills
• Persona development, and differentiation of user goals from corporate goals (and from buyer goals)

The Missing Link

With all the current hub-bub about the bigfoot hoax (“I think I’m going to have a heart attack and die from not surprise!” – Iago, Aladdin), I couldn’t pass up this mug shot.

Collecting the customer-need data, with something more than anecdotal evidence, is tricky.  One of the premises of the agile movement is that you can’t, so don’t waste time trying.  I’ve always approached it by gathering anecdotal data, looking for root causes to create problem statements, and then working to map back to personas – dangerously extrapolating trends from a handful of datapoints.  And it seems to work.  But it doesn’t scale.  There must be a better way.

I had a great conversation with someone who asked the Austin PMM yahoo group what tools they used for tracking “customer feature requests.”  [Thanks again, btw, if you're reading this.]  The requestor was looking for something less than Feature Plan.  Just a mechanism for tracking feature requests.

Here’s the problem.  A feature request is to a market requirement as a gorilla suit in a block of ice is to a frozen captured Bigfoot.  Tracking and managing feature requests isn’t what we actually need to do.  Tracking and managing market requirements is what we need to do.

What Do You Do?

OK, so you manage a product that is sold by a sales team.  Those sales people, and account managers get feature requests all the time.  Or you have a SaaS product, and you built in a feedback mechanism.  A 2006 survey of SaaS vendors found that the ratio of feature requests to bug reports was on average, 5 to 1.  That’s a lot of feature requests.  Your process should look like the following:

1. Review feature requests.
2. Do something, possibly using some tool(s).
3. Determine market needs, prioritize markets (or needs), and update your roadmap…

Share what and how you do it.  Some questions I would ask if you were teaching me how:

• Assuming you map ‘features X, Y, and Z’ to an actual ‘requirement A’, how do you chunk those inputs – by persona, by market segment, something else?
• Do you have a way to automate any of the analysis (e.g. mapping a market need to a segment or persona)?
• If you had a magic wand, what would make that job easier?
• Any lessons-learned / advice for new product managers?
• How do you close the feedback loop with the customers who originally submitted all of those feature requests?

Thanks in advance for any responses!

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Product Success Is Not Easy

Saeed Khan wrote a critique recently, in On Product Management, of an article by Phil Meyers on the Tuned In blog. Phil’s article is an analysis of the pending re-organization at Starbucks, and the one quote that Saeed keyed in on was:

At the end of the day, its simple. Create a product or service that your buyers want to buy and the rest takes care of itself.

Saeed’s point is that it is not that easy. A lot of hard work goes into creating a successful product. And Saeed’s right.

Maybe Phil’s point is that the executive should not worry about the details, and trust in his team to do all the hard work. But he doesn’t really come out and say that, so we can’t really back him up on that front. Let’s give him the benefit of the doubt anyway. There’s another point that Phil makes that is potentially disturbing:

Looking at metrics like average same day sales and products per square foot lead you down some strange paths. Schultz even admitted as much in a letter from the board about a year ago in which he worried about the company ‘losing its core’.

Yes, abandoning your goals to pursue your metrics is bad. But don’t abandon your metrics to pursue your goals – unless all you want to do is get lucky.

You might argue that a company like Animoto got lucky when their product spread virally within Facebook and their user base jumped from 25,000 to 700,000 users. But if you listen to the interview that Amber MacArthur did with co-founder Brad Jefferson, you will realize that it was only when they tweaked their product offering – a response to empirical analysis of product adoption metrics – did their success explode. I would argue that they made their luck by being intentional.

Empirical Processes

When you can perfectly model your business analytically, you can measure the inputs and know (with certainty) the outputs. As a college engineering student, I learned this. Real world processes can never be perfectly modeled analytically. As a professional engineer, I learned this too. Real world processes are empirical. The secret to great engineering is to apply analytics to those empirical processes to create disruptive innovation, and combine it with empirical controls that help you statistically predict the likely outputs. The answer is simply that neither analytics nor empiricism alone can help you achieve greatness.

Business processes are also empirical in nature. Even when you can devise an analytical model for the behavior of an isolated system, you have to acknowledge that no real world system is isolated. You have to expect unexpected inputs into the system. As Saeed points out, you have to apply analyses to make smart decisions when developing your process (or business model, or product). And what Phil appears to discount is that you also need to apply empirical measurements to your process (or business or product) to control the expected results.

Creating Successful Products Intentionally

This article proposes that there are two paths to product success. The first path is simple. Cross your fingers, then get lucky. The second path is harder. Be intentional.

1. Identify your market (and therefore your customers and competition).
2. Identify their problems, and select the ones you will solve.
3. Create a product roadmap (aka a “plan”) to solve those problems.
4. Design and implement solutions to the most valuable problems.
5. Get feedback on your solutions.
6. Incorporate your feedback into your plan (step 3) and repeat.
7. Revisit your market (step 1) and the problems you choose to solve (step 2) and repeat.

Note: Step 7 should occasionally replace step 6, so that you stay focused on your market, and not just an out-of-date snapshot of what used to be important to your customers.

1. Identify Your Market

There are a lot of ways to pick a market to focus on. You can chase demographics – there sure will be a lot of retired people in the US thanks to the baby-boomers. You can go with what you know – years of paying attention to an industry presents ample opportunities to understand the market. You can create an entirely new – blue ocean – market by solving problems people don’t even realize they have until you offer a solution. Choosing a market is the subject of many books, not just an item in a list.

Once you choose a market, you need to segment the market into groups of people who share the same problems and who value solutions to those problems similarly. You can apply market research to improve your market segmentation.

2. Select The Problems You Will Solve

You use elicitation skills to identify the problems that your customers face. And when you have to address multiple market segments, you can prioritize the problems across those market segments.

3. Create a Product Roadmap

Once you’ve prioritized the problems you are going to solve, create a product roadmap. Your product roadmap should show the problems you are solving, and the order in which you will solve them. When you define sequencing, you also must define your approach to scheduling product releases.

4. Design and Implement Solutions

There are two keys to successful execution of the plan you built with your product roadmap. First – use rolling-wave planning to define near-term details and long term vagaries. Second – make sure you have continuous integration as a key component to managing quality throughout the process, instead of checking quality at the end (or even worse – ignoring quality).

5. Get Feedback on Your Solutions

This is half of why agile (when done right) works [Can you believe the discussion over the last year on this article is up to 27 comments?!]. Feedback is not just something you get when sharing a prototype with stakeholders. Feedback is also something you must get as part an incremental release methodology.

You can even measure the ROI of your designs, and incorporate feedback at the design level.

6. Incorporate Feedback Into Your Plan

There’s no point in gathering feedback if your organization and your process are organized to resist changes to the plan. Contrary to what the Standish Group’s CHAOS study has always implied [and we've made this implicit mistake too], release schedules are not the primary measure of project success. In a fantastic article at Dr. Dobb’s Journal, Scott Ambler points out that in his survey results, almost two thirds of professionals find that doing the right thing is more important than meeting a project schedule.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.

Do the right thing. If the right thing involves changing the schedule, that doesn’t make it wrong. What makes this work is the fact that you are getting feedback early and often. It is a risk mitigation strategy, designed to reduce the possibility that you will create an unsuccessful product. It is not a strategy designed to keep your project on schedule no matter how mis-aligned you are to your market.

7. Revisit What You Are Doing And Why

If step 6 is small-scale course correction, this is large-scale course correction. You may discover that solving a big problem for your customers exposes a new “biggest” problem that wasn’t there before. By revisiting step 2, you can choose to tackle or ignore those newly discovered problems.

You may also discover that by leveraging your investments to date, you dramatically improve the ROI of solving problems in another valuable market segment. This is because even if solutions to those problems have the same value, solutions to those problems now have much lower costs (for you). By revisiting step 1, you give yourself the opportunity to best manage your strategy, your resources, and your plans.

Conclusion

Product Success may have an element of luck, but you should never plan to hit the lottery. Be intentional in what you will do, and a good plan, executed well and adapting to change, will get you there.

We’re dedicating our “blogging time” this week to doing some infrastructure upgrades – we have to address some security issues on the site. Until we get through these changes, we’ll be recycling some of our existing content. For our recent readers, it will be “new to you” and for our long time readers, we appreciate your patience. Today we look at one of our better received articles on active listening.

Ten Supercharged Active Listening Skills To Make You More Successful [15 Mar 2007]

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Here are ten active listening skills that will help you, your customers and your team.

Our active listening article goes into details on the following 10 Active Listening Tips:

1. Acknowledging
2. Restating
3. Reflecting
4. Interpreting
5. Summarizing
6. Probing
7. Giving Feedback
8. Supporting
9. Checking Perceptions
10. Being Quiet
11. [Bonus] Extending

I hope you enjoy them and put them to good use – they really do make a difference

In this article, we build on our ability to represent straight forward business relationships in UML class diagrams. These relationships describe how two objects are related to each other. Representing relationships in class diagrams helps us to better understand the domain and helps us to uncover hidden requirements. Occasionally, we have to deal with more complex relationships that involve more than two objects to properly describe. This does not happen as frequently, but when it does, our modeling efforts are more likely to uncover overlooked requirements. In this article we learn how to describe relationships that involve more than two objects.

Catching Up On UML Class Diagrams

If you navigated to this page first, it is the fifth in a series introducing UML Class Diagrams for requirements elicitation.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: Discusses combining objects into collections and concepts.
4. Uncovering Requirements With UML Class Diagrams Part 4: Defines generalization (inheritance) and how to use it.
5. Uncovering Requirements With UML Class Diagrams Part 5: This article

Jump back to the other articles and get up to speed if you need. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work.

Understanding Details About The Relationship

One reason you may want to deal with more than two objects is obvious only after you change your way of thinking. So far, you’ve been thinking about objects (classes) and relationships (associations). Sometimes, when you need to understand the details of the relationship, you should think about the relationship as an object. It is both a relationship AND an object. And you draw this with an association class. We’ll walk through an example that illustrates the idea clearly, then we’ll look at the steps needed to create a relationship that is also an object.

Consider that you are gathering requirements to support software for tracking court cases – perhaps a mashup site that combines the latest public record lawsuits with entries from LinkedIn (my profile) and Crunchbase.

As part of your requirements gathering, you need to understand how these court cases work – so you start with a class diagram.

First – identify the main players in the lawsuits:

Both a plaintiff and a defendant are litigants, as they are involved in lawsuits.

That represents a simple relationship. A plaintiff sues one or more defendants. When you show this diagram to one of your stakeholders, she likes that you captured that one plaintiff can sue more than one defendants. She also likes that you can determine “who is the plaintiff suing” as well as “who is suing a given defendant.”

You point out one small problem – it is not clear if the plaintiff can only sue multiple defendants one-at-a-time, or if the plaintiff can sue multiple defendants in the same lawsuit. You get the answer (multiple defendants can be sued at the same time), and as you start to scratch your head about how to represent it, your stakeholder interrupts (they do that):

“We need to be able to show lawsuits with a “most recent” view, and a “largest” (in dollar amount) view on the main page of the site!” You realize that your diagram doesn’t work, and you make a note to yourself about the multiple-defendants issue.
You need a way to capture information about the suit. Suddenly, instead of a verb (sues), you need a noun (suit). You need to reason about the relationship. So you update your class diagram.

Your updated diagram now shows that a single plaintiff, in the context of a single suit, can sue multiple defendants. You also capture that you need to know the trial date and the dollar amount of the suit. You erase that note to yourself, because your diagram now clearly indicates that one lawsuit involves multiple defendants. You make another note to yourself that it is not clear if a plaintiff can be involved in more than one suit with the same defendants (he can). You’ll deal with that later.

What you’ve drawn is something (the suit) that is both a relationship and an object. In UML class diagrams, this is called an association class.

Creating An Association Class in a Visio UML Class Diagram

To create an association class, you use the Association Class shape in the Visio UML Static Structure stencil.

Drag the association class onto the page.

By now, you realize that you need to suppress the end names in the display. Right click on the shape and select “Shape Display Options…”:

And disable the display of the end names:

Now your shape will look like this:

You can manipulate the shape and its placement in two different ways. You can select and drag either line end (to connect to another shape in the diagram)

Or you can drag the “class” portion (the box) of the shape to wherever you want to place it. [Note: When you drag the class, it looks like you are disconnecting the line from the shapes and messing everything up. It is not happening. When you release the mouse button, the class will be where you put it, and the line will still be where it was before.] There is a dashed-line that connects the class (the box) to the association (the line). Visio automatically updates that for you – you never have to worry about it. In fact, if you don’t like it where it is, you can’t do anything about it either.

You could use the rotate-handle (the green circle on top) to rotate the box, but please don’t. Class diagrams, by convention, are drawn with everything aligned with the page. To get the line on top, just drag the line ends above the shape (or drag the shape below the line ends).

You use the same rules for showing directions with an association class that you do with a regular association. If the business needs to think in one direction – “Who has the plaintiff sued?” then show that arrow. If the business wants to think in the other direction – “Who has sued a particular defendant?” then show the opposite arrow too.

Even More Complex Relationships

The cool shape above lets you draw a three-way relationship. It is most handy when you need to understand something about the relationship itself – treating the relationship as a noun instead of a verb. You can create relationships in UML class diagrams that involve more than three objects. These are called N-Ary Associations. The “N-Ary” part is geek-speak for “binary, trinary, quaternary, etc” – any number is valid.

Earlier, we glossed over one question – “Can a single plaintiff, related to multiple defendants in the context of a single suit, also be related to those defendants by another suit?” You can use an n-ary association to depict this.

In the Visio UML Static Structure stencil, select the N-Ary Link shape.

Drag it onto the page

It looks a bit like a decision diamond from a flow chart, but with handles. Drag it to where you want it to be in your diagram and then start connecting the line ends to the related classes.

After you’ve connected the ends (or before, but after is easier), double click on the shape to bring up the properties dialog.

You’ll see three “Link Ends” – just rename them to show the multiplicity of the connections. You will end up with a final diagram that shows:

One plaintiff can sue one or more defendants in one or more suits. You could (and I will) argue that this is even more ambiguous than the previous diagram.

• Who does the suing? Is it the plaintiff, the defendant, or the suit itself?
• Are they even suing? Perhaps the relationship is just “they are all in the same room at the same time.”
• When a plaintiff sues multiple defendants, is it one defendant per suit, with multiple suits? Can it be? Must it be?

Personally, I never use an n-ary association when modeling complex relationships. I much prefer the association class.

A Simpler But Busier Alternative UML Class Diagram

You never have to use an association class. You can always represent the situation with three classes and two associations as the following diagram shows:

Instead of an association class, you create a single class (suit) that represents the noun, and you break up the single association (suing) into two association (attacks with, defends against). In some ways, this is more precise than using an association class. You can tell from the diagram above that

• A single plaintiff attacks with one or more lawsuits.
• One or more defendants defend against a single lawsuit. Therefore, there could be two suits between the same plaintiff and the same defendants at the same time.

What you lose is a notion that the suit establishes the context of the relationship between the plaintiff and the defendant(s). Ultimately it is a judgment call about which form to use (the association class or the normal class with two associations). If understanding the specific multiplicity data is important, you should use the two-association diagram. If it is not, I personally feel that the association class provides clarifying context.

Next Up

In the first five parts of this series we’ve covered

• Using classes to represent business objects and entities.
• Using simple associations (relationships) to demonstrate how objects are dependent or how they relate to one another.
• Using composition and aggregation to show how objects are treated when grouped together.
• Using generalization and inheritance hierarchies to show how similar, related objects can behave differently.
• Using association classes and n-ary associations to express more complex relationships.

If you understand all of these concepts, you are ready to create UML class diagrams of the business domain and concepts. You are ready to use these tools to uncover otherwise hidden requirements. If you want to study some of the more arcane details around UML class diagrams, you should be ready to read Scott Ambler’s articles.

• UML 2 Class Diagrams – an explanation, in detail, of how and what and why to draw things a particular way
• UML 2 Class Diagram Guidelines – advice on how to make your diagrams consumable and appealing

Just keep in mind that Scott jumps right into complex topics (which you are now ready for), and also includes tips and advice that are only relevant when creating class diagrams of implementation designs. Just filter that stuff out. Or come up with a way to leverage those details to the modeling of business ideas, and share them here.

Thanks for following along this far, and if you have any questions or would like to see us cover anything else about using UML class diagrams for uncovering requirements, add a comment below.

The hardest part of gathering requirements effectively is uncovering the requirements that people don’t immediately tell you. You have to ask the right questions. And one of the best ways to find the right questions to build a class diagram of the business domain. This article continues our introduction to class diagrams.

Catching Up on UML Class Diagrams

If you’ve found this article first, there are three that came before it.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: Discusses combining objects into collections and concepts.
4. Uncovering Requirements With UML Class Diagrams Part 4: This article.

So jump back to the other articles and get up to speed. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work.

Generalization: A Dog Is A Mammal

We’ve looked at objects and relationships between them. We’ve looked at the special association relationships that give us aggregation and composition. Generalization is another form of relationship, but not one that tells us how different objects interact – one that helps us better describe objects. We could talk about a dog, and create an object that represents a dog. But what if we also wanted to talk about a horse? They have some things in common, because they are both mammals. Generalization allows us to talk about mammals too. That’s fine, but let’s use a business example instead of a classroom example.

The key to this generalization relationship is to think about the phrase “is a.” A dog is a mammal. Don’t confuse this with combining objects into an aggregation. A pack has a bunch of dogs in it. A zoo has a bunch of mammals (and other animals) in it. But a dog is not a specialized pack. It is a specialized mammal.

Remember “…is a…”

This relationship carries special meaning – all things (characteristics, behaviors, etc) that are true about the general object are true about the specialized object. But all things about the specialized object are not necessarily true about the general object.

• All mammals have hair, therefore all dogs have hair.
• All mammals have live babies (they do not eggs), therefore all dogs have live babies (puppies).
• All dogs are pack animals, but all mammals are not (elephants are, but shrews are not).

Technical folks usually call this inheritance – the specialized object inherits all of the properties and behavior of the generalized object. Inherit is almost as good of a word to use as generalizes. Where inheritance really helps as a term is it allows us to think in terms of parents and children objects. The mammal is a parent and the dog is a child of mammal. The terms parent and child make it much less cumbersome to talk about generalization relationships.

Understanding Insurance Policies With Generalization

Consider that you’re working on a project for a life insurance company. In your first conversation with a subject matter expert, you hear five different terms for describing insurance policies. At a convenient pause, you stop the interview, walk over to a white board, and draw class diagram objects for each of the five items.

You ask your expert how all these objects are related to each other. She explains that all life insurance policies are either term policies (they last for a fixed term of time) or permanent policies (they last for as long as the premiums are paid).

You recognize this as a generalization relationship.

• Every Term Policy is a Life Insurance Policy
• Every Permanent Policy is a Life Insurance Policy

Your SME also informs you that permanent policies, as a form of investment, are always one of two special types – whole life policies and variable insurance policies. Whole life policies have a fixed return for a fixed premium. Variable policies invest your premium in market securities, and the amount of money available at the time of payment depends upon the performance of the policy. More generalization relationships.

• Every Whole Life Policy is a Permanent Policy
• Every Variable Insurance Policy is a Permanent Policy*

[*As far as I know. If there is such a thing as a variable term life insurance policy, my apologies - just assume that your company does not sell one.]

You draw the generalization relationships on the white board, and you move forward in eliciting requirements. This drawing is known as a hierarchy.

Drawing Generalization Relationships in Visio

You use the generalization shape in visio to create generalization (inheritance) relationships between classes in your class diagram.

As you drag it onto the page, it looks like the following:

The shape is an arrow with a closed (but not filled) arrowhead on one end. You connect that arrowhead to the parent class – the more-general of the two. The tail is connected to the child class – the more-specific of the two.

Once you draw all the relationships, your Visio class diagram will look like the following:

Now you’re prepared to understand the other information your subject matter experts are sharing, in the context by which the business is describing their requirements.

This hierarchy makes sense, but it seems to be completely different from all the other class diagram stuff we’ve done. How can you combine these different views? It is the combination of them that really brings out the value.

Relationships, Classes, and Inheritance

The first thing to realize is that association relationships, composition relationships, and inheritance relationships can all happily co-exist within the same UML class diagram. In fact, much of the insight you gain into uncovering requirements only comes when you combine these different analyses within a diagram.

The structure we looked at above provides a good description of how a company manages the policies that they write. What you are likely to want to document are requirements around selling those policies. Each time a policy is sold, an agreement is created. That agreement is a copy of the policy sold (at the time of selling it), with the insured person’s name filled in. You can imagine the policy to be a form with blanks that need to be filled in. Each time a policy is sold, someone makes a copy of the “official” policy, fills in the blanks – name of insured, policy dates, etc – and then it becomes an agreement.

Introducing the term agreement allows the business to treat the two ideas separately. A policy defines the agreements that can be sold at any given time. An agreement is one policy, as sold to an insured person (customer).

[click for larger diagram

As you can see from the diagram, we have the same hierarchy for describing insurance policies. We've added some other objects and relationships.

Objects

• Agreement. A policy written by an agent for an insured person. The agreement is written in a specific state.
• Agent. An agent is someone who sells insurance policies (agreements). The agent lives in a specific state.
• Insured Person. Someone who purchases an insurance policy (agreement). The person lives in a specific state.
• Insurance License. An official document that allows someone to sell policies in a specific state for a period of time.
• NASD License. A special license from the National Association of Securities Dealers that allows someone to sell variable insurance policies.

Relationships

• A life insurance policy is used as a template for an agreement.
• An agreement is written by an agent.
• An agreement is held by an insured person
• An agent holds one or more insurance licenses.

From the diagram, we can understand that an agent sells an agreement to an insured person. That agreement is based on a life insurance policy. The agent holds at least one license to sell insurance.

Notice the relationship between the agreement class and the life insurance policy class. The life insurance policy is at the top of an inheritance hierarchy. Each other type of insurance policy (term, whole life, etc) is just a specialization of life insurance policy. The diagram depicts that the agreement can be one of any of the different types of insurance policy. And therefore, an agent can sell any of the types, and an insured person can hold an agreement of any of the types of insurance policy.

When reviewing these relationships, you discover that this is an overly simplified representation. You capture the additional information and update your diagram.

More Complex Class Diagram

As part of reviewing the diagram, you discover that variable insurance policies are treated very differently than other insurance policies.

• An agent must have a different type of license (an NASD) license to sell variable insurance. Because of this, the business treats these agents as being special - they are called "Broker / Agents" and are subject to many different internal policies and procedures. Some of those policies represent enforcement of legal regulations, and others are internal policies.
• A broker / agent can sell both variable and fixed (non-variable) insurance policies.
• A variable policy is a combination of a fixed policy and an investment. As such, the business thinks about those customers as investors, and not just insured people. This distinction is really only relevant to sales people and marketing - who will use different approaches to sell to people who want investments.

You update your class diagram to look like the following:

[click for larger diagram]

This diagram is much more complicated.

• We enhanced the hierarchy for insurance licenses to reflect that broker/agents need a different type of license (NASD license) to sell insurance.
• An insured person holds a fixed agreement, where an investor holds a variable agreement.
• An agent can only write a fixed agreement, where a broker/agent can write any type of agreement (fixed or variable).

The diagram is almost too complex to absorb within a UML tutorial. If you were writing these requirements, and did not create a similar diagram, you would be in trouble. In the best case, you would end up with an implementation that met all the requirements, but did not use a good implementation design (due to lack of context). It is more likely that either you would miss some requirements, or your implementation or test team would miss some.

The diagrams that have had the most impact, in our experience, are diagrams that have a similar level of complexity.

Next Up

In the first four parts of this series we’ve covered

• Using classes to represent business objects and entities.
• Using simple associations (relationships) to demonstrate how objects are dependent or how they relate to one another.
• Using composition and aggregation to show how objects are treated when grouped together.
• Using generalization and inheritance hierarchies to show how similar, related objects can behave differently.

All of the tools you’ve learned so far deal with binary associations – an agent sells a policy, a book club reviews books. In the next article, we will look at relationships that involve more than two classes.

Uncovering Requirements With UML Class Diagrams Part 5: Complex Relationships

UML Class Diagrams are very effective at uncovering requirements. They give us insight into how the business thinks about objects and their relationships. And from that understanding, we think to ask questions we might otherwise overlook. In this part of our series, we look at how to represent when one object is made up of other objects. The two types of relationships we explore are composition and aggregation.

Catching Up on UML Class Diagrams

If you’ve found this article first, there are two that came before it.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: This article.

So jump back to the other articles and get up to speed. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work. UML class diagrams can be used for both, and most tutorials are written for programmers doing design work. This one is written for people who work with requirements.

Relationships of Combination

When a collection of bananas are combined, we call them a bunch. Crows exist in a murder, and lions in a pride. Teams are made up of players. It is a deck of cards. An order is a collection of line items. We have always had the notions of both individual items (or people) and combinations existing as an interesting entity. Sometimes we treat them the same – you can eat a banana or a bunch. You can feed a lion or a pride. Sometimes, we deal with the combined entity. You shuffle a deck, you fulfill an order.

Understanding this type of relationship can be very important to understanding what your customer (aka “the business”) needs. You are describing the mental model of the business. Business people think about fulfilling an order, not “fulfilling all of the items on the order.” A user may want to archive the history (all the previous versions) of a file, or she may just want to keep the most recent version. Thinking about these concepts helps you uncover the requirements.

There are two jargon terms – aggregation and composition – that apply when we talk about multiple things as one combined thing. They have precise meanings.

• Composition – when one item is part of another item, the relationship is composition.
• Aggregation – when one item can be included in another item, the relationship is aggregation.

If that doesn’t make sense, this “formal” distinction will really mess you up:

Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts.

Scott Ambler

Here are some examples that may simplify things:

Composition

• A building is composed of one or more rooms (a room is part of a building)
• A plane is composed of a fuselage, one or more engines, and one or more wings (a wing is part of a plane)
• An order is composed of one or more line items (a line item is part of an order)

Aggregation

• A team includes more than one players
• A library includes more than one books
• A market includes one or more customers

Ambler’s definition makes sense, when you think about these examples. You could shut down a library without destroying the books – likewise, you could kick one of the players off a team and the team would still exist. That’s what he means by coincident lifetimes.

Drawing a Composition Relationship With Visio

To draw a composition relationship in Visio, you use the composition shape from the UML Static Structure stencil.

When you first drop this shape on the page to connect two classes, it looks like the following:

There is a solid black diamond on one end (the first end) and nothing on the other end. In UML, this is stating that an order is composed of line items. By default, Visio shows the “end names” as it did with the association shape. You can fix it the same way we did before. Right click on the line and select shape display options.

Then make the same modification we did before, to show the shape name and suppress the display of the “end names.”

Now you have the kind of display you want. Note the check marks at the bottom of the dialog – you only have to make this change once per class diagram. Unfortunately, Visio does not remember this change, so you have to do it once for every diagram (every new file, and every new tab within the same file). Annoying.

Double click on the line to update the information about this composition relationship.

You will end up with the following (we re-arranged it to make it easier to read):

Drawing an Aggregation Relationship With Visio

Drawing an aggregation relationship is almost the same as a composition relationship with Visio – it just requires an additional step.

In this example, a book club reviews books. You want to show that the book club includes members. Note – members can come and go without causing the book club to be disbanded. You can think of aggregation as membership in a combined entity.

First, use the composition shape again (the same as above), and update the properties as we just did. You will see

The Visio stencil does not include a special aggregation shape, so we will cheat by changing the formatting of the composition shape. Select (in the menu at the top of the window) format > line…

And in the dialog, you will change the display of the “Begin” end-point.

Aggregation is represented in UML Class Diagrams with the same diamond-shape as composition. The difference is that the shape is “empty” instead of being a solid black diamond. Click “Apply” and “OK” and you end up with what you want:

Note: If you change the format of the composition line first, and then change the properties (“Joins” etc), Visio will reset the line end to be a solid diamond again. It resets. Annoying. If you copy an aggregation line, the copy reverts to the solid diamond again too. Very annoying.

Next Up

Up to this point, you’ve learned how to define classes (and attributes), simple relationships (A book club reviews books, and a member reads books), and combinations of items as compositions and aggregations (an order is composed of line items, and a book club aggregates members).

Next, we will cover hierarchies, usually thought of as “Is a” relationships. A Sales Rep is an employee, and an employee is a person.

Uncovering Requirements With UML Class Diagrams Part 4: Generalization (inheritance) and how to use it.

We continue our exploration of UML Class Diagrams with this article that explores how to represent basic business relationships in a class diagram. Drawing these relationships can dramatically clarify requirements documents. Using a class diagram to supplement other requirements documents provides for a centralized reference that enables a shared understanding of the problem domain. That understanding prevents mistakes in interpreting requirements.

Getting Up To Speed

We started this discussion of class diagrams last week. In it, we presented the notion of a class. When a stakeholder cares about a concept, idea, or thing, we represent it as a class.

The business cares about customers. And customers have addresses and credit ratings.

Classes and Attributes

How do you know when something should be an attribute, and not another class? In our example above, think about Customer and Address and Credit Rating. One way to make a distinction is to say that if an attribute has other attributes, it should be a class. A credit rating is just a number. But an address is a compound object made up of multiple attributes.

An address can have multiple lines of street address information, as well as city, state, zip code and country information. That is a good indicator that it is likely to be a class of its own. If we were to represent an address as attributes of a customer, we would have to include each of the “sub attributes” as a separate attribute of customer. That feels bad, from a design standpoint.

The distinction is one of design, but generally speaking, if the concept stands on its own, it should be its own class. An address is related to the customer. A credit rating is a property of a customer.

Simple Relationships

How do we show a relationship between a customer and an address?

The customer receives bills at an address. That is the relationship between the customer and the address. The business wants to know where to send bills for the customer. We’ll talk more about relationships in a bit. First, we’ll cover the steps in visio for creating the relationship shown above.

Showing Relationships With Visio’s UML Stencil

The relationship shown above is called a binary association, because it shows the association between two classes. There is an object (Visio calls it a “master shape”) in the Static Structure template for creating these, aptly named binary association.

Drag that onto the page, and connect the two classes for which you wish to show a relationship.

The default display properties for the binary association shape cause the shape to display some weird information – called the “end names” of the relationship. The shape also does not give us the arrowhead, or the name of the relationship, Receives Bills At. Right click on the line and select “Shape Display Options…”

Remember this, you will use the dialog that pops up a lot.

We want to do three things for now:

1. Check “Name” so that the name of the relationship (Receives Bills At) will show up.
2. Un-check “First end name” so that it is hidden.
3. Un-check “Second end name” so that it is hidden too.

Click OK, and the shape will have updated to look like the following:

The name is defaulted (to “Association1″), and no arrowheads are showing up. We also have two asterisks, an no “1.” We need to update the shape’s properties (not display properties) to include that information. Double click on the line and you will see the following dialog (Fill it out to match):

[click for full size view]

• Name: Enter “Receives Bills At.” for the name. Note – some people prefer mixed case or lower-case. Any approach is fine, just be consistent. The name is the name of the relationship and it indicates the meaning of the relationship.
• Name Reading Direction: forward and backward will confuse you. It confused me for years. This is what determines where the small solid triangle shows up to indicate the direction of reading. Customer Receives Bills At Address, instead of Address Receives Bills At Customer. One day, I realized that this field only controls if the triangle shows up before or after the text. With up-down relationships, I still get confused. Use the standard of top-to-down is the same as left-to-right, and you’ll eventually get used to it.
• Association Ends: This section shows the two ends as rows in a table – with five columns describing each end. For now, we will only focus on the last two columns. This is another area for confusion – the first row represents the top-left end of the line (when you drag it onto the page) and the second row represents the bottom-right end of the line. You can move the ends of the line around after you place it on the page, and the rows in this table will maintain their original associations. Try not to get frustrated when you get these backwards. I still make that mistake all the time, after creating a few hundred diagrams over the course of a decade. Think of the top-left end of the line as the “first” end, and the bottom-right as the “second.” Then when you move it around, you might remember which is which. If you get in the habit of attaching the line first to the “from” class, and then to the “to” class, you will start to get the hang of it.
• Multiplicity: Multiplicity allows you to specify how many objects can be on either end of the relationship. In our example, a customer can receive bills at only one address, but multiple customers could share the same address. My stepdaughter and I each have iTunes accounts. We are two separate customers, but we have the same address. Since I attached the “first” end to the Customer class, there is an asterisk in the first row, and a “1″ in the second row. [*See below for explanations]
• IsNavigable: Either the UI designers for Visio expected all of their users to be Java programmers, or they ran out of space. “IsNavigable” can be translated into “Should the arrow be shown on this end of the line?” Since, as a business, we care about the address at which a customer receives bills, we show the arrow for the “second” end. But we don’t anticipate (commonly) needing to determine all of the customers that receive bills at a particular address – so we don’t show the arrow in the opposite direction.

Types of Multiplicity

There are a few different concepts that can be displayed for multiplicity. Your developer co-workers and math geeks will call this cardinality. That’s probably even the better term to use. But since Visio chose multiplicity, so will we, at least for this article.

• 1: Exactly one object of this type is involved in the relationship. A customer has one billing address.
• *: Any number of objects (or none at all) are involved in the relationship. Any number of customers can receive bills at a given address.
• 0..1: Zero or one objects are involved in the relationship. A driver may or may not have a drivers license.
• 0..*: Same as “*”
• 1..1: Same as “1″
• 1..*: Any number of objects (as long as there is at least one) may be involved in the relationship. A shipment can include any number of items, and it must include at least one item.

This brings us back to our original relationship example.

The small class diagram above represents the following:

• A customer has a credit rating.
• An address includes three fields for “street information”, city, state/province/county, zip or postal code, and country fields.
• A customer receives bills at exactly one address.
• Any number of customers (or none at all) can receive bills at any one address.

Simple Relationships Revisited

With the mechanics of using Visio out of the way, we can show some examples of some other simple relationships.

• A sales rep sells products to any number of customers.
• Any number of customers purchase products from a sales rep.

Both examples above depict the same relationship, and either is acceptable. What would be bad would be to use the passive voice and say “any number of customers are sold products by a sales rep.” This is the same advice that applies when writing use case names – don’t use passive voice.

There are opportunities to misread requirements when relying solely on UML. Imagine we had a requirement that any customer always make purchases from a single sales rep. The goal is to provide a sense of relationship for that customer. Both of the diagrams above technically express that requirement. If a customer could have more than one sales rep, we would show “1..*” instead of “1″ for the multiplicity on the sales rep side of the relationship.

Someone reading the examples above could reasonably be unsure about the intended requirement. Is there a single sales rep for a given transaction? Is there a single sales rep for a given customer, regardless of the number of transactions? Only the latter interpretation is technically accurate – but either is a reasonable interpretation. Professor Daniel Berry, author of The Ambiguity Handbook [The actual title is From Contract Drafting to Software Specification: Linguistic Sources of Ambiguity, A Handbook], explained in a lecture last year at the 2007 IBRF that UML stands for Undefined Modeling Language. This is a good example of that.

By including the diagram within, or as a reference from, a requirements document, you provide both the context and the graphical clarity needed to understand the intent. Don’t rely solely on the diagram!

A product has a price. One product has one price. This relationship is almost too simple, making it difficult to come up with a good name for the relationship. “A product has a price of price” is awkward.

“A product will be sold for a price” is better. If we were limited to “has a”, we could make an argument that the price should be an attribute. But the price may have properties (like currency used), or may be calculated dynamically based on coupons or contracts.

Using action verbs will help with both understanding and elicitation. If you are reviewing the diagram above with a stakeholder, you are not likely to get any discussion from “product has a price” – of course it does. But if you show “product will be sold for a price” you will immediately trigger responses. Especially if you ask “how do you know what price to sell the product for?” Use active verbs with explicit meanings instead of “weasel words” like “has a.”

This is a very clear way to indicate that from a business perspective, the customer has a billing address and a shipping address, and no reason to expect them to be the same. If you have to worry about export compliance, you may add an “end use” address – the location where the product will ultimately be used. Imagine how messy that would be if we had used attributes instead of classes!

As messy as that would be, this highlights why we use classes. Think about some other business relationships we have not drawn. Credit card authorization uses the billing address. Taxes may be* calculated based upon the billing address or the shipping address. Shipping charges would be based upon the shipping address. [*I believe that for physical goods, the shipping address is used, and for electronic downloads, the billing address is used.]
There is no limit to the number of entities and relationships that can be represented in a class diagram. As a guideline, think about usability. Are you producing class diagrams as part of exploring specific areas of the business? Are you making sure that a complex set of relationships do not get oversimplified? Are you “boiling the ocean” with a giant encyclopedia of the business domain? If you are – why?

Summary So Far

So far, we have discussed classes as a means to represent entities from a business perspective. We’ve also introduced some simple relationships. Those relationships show how pairs of entities interact or inter-relate. We’ve shown how to make the relationships directional and bidirectional – depending on which way(s) the business needs to look at things. And we’ve covered multiplicity – how many of each type of object are involved in the relationship.

There is still a fair amount of ground to cover between here and Scott Ambler’s comprehensive reference. If any of the concepts so far are unclear, or if there’s something you want to make sure we cover – add a comment!

Next Up

In our next article on using UML Class Diagrams for unearthing requirements, we will look at more complex relationships.

Uncovering Requirements With UML Class Diagrams Part 3: Combining objects into collections and concepts.

UML Class Diagrams can be used not only for documenting software design, but for documenting software requirements. One of the challenges in writing clear, unambiguous requirements is being precise about what a particular word means. This is especially true with symbolic terms like “quote” or “customer” – where everyone knows what they mean – but they mean different things to different people.

Why Create UML Class Diagrams for Requirements?

One of the first articles we wrote in 2005 provides a very simple class diagram example, and an explanation of why you should use class diagrams to clarify your documents.

In prose, we could also capture the same information as follows:

1. The system shall include a representation of customer orders.
2. Each order will have a single associated customer, and each customer can have multiple orders. Note that a customer is not required to have any orders.
3. Each order will have at least one, and possibly multiple line items. Each line item is uniquely associated with a single order.
4. Each line item represents a single product. Note that a product is not required to be represented in a line item. A product can be represented in multiple line items (even within the same quote).

OOA is compellingly powerful as a descriptive tool – it took less time to draw the diagram, and it can be easier to read than the prose.

A Picture is Worth A Thousand Requirements

UML class diagrams, in addition to being potent for communication, can also help with requirements discovery. They provide a clarity and explicitness of understanding that helps you gain insight into the topics being explored.

Getting Started or Getting Refreshed

If you already know UML, or generally know how to draw UML 2 Class Diagrams, you can “test out” of this article, and go to the best, most thorough explanations we know of, courtesy of Scott Ambler.

• UML 2 Class Diagrams – an explanation, in detail, of how and what and why to draw things a particular way
• UML 2 Class Diagram Guidelines – advice on how to make your diagrams consumable and appealing

If your eyes glazed over, that’s ok. There is a lot to absorb. There are a lot of advanced concepts that can be represented in class diagrams, and Scott provides explanations and examples of how to do most of them. If you are new to modeling with UML, or are only interested in what you need to know to document requirements, those articles may be too advanced for now. We’ll try and close the gap. Keep those links handy, both for reference, and for deeper explanations than we cover here. If Ambler’s articles are written to help you be a master craftsman, we want to help you become a journeyman first.

Class diagrams are incredibly powerful tools for anyone doing requirements work. I never wrote about them before, because Ambler already did. And he didn’t leave me wanting more, so I never knew what to write. After a recent conversation with someone new to modeling, I discovered that he did leave a gap. There’s a fair amount of learning you need to do before you can really get the value from his articles. Ambler also addresses both the analysis and design uses of class diagrams.

We will focus exclusively on using UML class diagrams for analysis. So if you are a business analyst or requirements analyst, this will help. If you are a developer, this will help you read the diagrams that analysts create. If you are a product manager, this will help too, but I think you’ll need to do this less frequently than a business analyst would.

We do assume that you are already comfortable using Microsoft Visio, but have not used it for creating class diagrams. You don’t have to use Visio, but the tools in Visio are good ones for creating class diagrams.

Visio Template for UML Class Diagrams

The easiest way to get started is with the default drawing type already available in Visio.

Create a new file, and select the Software category, then scroll down and select “UML Model Diagram” in either US or Metric units. When you do, a number of stencils will automatically load for you. You want to use the UML Static Structure stencil.

These are the shapes that you use to represent objects in a class diagram. You can safely ignore all of the other stuff that Visio provides in the other templates.

The Class

When you drag the “Class” shape onto the page, you get the empty looking box on the left. Visio automatically names it for you as “Class1.” The class represents a concept, entity, item, or object. It is important for analysts to remember that what you are drawing is “how the business thinks about these objects” – not “how developers will implement a representation of the objects.”

There are three areas in each “class” shape. The shape on the right shows that the top area is where the name of the class appears (in bold), the middle section represents attributes, and the lower section captures operations that can be performed by the shape. This feels like describing an implementation or design. The terms attribute and operation certainly sound like programming. UML Class Diagrams may have initially been created to help developers design solutions, that would certainly explain the names. There is still a lot of power to be unleashed – so take it on faith for now – we’ll present some examples that demonstrate the value of class diagrams for analysis.

Imagine that you are thinking about a lamp. Perhaps you are designing an emergency battery backup system, and one of the things you need to think about is how much wattage a lamp requires to operate. The wattage of the lamp, in English, is a characteristic of the lamp. Programmers call it an attribute. For our purposes, the terms are interchangeable.

A lamp can be turned on. That is pretty intuitive. We imagine ourselves turning on a lamp. Actually, all we do is turn a dial (or flip a switch). When we turn the dial, the lamp turns itself on. If we were really playing with language, we might say “When the user requests illumination, the lamp turns on.” We would never use that phrasing for a concept as simple as a lamp, but you get the idea. The operation is something that the object can do. Dogs bark, cats meow, lamps turn on.

When we are creating class diagrams for requirements discovery, we will always use class names, almost always use attributes, and almost never use operations.

A customer, in the diagram element above has an address. The customer also has a credit rating.

The two elements above represent the same information. A product has both price and weight. We also find, during our requirements exploration, that we need to know if a product is available. Perhaps our users need to know if a product is available right now before suggesting it as an up-sell item to a customer. If that is our requirement, we realize that we need to know the availability of the product. You can either include the question “Is it available?” or a single name for the attibute – “Availability.”

It is better to use the word “Availability” for two reasons. First, it is consistent to say “price, weight and availability.” You could achieve consistency with all questions – “What is the price?” “How much does it weigh?” and “Is it available?” But that becomes overly wordy. The second reason for using a single word is to avoid embedding rules in your requirements.

Consider the “Credit Rating” attribute for the Customer object. What we really want to know is if the customer’s credit is good. The definition of “good” will change over time, or may become complex. “Good enough for small purchases”, “Good when putting 20% down” are examples of the definition of “good” becoming complex. Or maybe you’re loaning money, and you can improve your profits with notions of “pretty good” and “really good.” You will create business rules to define what you mean by good. You happen to know that those rules will reason about the customer’s credit rating, so you should capture that value.

You could but should not represent the notion of “Is Credit Good?” with an operation:

You end up specifying design here – however unintentionally. Depending on how you interpret this, you are either saying “Customers are responsible for determining if their credit is good” or “The credit worthiness of a customer is determined without considering anything other than the customer.” While precise for programmers doing design, this is a pretty ambiguous thing to document in an analysis. By adding this operation, you are not providing unambiguous insight into how the business thinks about customers. So don’t do it.

Next Up

In our next article on UML Class Diagrams for analysis, we’ll look at relationships between classes.

If there’s something in particular you’d like to see explained, add a comment below and we’ll either fold it into the series or answer in the comments. And remember – you can subscribe to the comments for any article, just click the link.

Uncovering Requirements With UML Class Diagrams Part 2: Simple relationships between objects or entities.

Barry Boehm, inventor of the spiral model of software development, may also be the originator of the CRACK acronym for the type of users we want on our projects. When defining (and executing on) projects, we don’t just want CRACK users, we want CRACK stakeholders. And we want them to stick around. In fact, we’re addicted to them.

What Are CRACK Users?

We are not talking about substance abusers here. We are talking about users, and stakeholders in general, who have the following characteristics:

• Collaborative - stakeholders define goals and provide feedback and are available to work together
• Representative - they characterize (or embody the personas) who make up our key users
• Accountable - along with collaboration comes a sense of ownership: we succeed or fail together
• Committed - not just in percentage of time dedicated to the project, but also continuity of involvement over time
• Knowledgeable - understanding more so than knowledge leads to insights but both improve our deliverables

Thanks, Mike Griffiths, of Leading Answers, who points out the value to agile teams of having CRACK users. His article is actually focused on what to do when you can’t get users – and I love suggestion number three. Thanks Mike, and keep it up!

Before giving Mike all the credit, I wanted to see if anyone else was writing about CRACK users. Several of the top search results pointed to articles or presentations by Barry Boehm, who, due to his significant software engineering contributions, gets our “he must have invented it” accreditation.

As a quick tangent – during the search, I found a couple presentations by Barry were awesome.

• 2003 SERA Keynote Address – talking about agile and deliberate (non-agile) project approaches
• Systems of Systems: Characteristics and Challenges – dealing with enterprise architectures and projects in the tens of millions of lines of code arena.

This is a short one, but the idea is strong, and the linked presentations give you plenty of good stuff! Thanks Barry and Mike!

How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables – what would you do?

The Lay of the Land

Your IT director knows she needs something to give to her development and test teams. She’s looking to you to tell her what it is you need to deliver. Oh – and while it isn’t explicitly a constraint, her expectation is that you’re looking at something less than a couple of months of effort. To increase the pressure a little, she also tells you that her program will likely have a steady, ongoing need for requirements development – for now, she needs a “single capability” defined.

Her approach is really pretty rational. She’s rolling out a brand new initiative for the company. The initiative will drive tens of millions in profits for the company. There is a huge user base, there are stakeholders all over the globe, it is a “high pressure” environment – very visible internally, high external pressures, and there’s a palpable sense that continued employment is dependent on the success of the initiative.

There is an ocean of work involved in this particular initiative. Your director’s initiative needs to demonstrate momentum, so instead of boiling the ocean, she’s releasing new business capabilities incrementally. She’s working with the business stakeholders and customers to define “what first”, and then she’s working with internal teams to enable those capabilities one at a time. Each business capability is being treated as a distinct program – distinct funding, staffing, and timing. Sort of an “enterprise agile” – certainly an incremental approach.

The capability that she needs next (she has already prioritized it as “next” for the initiative) is also needed by other directors, for other initiatives. The enterprise IT folks intend to leverage the capability across many different programs and areas of the business. Each program has common and distinct needs, and different timing objectives. There are many moving parts involved in defining this capability across a multi-billion dollar enterprise.

Your mission is to figure out how best to validate your customer’s approach, identify what she needs, and estimate what it will take to make it happen – given the above environment. Do you try and boil the ocean, defining the requirements for the business capability across all the initiatives? If not, how do you define and manage deliverables for this one program?

One At A Time

There’s an interesting dynamic that comes into play when working with teams across and within an enterprise architecture. You have to think about the big picture (the ocean) in order to really understand things. At the same time, if you try to accomplish all of the needs of the disparate teams (boiling the ocean) at the same time, you will fail. Each group has its own dynamics, politics, deliverables, hangups, issues, and pet “favorite features.” If you try and tackle all of them at once, you will get mired in the bog of analysis paralysis and never make forward progress.

The best way to knock down all the dominoes in this case is to knock them down one at a time. Think of it as sequential product releases, each one targeted at a different market segment. Because that’s really what it is. As you build out a business capability (like “provide hosted service X”, or “sell products online”) for each program you are identifying a different set of internal stakeholders, end users, and often, delivery and test teams. They are independent projects that happen to share a lot of goals.

Dominoes make for a great analogy, because although you start out by knocking down the first one, you knock it towards the second one, with the intent of knocking them all down eventually. The more you understand about the other dominoes, the better a job you will do in knocking down the first one. But you have to focus on the first one first. The other knowledge provides context, and hopefully understanding that leads to insights.

Knock down the first one first.

How Much to Do?

You can approach this top-down (as we normally do with structured requirements), or bottoms-up. Either way, you end up with the same answer. We’ll work backwards in this article – since we’re identifying the deliverables, not creating them.

• Software Requirements Specification (SRS). We already know we need this – because the development and test teams at the company expect to work against an SRS. If your company uses something else to communicate requirements to development and test, substitute that artifact here.
• Fact Model and Glossary of terms.  Explicit agreement about language and terms is critical to avoiding confusion and ambiguity.
• Use Cases. The requirements in the SRS are defined to support use cases and goals. So we need use cases. The team you are working with, and the complexity of the business needs / processes will influence the format that works best.
• Actor Hierarchy and Personas. You have to identify the actors by role, and the personas that describe them.
• Business Requirements Document (BRD). Describes the goals of the business stakeholders.
• Vision & Scope Document. Describe the vision for your program, and its scope. Especially valuable in avoiding ratholes in this environment – be articulate about what you are not doing. Set expectations that the second domino is second – only the first domino is first.

You can reverse this list to create a top-down set of deliverables: Vision & Scope Doc, BRD, Actor & Persona definitions, Use Cases and SRS.

And Estimating…

The devil is always in the details when it comes to estimating. How long will use cases take? How many interviews will you have to do, and do you need to travel to do them? And a hundred more questions.
We aren’t trying to tackle the estimation details here – too many project specific variables, and as I just read somewhere, “estimating is more of an art than a science.” Although you can apply some science to expose and mitigate the risks around your estimates by using PERT analysis.

But now you know what you should deliver, and what you now have to go estimate.

[photo by Henkster]

Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.

Knowledge and Understanding

Holly Buchanan recently wrote a thought-provoking article about knowledge and understanding at Future Now. In her article, she tells us the story of how a Toyota engineer “got in the heads” of users by logging tons of hours driving a minivan all over the US. Her article stresses the importance of understanding users when it comes to persona development. And she’s right. It got us to thinking about the importance of knowledge and understanding from a broader perspective as well.

In other words, you can’t just know the facts; you must be able to interpret them.

I believe that in order to go from knowledge to understanding, one must have real-world insight into one’s customers. You have to dig deeper, ask better questions, and yes, put yourself directly into your customers’ shoes.

Holly Buckanan

Holly gets to the crux of things with that quote. Interpretation of knowledge is what leads to insights, and therefore understanding. This is critical to developing the right interactions for your products – but it is also critical to developing the right products.

Knowledge is something you can be taught. You can gather knowledge, someone can pass knowledge on to you. Someone who understands something can even pass along their insights – but when you receive them, they are merely additional knowledge. When you elicit requirements, you are really just collecting knowledge. There are many tips you can apply when interviewing to gather requirements, and you can even focus on making sure you interview the right people. All of this helps you to get the right knowledge, but it is still only knowledge.

Knowledge can also come from lateral thinking processes, like associative thinking.

Understanding, however requires more than just associations. Understanding requires incorporating contextual information into your data, and generalizing and abstracting from the data you have to form concepts, ideas and principles. Neither associations nor gathered data alone can get you to understanding.

Associative Thinking

Apparently, one of the impacts of (or descriptions of) autism is that people afflicted with autism think primarily in terms of associations. This very interesting article by Temple Grandin – a mildly autistic professor, Thinking the Way Animals Do, highlights the inadequacy of associations alone in achieving understanding.

People with autism and animals both think by making visual associations. These associations are like snapshots of events and tend to be very specific. For example, a horse might fear bearded men when it sees one in the barn, but bearded men might be tolerated in the riding arena.

Temple Grandin, PhD

We added a yellow Labrador to our family a couple years ago, and we took Scout to a trainer once a week for several months. As any dog owner will tell you, the trainer was there to teach us, not him. She made a very interesting statement at the time. She told us that dogs are great at making specific associations, but miserably bad at generalizing. Her example was that teaching Scout to sit in the living room when we have food would not help him to know to sit (with the same command) when we’re walking outside at night and he’s on a leash. Scout has no reason to associate the desire to sit with the command “sit” – he has to process many inputs, and makes a compound association, not a general one.

Her advice has proven out to be true over and over again. We taught Scout to not chew on the edge of his dog bed. He didn’t chew on that spot again after we said “No!” But he moved to a new spot 6 inches away and started chewing. We said “No!” again, and he moved again. This lasted for about an hour, as he gradually learned that chewing on any part of his dog bed was unacceptable. He couldn’t generalize that dog bed chewing was bad – he had to build up a list of don’t chew on this part of the dog bed and don’t chew on this part either, until we had the whole bed covered. He doesn’t chew on it at all, now.

With purely associative thinking, Scout didn’t develop an understanding – he only gained knowledge.

Context As a Framework

When we talk about best practices for defining requirements and managing them, we regularly refer back to the notion of structured requirements.

In earlier articles, we’ve pointed out that this technique helps primarily because it helps answer the question “Why?” “Why” becomes the context in which we make decisions. Throughout the software creation team, there are several roles with different perspectives.

Requirements Documents – One Man’s Trash

Different members of the team rely on different levels of decomposition of the problem to make their individual work (the “What”) actionable (the “How”).

We had a client who is facing a multi-national IT initiative, designed to support the sales process globally and regionally. In our role, we have to deliver requirements. To define those requirements, we have to understand our customer’s needs. Our challenge is to gain insights and understanding. If we just interview people and ask “what do you need?” they will give us knowledge, and we’ll capture it.

From that point forward, each person on the team has the opportunity to understand their work in the context of the requirements – but we are at risk, if the knowledge we capture in the requirements is incorrect or inadequate. To reduce the risk of making those mistakes, we have to gain understanding.

One thing I did was review McKinsey’s latest research on how the Indian economy is evolving. Their report proposes a (likely) view of how market forces and individual behaviors have shifted and are likely to shift. Understanding those market dynamics helps us validate or model a proposed growth rate for sales of a particular product in that market. This expectation, combined with an understanding of which sales-models work best in India helps us prioritize Indian requirements relative to those of other regions. This level of understanding helps us impart better knowledge to the rest of the team.

McKinsey’s report describes trends. We can generalize and gain insights into behavior (and likely behavior) from them and apply to the context of our particular analysis. And we can hypothesize and model financial forecasts based on their research – and that data impacts prioritization discussions. Ultimately, we will end up with better requirements, and better products.

A great way to organize this type of “contextual exploration” is through the use of concept maps. Each concept map provides a way for you to relate information that you’ve discovered with decisions you’re making. You create associations. This technique is usually applied to brainstorming, but it is even more powerful when documenting free-form associations of ideas.

Conclusion

Understanding of any topic comes from combining knowledge with context via associative thinking. We gain knowledge empirically. We gain context through organization of information. We apply associative thinking to interrelate that knowledge into a web of (scoped) understanding. Then, by gaining knowledge that is relevant to but not necessarily part of our scope, we can develop associations to what we already know, thereby improving our understanding.

This understanding leads to better decisions, better prioritization, better requirements. And ultimately, better software.

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

One way to identify the sources of bugs is by listening to how people tell you about the bugs.

1. “That is not what I want”
2. “That is not what I said”
3. “That is not what I meant”
4. “That is not how it is supposed to work”
5. “That is not what they meant”
6. “That is not what I want it to do”

Visually, you can think of the development process (regardless of methodology) like the following flow

Each of the six sources of bugs is labeled in the above flow. The article, Where Bugs Come From, goes into a detailed explanation of each source of bugs. This article looks at what you can do to improve the ability of your process to reduce these bugs. I have been a stakeholder, a product manager, a business analyst, a developer and a tester. And I’ve been guilty of all of these offenses at one time or another. When I say you, I also mean me. So chill.

“That is not what I want”

Stakeholders introduce bugs into the process by being unable to define what they want. Some agile methodology proponents argue that as a stakeholder, you can’t know what you want until you have something you don’t want in front of you. In other words, those agilists are giving up on trying to prevent these errors – they claim it is futile.

You can change your mind. The team could be dealing with “That is not what I want now” – and change is something that can not be prevented – although the impact of change can be mitigated. Iterative development and course-correction through getting immediate feedback is one way to do that. Prototyping is another method of course correction. Prototypes can also be used to elicit implicit requirements.

But that still avoids trying to directly address the issue of you not effectively describing what you actually want. There are ways to improve your team’s engagement with you, so that you actually say what you want. First, an emphasis on valuable requirements drives critical thinking about why you need a particular capability or feature. One approach to achieve valuable requirements is to question their justification.

The key to making this work is to make sure you are approving your requirements. And watch out for the anti-patterns in the article.

“That is not what I said”

Business analysts, product managers, and requirements analysts introduce bugs into the process through misunderstanding the stakeholders. Using the techniques above to stay on top of changes in stakeholder needs is not enough. Even when you effectively engage your stakeholders so that they are self-aware and can articulate exactly what they need and why, you still have a problem.

You can improve how you listen, and you can improve how you document what you heard. Make sure that you write complete, consistent and unambiguous requirements. While you’re at it – make sure you are writing your requirements correctly.

“That is not what I meant”

Developers can misinterpret requirements. While there are situations where a requirement is adequately expressed, but the developer is not capable of understanding, that is not the norm. Developers are smart. The onus is on the person writing requirements to make sure that they are written for the audience. So, even though the source of these bugs appears to be the developers, it is actually your documentation. If your documents need to span cultural chasms, then that’s your reality.

Make sure you write your requirements unambiguously, so that they are not misinterpreted. Make sure that they are feasible requirements, and that they do not specify design. The requirements also need to be concise without being overly terse.

“That is not how it is supposed to work”"

Developers should test what they create. Given an understanding of what you believe the code is supposed to do, you should test that it actually does it. This is the stereotypical bug – we asked for X, and it doesn’t work. Continuous integration is the most effective technique for addressing bugs that are introduced at this point in the process.

In more complex situations, you can apply more advanced techniques to assure that your testing is complete.

“That is not what they meant”

The testing team can also misinterpret requirements. This is a source of false positive bugs – even when the developers properly interpret the requirements, a bug may be lodged against their code when there is no bug. That’s why we have the ability to mark issues as “not a bug” when closing them. Apply the same rules for well-written requirements and you will also address this issue. Further, make sure that your requirements can be measurable, or verifiable. We recently wrote more about why you should make requirements testable.

“That is not what I want it to do”

User education is the key here. Users should be encouraged to provide feedback about your product. You don’t want to discourage feedback, you want to minimize the number of false positives. False positives come from users misinterpreting how the application is behaving – a sign of poor design. False positives also come from users not understanding what the application can (or should) do.

You can address design issues by focusing on design with the user in mind. And you can educate the users through a combination of training and with a novel approach to documentation. Document the product in terms of what users are trying to accomplish, in the context of how they are trying to do it.

Conclusion

There are a lot of people involved in the software development lifecycle. As people, we introduce bugs. As informed software professionals, we also know how to address many of them.



]]> http://tynerblain.com/blog/2008/01/14/you-are-creating-bugs/feed/ 8 http://tynerblain.com/blog/2007/11/08/abilene-paradox/ http://tynerblain.com/blog/2007/11/08/abilene-paradox/#comments Fri, 09 Nov 2007 05:16:42 +0000 Scott Sehlhorst http://tynerblain.com/blog/2007/11/08/abilene-paradox/



An excellent article by Jonathan Babcock raises a thought provoking idea. When gathering requirements, we can end up with requirements that no one actually wants, because everyone thought someone else wanted it. This is apparently known as the Abilene Paradox, a term coined by Jerry Harvey. We can apply our insights into stakeholders and traceability to prevent it.


The Abilene Paradox

Jonathan quotes Harvey in his article. Go check it out, we’ll wait here for you.

What? You didn’t go check it out? Here’s how Jonathan sums it up:

The heart of Harvey’s message, in my view, may be summed up in the following points:

1. While the benefit of coming to decisions as a group is that more points of view will filter out the weakest options, groups sometimes reach incorrect decisions because of false consensus.
2. People will go along with what they perceive to be “the crowd” even if, in reality, there is no “crowd.”
3. People tend to have an impression – either warranted or unwarranted – that there will be repercussions to speaking out against ideas with which they don’t agree.
4. If we acknowledge that the paradox exists, we can be more conscious of it, and strive to avoid it.

Jonathan Babcock (bold is ours)

OK, now we’ve got your attention. Go check it out.

Eliciting Unowned Requirements

The other point we walked away from the paradox with is that somehow, the group “manufactured” a requirement (or desire) to go to Abilene, even though no one actually wanted to go. This can be a real challenge with elicitation. The “requirements analyst” believes he has discovered a requirement to go to Abilene when there really wasn’t one.

The problem manifested partly because the people in the story jumped immediately to a solution, and then made assumptions, and then group think‘ ed themselves into a horrible experience. Once they were considering a solution, and failing to communicate, they ended up manufacturing the requirement to go to Abilene.

Context And the Ownership of Goals

Had the people validated those assumptions, with a simple question, “Why do you want to go to Abilene?”, they would have avoided the dreaded trip entirely. If you walk away with the “solution” of “always ask why” you’ll do ok. But you could do better.

“Why?” is certainly a good question – but ultimately, you need to understand the rationale and ownership of goals. In the story, the father-in-law proposes the trip to Abilene as a cure for (perceived) boredom. The rest of the family assumes that he, and each other person (progressively) actually wants to go to Abilene. In reality, the father-in-law wants to cure family boredom, and the other family members want to make each other happy. The long drive through the Texas desert to eat bad food in Abilene achieves none of those goals. Why someone would think that driving through the Texas desert is a cure for boredom, I’ll never know. Perhaps when you live 53 miles outside of Abilene, you have different standards.

Imagine that the father-in-law had expressed his goal (requirement) – “We need a cure for our boredom!” and then proposed a solution “Let’s drive through the desert.”

The family would have had the opportunity to dispute the need for a cure for boredom. At a minimum, we would hope that they would propose an alternative solution, like staying home and seeing how high they could stack some rocks.

In the World of Software Development

Cute as the story is, there are unfortunately too many examples of this happening in our companies or with our clients. Someone proposes a solution, without defining the problem. It could be an executive, forbidding all employees from using instant messaging tools, instead of identifying low worker productivity as a problem to be solved. It could be someone from the IT department mandating that all employees may only use Internet Explorer, instead of identifying that the human resources self-enrollment website does not support other browsers.

Or it could be an example I saw recently in a use case. Paraphrasing to protect the innocent:

1. User adjusts price discount on product.
2. System updates product price on quote.
3. System updates subtotal price (for all products) on quote.
4. User requests recalculation of shipping and taxes.
5. System updates total price (for all products, including shipping and taxes) on quote.

Discussions with the product manager reveal that the existing system (being modified) was implemented such that the server that recalculates taxes can not handle the volume of tax-calculation requests that would be created if taxes were recalculated with every price change (step 1) on every quote. By asking users to make multiple price changes, and then just recalculate taxes once per quote, the load on the tax-calculation system was dramatically reduced.

A use case represents what the user is trying to accomplish – it should neither incorporate design elements, nor articulate system constraints.

There’s a very real possibility that the tax-calculation server has been updated to handle all the traffic for all of the users. If the use case is written such that it implies that the user desires to manually recalculate taxes, then the user is very likely to get stuck recalculating taxes manually.

Expressing this procedural artifact within the use case is forcing the user to go to Abilene for dinner.

Conclusion

When you gather and write requirements, find out the source of the requirements – and trace those requirements to the source. Don’t mix them up. Don’t enforce constraints / requirements within a use case that are unrelated to what the user is trying to accomplish (reducing the price on a quote to close a sale). Validate and document the system constraints (tax-calculator can only handle X quotes per hour), separately.



]]> http://tynerblain.com/blog/2007/11/08/abilene-paradox/feed/ 4 http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/ http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/#comments Fri, 14 Sep 2007 04:17:49 +0000 Scott Sehlhorst http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/



Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?

Elicitation Techniques

The BABoK (Business Analyst Body of Knowledge) identifies ten different methods of gathering information. That list is a good one for describing the complete tool set that business analysts should have for elicitation. The same techniques are valuable for product managers too.

We wrote about those techniques almost a year ago, from a requirements gathering perspective. Check out that article for more details, but here’s the short list:

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey

Different Views of the Business

Processes, requirements, and rules all represent different elements of how the business works, or how software must work to support the business. The most obvious distinction is one of perspective.
To oversimplify a little, some rules define the regulations and policies that constrain how a business operates. Some rules represent calculations, inferences, or enable actions that provide some precision about the business operates at a greater level of precision.

Processes represent a business design decision by the company. Given a set of goals and constraints (both “rule constraints” and practical ones – resources, costs, market forces, etc), processes are designed to achieve business objectives. They generally manifest as procedural instructions for the business. Note that they should be modeled at a higher level of detail than “open this file, walk down to purchasing…”

Requirements are an articulation of what a tool (in our case, a software product) must do when it is used in one of the business processes. The design of those processes has an impact on the requirements of the software. The rules that constrain the business (and by extension, the processes) must be enforced within the software.

Ultimately, we have to understand all three to create successful software.

Different Drivers of Change

A more subtle difference is in recognizing that processes, rules, and requirements change differently. Each class of artifacts changes for different reasons, on a different time scale.

Policy rules generally change as top-down mandates, or external forces. State or federal regulation changes can affect how a company does business. The Sarbanes-Oxley act has driven massive changes in how companies operate. These are relatively infrequent, but sweeping changes. Their effects cascade through everything the business does (and therefore everything that is required of the tools used to operate the business).

Decision rules generally change as part of feedback loops in processes. Consider the set of rules that an insurance provider uses for determining what premium to charge for a given policy. These rules are so extensive that they are maintained in rate tables, or other complex rules-calculation systems. An insurance company will have a department who’s responsibility is to maximize the profits that come from setting premiums. That means that they will tweak the rules in their rate table on a regular basis – like an ongoing science experiment. Predict, modify, inspect, repeat.

Process changes can happen as a result of policy changes, but more likely, they happen because of business re-engineering. This is the same feedback loop that affects low level rules, but on a grander scale. The big business consulting companies make very good money providing business consulting services. Part of that is strategic guidance, and part of it is process re-engineering. They look for inefficiencies and missed opportunities in processes. The predict the ROI of changing the processes, propose changes (maybe even help manage those changes), and repeat. These larger changes take more time than changing low-level rules.

Requirements articulate how the software must support the given processes, while implementing or enforcing the company’s rules. Requirements can change because of process changes, and policy rules changes. As long as you separate rules from requirements, then changes to low-level rules will not force changes in requirements. And ideally, for volatile rules, will not require you to modify (and test and re-release) your software. Requirements also change because they represent our understanding of the business’ understanding of what they wanted when we gathered them. And the business can change it’s mind, as it gets new data. One of the arguments for iterative development is that people don’t know what they want until you’ve given them what they don’t want. There’s some truth in that.

Effectiveness of Different Techniques

We’ve mentioned before that the same elicitation activities, and people, generally gather process data, rules, and requirements. And that presents one of the challenges in managing them independently. Here’s a table that summarizes the effectiveness of different elicitation techniques for uncovering and defining a business’ processes, rules, and requirements.



Each technique has a row, and is graded Consumer Reports style. Each type of artifact has a column. A full green circle means that the technique is well suited to eliciting that information. A half-filled circle means that you can use that technique to gather the data, but it is not as effective as the full-green-circle techniques. An empty circle means it isn’t impossible, but you should avoid it if you can.

As an example, reverse engineering is ineffective at defining any of the above. Reverse engineering can tell you what you have, but in no way can you assume that what you have is what you need. In fact, if it were, then your customer wouldn’t need to do the new project at all. Reverse engineering is a last resort that we sometimes have to rely on, but you should always treat it as a “starting point” – a baseline to be corrected and validated. It is certainly going to paint an incomplete picture – and often an inaccurate one.

And You?

These effectiveness assessments are based on experiences with dozens of clients in the enterprise software space, over a decade of elicitation. That means they are anecdotal. Thousands of people will read this article [Really. How cool is that?!]. So if you can confirm the above, or even better – correct it and share your experiences, we’ll be able to paint a much better picture. So – join in the discussion and let us all know.



]]> http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/feed/ 3