Monthly Archives: May 2006

Writing Concise Requirements

Big Ten Logo

One of the ten big rules of writing a good MRD is writing concise requirements. We have to minimize the amount we write to avoid information overload. We also need to make sure we write enough to get the message across. How do we strike the balance?

The Big Rule of Brevity

From our previous article, Writing Good Requirements – Big Ten Rules:

Easy to read and understand. If only it were that easy. For whom is it easy to read? A market requirements document (MRD) is written for several different people on the team. It provides a vision of what problems our product solves. It provides clarification to the implementation team. It also sets expectations with stakeholders. Different people on the team have different domains of expertise – we have to write requirements that are easily understood by all of them.

The primary goal of concise writing is to improve communication and retention of ideas. The goal is not to save time. It takes more time to write less. Trust me on this.

How do we confirm effective communication?

Confirm Personally

The only way to confirm that the reader of a document understood what the author wrote is to ask him. “Did you understand?” doesn’t work. We have to create a feedback loop where the reader can give us confirmation that they understood. Teachers would do this in the essay portion of a literature exam – “In your own words, what did the author mean by…?”

We can get this feedback by directly speaking with the reader and using active listening skills to confirm that the reader understood the key concepts. The goal isn’t to correct the person’s understanding during the conversation. Rather, any misunderstanding is a “bug” in the documentation. We use those gaps to update our document, and then validate that the changes are understood.

Confirm Indirectly

A less effective technique, but one that might be required when working with a geographically distributed team is to infer levels of understanding by reviewing the output of the reader. We can potentially confirm that the reader understood the requirement by validating ‘the next step’ in the process. We can confirm that a business analyst understands the market requirement by validating the software specification that she creates. If the spec ‘completely covers’ the requirement, and does not introduce new ideas, then we know that the requirement was understood. If the spec is inadequate, then it may be due to mis-communication, or lack of competence.

As product managers, we aren’t in a position to validate the designs created by the implementation team, so this approach generally will not work for validating a spec. We may have the skills (perhaps we previously were developers or designers), but we should not try and do this – we risk getting caught in the weeds.

Improving Our Writing

  • Requirements documents need to be scannable, much like web pages or articles. Readers need to be able to refer back to a particular requirement repeatedly to understand how to validate their work. We also need to be able to verify the requirement. Use of lists and short paragraphs help with referenceability and scanning.
  • We have to be on the lookout for repetitive content within a requirement. The repetition at best is hard to read, and at worst is self-conflicting.
  • We can include examples. Examples are often very illustrative of an idea.
  • We can include OOA diagrams. Entity-relationship diagrams, when the reader knows how to interpret them, are very effective both for precise documentation, and for concise documentation. Remember that we are diagramming the problem, not the solution.

Conclusion

Write no more and no less that you have to. Confirm that the readers understand what you intend.

Writing Valuable Requirements

Big Ten Logo

One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?

The Big Rule of Value

From our previous article, Writing Good Requirements – Big Ten Rules:

Pragmatic uses necessary as a criteria of good requirements. We believe that valuable requirements are good requirements. When prioritizing requirements, we should do the must-have requirements first. But other valuable requirements are critically important – even if they aren’t mandatory. Prioritization and release scheduling should stress necessary requirements first, and then the most valuable requirements next.

Requirements that can differentiate our product from the competition are by definition not necessary – or the competition would have done it already.

Valuable How?

Ultimately, we care about requirements that are valuable to us – they help us sell more software, more profitably.

We might sell more software by selling additional products to the customer. Our customer could become an advocate for our products, helping us sell the software to more customers. We could get a maintenance, subscription, or renewal contract. Or we might offer services that can be sold in conjunction with our software.

When we solve the right problems, we can sell our software for more profit.

Valuable to Whom?

While value to us is our ultimate goal, we sell software because it is valuable to our customers. There are two key groups we need to listen to, and one we need to ignore. We address the needs of the purchasing persona and the key user persona. We don’t let our salespeople have undue influence over our requirements.

Salespeople are correctly focused on a single sale. “Add this feature, and I know we can close this deal!” And a good salesperson is likely to be right about that. This, however, is a slippery slope. When we are writing an MRD we are writing market requirements, not customer X requirements. Salespeople give us input that is overwhelmingly driven by the influence of the current deal. Its possible that the salesperson is tapped into a single example of a market requirement. But it isn’t the salesperson’s priority to vett that requirement as one that applies to multiple customers. We have to do that.

The key user personas are the primary beneficiaries of our software. We are helping them improve existing processes, or we are introducing new capabilities that allow them to introduce new business processes. We help them in a way that helps their employer to make more profit. Since this is a market requirement, we need to validate that this problem is one that applies generally to our potential customers in the market, and not specifically to this customer.

A market requirement may look like the following:

Customers are waiting an average of five minutes for customer support when they call for assistance. We need to reduce the time that people wait on for support to an average of under a minute without adding support staff.

The supporting product requirement might look like the following:

Our best technical people are spending time on easy-to-solve problems, and our new-hires are wasting time trying to solve problems that they can’t solve. We need a way to make sure that our new-hires are not trying to solve problems they can’t solve, and our experts are not spending time solving trivial problems. We need a solution where new-hires solve >90% of all calls they handle, and experts only handle calls passed on by new hires.

In this example, the user persona is the call-center support staff member. The key user would be the new-hire. This requirement is valuable to them. The new-hire might have a personal goal of getting promoted. The ability to process more calls to resolution (by immediately rerouting hard problems) will help them achieve their personal goals.

The corporate goal of increasing the effective capacity of the team is also achieved. Our buying persona cares about this. And our buyer won’t buy if they don’t understand the value. A valuable requirement will be measurable. In this example, reduction of waiting time from over five minutes to under a minute is an easily measured market requirement. We can also easily measure that more than 90% of calls get re-routed, or that all expert-calls are previously vetted by the new hires.

How much value is too much?

Why did we set a goal of moving from over five minutes per call to under one minute? Why not under two minutes, or under ten seconds?

We’re dealing with a measureable goal that operates on a continuum. Most continuum-based goals operate under the law of diminishing returns. A reduction in time from five minutes to three is worth more than a reduction from three minutes to one. In our example, we have data that indicates that most people who will wait ten seconds will wait a minute. After we have asked them to wait a minute, more people become unhappy with the service with each passing moment. We have a data-driven utility curve that we can measure caller-happiness versus wait time. This gives us a good understanding of value versus wait time.

We also have to understand the cost function. Our engineering team, in this example, has studied the previous call logs and believes that we can achieve the one-minute mark by providing a solution that helps new-hires triage a call in ten seconds, and know if they need to forward it to an expert. To get the triage process under ten seconds, our engineering team has told us that they would have to build a system that automatically knows if the problem is easy to solve or hard. And this solution can involve voice recognition, or online-connectivity to the product being supported, or other cutting edge technological solutions. These clever solutions are also dramatically more expensive. This gives us a good understanding of the cost of solution versus predicted wait time.

By combining these two sets of data (benefit versus cost) we can produce a curve that tells us exactly how much is too much.

Cost Benefit Curve

Making the tradeoff

Our customers will be willing to pay more for more value. However, they will have a target ROI or hurdle rate for making an investment in our solution. The cost axis of the curve becomes the cost to our customer for a particular measurement of the requirement (three minutes, one minute, ten seconds). The customer’s hurdle rate is tangent to the cost-benefit curve (representing customer cost and customer benefit) at the customer’s optimal point.

We should target this point for the requirement.

When Should We Get the Value?

We might not target this point for the earliest releases of our software.

In an incremental delivery process, we may prioritize a partial delivery of the feature in an earlier release. When scheduling requirements across releases, we start with a focus on the must-have requirements, and then introduce the more-is-better requirements.

In our example, we may choose to solve this problem with a database that provides keyword lookups for the new-hires, who can ask two or three simple questions, and then quickly identify the problems that are beyond their capacity to solve. This system might be designed to also log the solutions based upon the answers to the triage questions (allowing new-hires to solve more and more of the problems). In our first release, we might choose to implement the logging features. In the second release, we may include the ability for experts to input post-mortem results (to make the system get smarter over time), and in the third release, we may focus on entering data from the previous call logs, so that the system is sufficiently smart to allow for routing of more than 90% of incoming calls.

Conclusion

  • Make sure our requirements are valuable.
  • Make sure that the value is expressable to the buyers and ideally directly achievable by the primary users of the system.
  • When developing requirements along a continuum, use data (not opinion) to set the target for the requirement.
  • Prioritize incremental delivery of the functionality across sequential releases.

Test Smarter, Not Harder – A Detailed Article

Scott Sehlhorst

developer.* has just published a 15-page article, Test Smarter, Not Harder by Scott Sehlhorst on test automation. We present the background for that article here (why you should read it) as well as a summary of what is covered in the article. Check it out at developer.*, and thanks to Dan Read, both for starting developer.* (which is a GREAT site) and for publishing the article. Skip to the end of this post to see how you can help.

Automated Testing Must Be a Core Competence

Automated testing has become a critical component of software product success. Processes like continuous integration require test automation to be effective. Unit testing requires automated testing to be effective as a rapid-development tool. Whitebox testing is almost always done with automation. More and more blackbox testing is being done with automation. A team without a good approach to automated testing is working at a severe disadvantage, and is arguably doomed to extinction.

Functional Testing (or system testing) is where a team can achieve process differentiation with automation. 80% of teams rely on manual functional testing today. These teams argue that automating functional tests is too expensive. The reasons most cited are complexity and rapid change in the underlying product.

Testing Complex Software

Complex software presents very challenging problems for test automation. First – how do we deal with the extreme complexity of many of today’s software applications? Billions or trillions of combinations (scripts) of user actions can be made. And software that works with one combination may be buggy in hundreds of others.

We can’t realistically test all of the combinations. Even if we did have the hardware needed to run them we would not be able to validate the results of all of those tests. So we can’t achieve exhaustive test coverage.

Without exhaustive test coverage, how do we know when we’ve tested enough?

Test Smarter Not Harder

The article starts with an analysis of the complexity of modern software and a brief discussion of the organizational realities and typical responses. Then the article explores common approaches and techniques in place today:

  • Random Sampling
  • Pairwise Testing
  • N-wise Testing

The article explores the math, benefits, and limitations of each approach. While N-wise testing is the most effective approach in common use today, it has a limitation – it assumes that the user’s actions (input variables) happen in a prescribed sequence or are irrelevant. In most complex software this assumption is invalid. The article presents a technique for incorporating order-dependence into the statistical approaches for developing test coverage.

The article also demonstrates techniques for simplifying the testing representation using whitebox testing techniques to redefine the problem space, and then applying blackbox testing (statistical) approaches to execution of the resultant test parameters.

By combining the statistical techniques explained in the article with a communication plan for sharing the appropriate quality metrics with stakeholders, we can deliver higher quality software, at a lower cost, and with improved organizational support and visibility.

Why developer.*?

While many Tyner Blain readers are interested in test automation, most of our readers would not want to go into this much depth. The audience at developer.* has a more technical focus, and their site is a more natural place for this article. Personally, I am honored to be included as an article author there – and all of you who want more technical depth than we go into at Tyner Blain should really check out the stuff Dan Read has put together. They’ve also just published their first indie-publisher ‘real book‘, which you can get via their site. My copy is on the way as I type.

How can you help?

This is a great opportunity for PR for Tyner Blain – please share the article with your associates because we want our community to grow. Also, it would be great if you ‘digg’ the article at digg (just follow the link, and ‘digg it’), del.icio.us, blink, or any other networking site. In addition to being good content, I hope to make this an experiment in viral marketing. Lets see if we can collectively reach the tipping point that brings this article, and the Tyner Blain community to the next group of people.

[update: the article just made the front page at digg and has 374 diggs and 32 brutal comments :). Welcome to all diggers, mobile, agile, or hostile!]

Non-Functional Requirements ERA [now available]

error message

PEBBAK* error!

Through a complete oversight / ommission / coma, the Non-Functional Requirements Equal Rights Amendment article was accidentally marked as private shortly after it was published. I was wondering why so many 404s happened when people tried to read it.

Well, its back now. Enjoy it, and comment. It highlights a critical issue – requirements that characterize behavior are not getting the attention they deserve. James Leatherman also has some great thoughts on how to address this issue – we agree on the problem, but don’t yet agree on a solution. Check out his original post, and his followup – he managed to get a comment with a link before the post mysteriously disappeared.

Add your comments, or links to your own thoughts – we will all benefit from figuring this one out.

*PEBBAK – Problem exists between blogger and keyboard

Writing Good Requirements – The Big Ten Rules

logo

Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.

Pragmatic’s List (1-8) + Two Three Four More

  1. Necessary Valuable
  2. Concise
  3. Design Free
  4. Attainable
  5. Complete
  6. Consistent
  7. Unambiguous
  8. Verifiable
  9. Atomic
  10. Passionate
  11. Correct
  12. Stylish

Looking at each rule of writing good requirements…

1. Valuable

Updated for 2009

Writing valuable requirements is important.  It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features.  The right products and capabilities are the ones that have relevant value.

  • Valuable requirements solve problems in your market.
  • Valuable requirements support your business strategy.
  • Valuable requirements solve problems for your users.
  • Valuable requirements meet your buyers’ criteria.
  • Valuable requirements don’t over-solve the problems.

Valuable Requirements

Pragmatic uses necessary as a criteria of good requirements. We believe that valuable requirements are good requirements. When prioritizing requirements, we should do the must-have requirements first. But other valuable requirements are critically important – even if they aren’t mandatory. Prioritization and release scheduling should stress necessary requirements first, and then the most valuable requirements next.

Requirements that can differentiate our product from the competition are by definition not necessary – or the competition would have done it already.

[Update: Our detailed article on Writing Valuable Requirements ]

2. Concise

Updated for 2009

Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done.  Great requirements exist to do three things:

  1. Identify the problems that need to be solved.
  2. Explain why those problems are worth solving.
  3. Define when those problems are solved.

Concise Requirements

Easy to read and understand. If only it were that easy. For whom is it easy to read? A market requirements document (MRD) is written for several different people on the team. It provides a vision of what problems our product solves. It provides clarification to the implementation team. It also sets expectations with stakeholders. Different people on the team have different domains of expertise – we have to write requirements that are easily understood by all of them.

[Update: Our detailed article on Writing Concise Requirements]

3. Design Free

Updated for 2009

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Design-Free Requirements

Generally, a requirement should not specifiy any of the implementation choices. From a product manager’s perspective the requirement is the ‘what’ and the spec is the ‘how’. To a system designer or architect or lead developer, the requirement serves as a ‘why’.

[Update: Our detailed article on Writing Design-Free Requirements]

4. Attainable

Updated for 2009

Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.

Attainable Requirements

The requirement must be realistically achievable. Barbara and Steve make great points about understanding the cost of implementing something as expressed in the requirements. As we pointed out in our thoughts about good requirements management, there is an optimal tradeoff between costs and benefits for any given company or project. We can formally approach this using the techniques identified for more is better requirements using a Kano framework. In short, the investment must have an ROI that exceeds the opportunity costs by the hurdle rate.

Looking at cost-benefit tradeoffs also supports the argument that valuable should replace necessary.

[Update: Our detailed article on Writing Attainable Requirements]

5. Complete

Updated for 2010

You give your requirements to the engineering team, and they look complete. The team builds your product, you launch it and the market soundly rejects it. Why? Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.

Complete Requirements

Simply put, if the requirement is implented as written, the market need is completely addressed. No additional requirements are required. When writing a specification, we may use decomposition to break individual requirements into more manageable, less abstract criteria.

[Update: Our detailed article on Writing Complete Requirements]

6. Consistent

Updated for 2010

Consistency in writing requirements is important on two levels – strategic and tactical. Tactically, you need to write your requirements with grammatical consistency, so that potentially ambiguous statements will be interpreted similarly. You also need to write requirements that are logically consistent, so that you avoid “impossible” requirements and gaps of unspecified meaning. Strategically, your requirements need to reflect a focus on markets and problems that are consistent with your business objectives and the vision your company is manifesting

Consistent Requirements

Pragmatic Marketing highlights that the requirement must be logically consistent with the other requirements in the document – no overlaps, no contradictions, no duplications. This is certainly the most important point of consistency.

There is also benefit to consistent writing in an MRD. We can use templates to provide a consistent framework, but more importantly the prose needs to be consistent. This consistency makes it easier on the readers.

[Update: Our detailed aricle on Writing Consistent Requirements]

7. Unambiguous

Updated for 2010

Writing unambiguous requirements is about understanding what is written, and what is read. Without a clear understanding of your market, you can’t write unambiguously. Even when you understand your market, you risk writing something that is ambiguous to your readers. Documenting requirements is about communication. Don’t break this rule, or you’ve wasted all the energy you spent understanding your requirements.

Writing Unambiguous Requirements

A great requirement has a single interpretation. A good requirement has a single reasonable interpretation. As part of our development process, we will use listening skills like active listening to make sure that our engineering team understands the requirement we intended to write. The better the requirements, the less expensive and risky this communication process will be. Writing unambiguously is critically important when using outsourcing models that limit our interactions with other team members.

[Update: Our detailed article on Writing Unambiguous Requirements]

8. Verifiable

Updated for 2010

Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can’t verify that what the team delivered is acceptable, neither can the team. This may be the most obvious of the rules of writing requirements – but it is ignored every day.

Verifiable Requirements

We use a process that starts with market requirements, and then decomposes them into software requirement specifications. the market requirements must be written in a way that we can verify that the associated requirements specification will meet the market need.

[Update: Our detailed article on Writing Verifiable Requirements]

9. Atomic

Updated for 2010

Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements are important.

Atomic Requirements

Every requirement should be a single requirement. If we can say “Half of this requirement is implemented” then this needs to be two or more requirements. If a requirement read “Sales reps can manage their client list and generate custom reports” it expresses two atomic ideas (list management and report generation). Those ideas need to be separated

[Update: Our detailed article on Writing Atomic Requirements]

10. Passionate

Nothing great has been born from complacency, lethargy or mediocrity. When we are defining requirements, we must be passionate about what we’re doing. If we’re just going through the motions, it shows up in the writing. If we aren’t excited about a requirement, the problem is either with us or with the requirement. Either way, it won’t inspire the rest of the team to do something great.

[Update: Our detailed article on Writing Passionate Requirements]

11. Correct

[Update: Added 30 Oct 2006]

In addition to all of the analyses above, a requirement must actually further the objective it supports, and must be neccessary to meeting that objective, given a particular approach to solving the problem.

Our detailed article on Writing Correct Requirements.
12. Stylish

[Update: Added 5 Jan 2007]

Style can also be the difference between a well-crafted requirement and one that is hard to read. And style, applied consistently across requirements makes it easier to view them as a whole, and identify gaps and inconsistencies. This ease of comprehension matters when trying to achieve correct, consistent, complete requirements.

Our detailed article on Writing Stylish Requirements.

Summary

There isn’t really anything to summarize – this article is one big summary.

I would like to take a moment to thank everyone who has been subscribing, reading, commenting, and sharing Tyner Blain. We started this site six months ago and I am continually surprised, flattered, and thankful for all of the readers and support we have.

Thank you very much!

Scott

Product Differentiation vs. Product Improvement

mousetrap

Build a better mousetrap. That’s what they used to say. But that doesn’t differentiate our products. Everyone is doing better, we need to do different.

Innovation

Innovation is good. But as Geoffrey Moore points out, it has to be differentiated too. We talked about this when discussing Kano analysis and prioritization of requirements.

One of Mr. Moore’s points is that innovation isn’t the goal – product differentiation resulting from innovation is the goal. He’s absolutely right. An innovative way to minimize the window of an application isn’t likely to differentiate the product from it’s competitors. An innovative way to automatically validate requirements would be the proverbial better mouse trap.

Differentiation

More precisely, valuable differentiation. Differentiating our products in ways that don’t matter is a bad idea, and common mistake. Differentiation should be in areas that redefine the problem, or solve problems that no one ever combined before.

The idea of a mashup is interesting, most mashup execution isn’t. Being able to view flikr photos geotagged with the location on the Google map is pretty cool. Being able to read Zagat restaurant reviews for the restaurants on the Google map would be valuable. Showing the restaurants near my hotel with a $20-$30 dinner option, and at least 3 stars would be even better. Might as well offer a coupon code with the directions. Anyone done that yet?

sailboat

Sailboats can sail into the wind because the sail acts like a wing. Why did we wait decades until someone actually used a wing instead of a sail? We’ve had the data since the Wright Brothers built the first wind tunnel a hundred years ago. People were trying to make sails better instead of making sailboats different. We had to wait until someone had a differentiated innovation.

Sailboat designers weren’t focused on the market requirement – make sailboats faster. They were focusing on a product specificationmake a better sail.

Seth Godin puts it succinctly:

When you make something that works a little better, you’re playing the same game, just keeping up with the status quo. When you make something different, on the other hand, you’re trying to change the game.

Conclusion

When comparing our products to our competitor’s products, if we find ourselves saying “It’s like X only better” we’re in trouble. If we’re saying “This is nothing like X because…” Make sure there’s differentiation. And make sure its valuable.

Non-Functional Requirements Equal Rights Amendment

measuring

We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? James Leatherman points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…

Structured Non-Functional Requirements

[Update Aug 2009: I realized the previous version of the following sentances could imply that this is “his” model – it is my interpretation of his model.]  My interpretation of Karl Wiegers’ structured requirements model (explained here) is show below.

original structured requirements

  • Goals are achieved by enabling use cases.
  • Use cases are enabled by implementing functional requirements.
  • Functional requirements must have the characteristics defined in non-functional requirements.
  • Functional requirements drive design decisions that are restricted by constraints.
  • Design choices guide implementation
  • Implementation is product

James realized that non-functional requirements are not getting enough attention. His solution approach is to deny that there is such a thing as non-functional requirements, thereby forcing people to deal with those requirements. By eliminating the stigma, I suspect he hopes to remove the second-class citizen status that non-functional requirements seem to have.

Here is my issue – there is no such thing as a “non-functional” requirement. In the IBM Rational world, there are Functional Requirements, encompassing business use cases, needs and features, UI specs and so forth – and whatever is left over (security, error recovery, etc.) gets heaped into “non-functional” requirements. Not only is this improper classification and a total misnomer, but it almost always gets overlooked by the project team. Bad idea, considering that, from my experience, 80% of the risk is in these neglected areas.

There is value in maintaining the classification of non-functional requirements. Requirements that represent different aspects of what shall be done should be separated, but they should also be treated with equal importance.

  • Functional requirements define what the system must be able to do, without defining how this is to be accomplished. The system shall store contact information. The system shall apply shipping and tax charges when billing customers.
  • Non-functional requirements define measurable, characterizing aspects of what the system must be able to do. The system shall return search results in under ten seconds. The system shall process at least 10,000 orders per minute.

Equal Rights for Non-Functional Requirements

As James pointed out, much if not most of the risk of delivery is in failure to meet these characterizing requirements. What we need to do is make sure that non-functional requirements get as much attention as functional requirements. We’ve reworked our structured requirements diagram to better reflect the importance of these requirements.

improved structured requirements

  • Goals are achieved by enabling use cases.
  • Goals drive non-functional requirements.
  • Use cases are enabled by implementing functional requirements.
  • Use cases influence non-functional requirements.
  • Non-Functional Requirements define the characteristics of functional requirements.
  • Functional requirements drive design decisions
  • Design choices are restricted by constraints
  • Design choices guide implementation
  • Implementation is product

We’ve made four distinct changes to the diagram

  1. Non-functional requirements define characteristics because they are needed for the goals. When a characteristic is irrelevant, it should not be documented. This explicit traceability to the underlying goal helps us keep our eyes on the ball and not lose sight of the importance of these non-functional requirements.
  2. Use cases influence which non-functional requirements need to be defined. The use cases embody the interactions that users will have with the system. Some non-functional requirements are independent of the specific interactions, so we used a dashed line. The dashed line serves to remind us that this relationship can exist but might not.
  3. We’ve re-ordered the statement of the relationship between non-functional requirements and functional requirements to highlight the significance of the non-functional requirements.
  4. Constraints represent limitations on how a solution must be implemented (database, supported hardware, etc). We’ve moved the relationship to properly show that constraints influence design decisions, not requirements decisions.

Conclusion

Non-functional requirements are critically important. They are distinct in their structure and content. That distinction should remain, if for no other reason than to help people focus on writing good requirements.

MRD Writing Tips – Ten from Michael Shrivathsan

handoff

Michael wrote five (and another five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We’ll extend the conversation here…

Michael’s list:

1. Write From User’s Perspective
2. Use Screen Shots
3. Write Using Simple Language
4. Use Templates – But With Care
5. Prioritize Requirements
6. Specify What & Why – But Not How
7. Cover Non-Functional Requirements
8. Review & Update
9. Define Target Market & Positioning
10. Include a Glossary

We have re-organized these tips into three general areas of guidance and provide our thoughts.

  1. Good communication (tips: 1,2,3,4,10)
  2. Good requirements (tips: 5,6,7,9)
  3. Good requirements management (tips: 8)

Good communication

The purpose of the document is to communicate. Writing for our audience is essential to communication. Using templates to create a predictable structure and flow makes the content easier to absorb. Using clear, unambiguous language (no contrived terms or jargon), makes the ideas easier to grasp and remember. Providing a glossary of terms to provide domain context for the readers is essential for many projects.

A software developer who is an expert at load-balancing a web server may not have any idea how to calculate incremental margin for sales beyond forecast. “Incremental margin” may seem like jargon, but it is a standard term (within the management accounting domain). Use that as your rule of thumb – is the term company-specific, or would anyone in the domain understand it. If the former, its jargon. The latter should have a glossary entry.

A picture is worth a thousand words, certainly. It isn’t clear that using screenshots or mockups is the best way to capture requirements in an MRD. Because they are so powerful, it is impossible to get the intent, without being influenced by the form. This is an area where a lot of smart people agree to disagree. We’ve written about the dangers of using screenshots or other implementation cues that can be interpreted as ‘how’. As Michael points out, often ‘how’ is the appropriate way to communicate with other members of the team – it depends on the team. Barbara Nelson, a product management instructor for Pragmatic Marketing, stresses that the product management role is strategic, and getting into details isn’t. It may be required, but if the product manager is doing it, who’s doing the strategic work?

On the flip side, Alan Cooper is promoting Interaction Design. In an interaction design process someone is responsible at a level analogous to an MRD for determining both what and how. This is basically an interpretation that the how is an element of the what, not just an implementation detail. Combining interaction design with classical structured requirements might look like this amalgam.

Good requirements

Prioritization is the most important element in the document (other than the ideas being prioritized). One goal of an MRD is to communicate the vision of the software. Understanding what and why, with the context of which is more important, is the mechanism of communication to the engineering team. This message provides the framework in which they operate.

MRDs are also the right focal point for driving much of the outbound communication. The vision in an MRD identifies which white papers should be created. The (market) positioning provides guidance to sales people in individual account positioning. (Sales) demos should highlight the most valuable capabilities of the product. Roadmaps and the multi-release schedule are driven by prioritization. Schedules may be managed in timeboxes and delivered in use-case-sized chunks, but the driving prioritization is in the MRD.

Good requirements management

MRDs are not carved in stone and aren’t found in a cave high in the desert. They are not an end, they are a means. A means to communicate a vision. One thing that the Agile proponents clearly have right is that change happens. The market is a moving target. A vision for dominating that market better move with it. And the resulting MRD is going to change.

Product Managers are also not infallible. Left to our own devices, we will write some horrible requirements. We require feedback from the implementation teams in order to write great requirements. A great example is documenting what Kano would define as a “more is better” requirement.

Profit maximizing

The optimal point is not the revenue-maximizing feature, it is the profit-maximizing feature. We’re driven by ROI. We need an understanding of the cost function to combine with the price function to result in a profit function. We must solicit and respond to that feedback from our engineers.

This is the level of execution expertise that can differentiate our teams, and our products.

Summary

An MRD is critical to capturing product strategy information. Capturing the right information is critical. The goals of capturing that information are to disseminate the ideas, and for the team to collaborate on them. Techniques that make it easier for our target audience to read the MRD are important. And having a good approach to managing the document as it evolves is what can set us apart from other teams, or make us more competitive.

Product Managers Are Critical To Success

trophies

The product manager role is strategic. Product managers identify valuable problems in the market and determine which of them should be solved with software. They create a vision and strategy for solving those problems. Everything else happens in that context.

James Shore has written a post on the importance of staffing the team with a good product manager. James is recognized as a significant contributor to the Agile community. Several people struggle to rationalize the role of a product manager in an Agile process. Through this article and others, James presents a perspective that the product manager owns the vision.

Without the vision of a good product manager, the team is likely to flounder. It will spend time delivering functionality that isn’t really important. It will develop low-value, high-cost functionality at the expense of high-value, low-cost functionality. It may spend time “thrashing”–switching back and forth between multiple features, never really completing any of them.

Prioritization and direction setting is the element of product management that is most visible to the implementation team. Sometimes it can be easy to forget that there is huge value in positioning, persuasion and other outbound activities. Those elements of software product success seem to generally be out of scope when discussing Agile practices. The prioritization process is very much in scope. It determines which use cases get implemented in each timebox (sprint, release, iteration).
James closes his article with this great conclusion:

So… get a good product manager. If your company won’t commit the resources for this critical member of the team, maybe your product isn’t valuable enough to be developing in the first place.

We won’t try and improve on it. Thanks for the great thoughts, James!

Requirements Gathering – Interviewing the Right People

aliens

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”

It isn’t much different for most software users. Users don’t typically know what software can do, or don’t have the skills to synthesize software based solutions to their real problems. Users are rarely the source of innovative solutions. So how do we gather the real requirements?

We can make our user interviews much more valuable by talking to different users. We can use Geoffrey Moore’s Crossing the Chasm description of technology adoption as a basis for segmenting our users. Ken Norton proposes that we do exactly this, and combine the different perspectives to reach our conclusions.

Classifying Users

We use personas to identify different classes of users in a software system. We use those personas to drive feature prioitization and design decisions. When making design decisions, we focus on the level of competence of the users to prioritize features. When we are eliciting requirements, it is before we get to the prioritization stage, and we are still defining what the features might be.

We can use the same techniques to increase the value of our requirements elicitation efforts.

chasm

For any given role that we identify as a user of our software, we can use Geoffrey Moore’s classification to identify four distinct user archetypes (personas).

  • Innovators (Influencers) – people on the bleeding edge of the technology curve.
  • Early Adopters – our first customers.
  • Majority – most users of our software.
  • Late Adopters – people who follow the crowd.

There are pros and cons to interviewing representatives from each group. With Ken’s guidance, we can separate the wheat from the chaff and combine their inputs to drive innovative and valuable solutions. Our goal in these interviews is to understand the pain-points and market opportunities.

Innovators

  • pro – Innovators can prevent tragically bad mistakes. They can also help us to identify opportunities to solve problems most people don’t realize are problems.
  • con – Innovators struggle to distinguish cool from valuable. There is also a risk that they can fixate on something that is irrelevant.

Early Adopters

  • pro – Early Adopters easily develop a deep understanding of our products and goals. They can tell us in advance what problems majority users will face, and provide a bit of a sanity check on the ‘problems’ that innovators suggest
  • con – Early Adopters tend to be power users, and are genuinely enthused about our product ideas. They tend to gloss over the negatives and focus on the positives. They also tend to communicate in terms of features, not capabilities.

Majority

  • pro – Majority users can give us the best insight into what is painful. We can use this insight to drive market requirements and solution ideas.
  • con – Majority users don’t think about software, they think about how software affects them. We have to keep a focus on the problem not the solution when gathering requirements. We also have to dig deeper with why questions to understand the underlying cause of a particular problem.

Late Adopters

  • pro – Late Adopters avoid change. Use them to help us identify where we need better interaction design and more documentation.
  • con – Late Adopters will drive us towards “… just like product X” solutions. They will be disinterested in novel solutions until they are mainstream.

Triangulation

Ideas that survive the innovator-filter, make sense to early adopters, and solve a painful problem for the majority are the ones that we want. The late adopters won’t be using early versions of our software, so we can focus our attention on the other groups until we become the dominant solution. Then we can look to the late adopters to help us manage incremental improvements.

Thanks Ken for suggesting that we triangulate these perspectives into great ideas!

Conclusion

Even if we don’t go out in search of these archetypes, we should try and understand the people we do talk to, and put their inputs into the proper perspective.