Archive of Requirements Articles

January 5th, 2010

Most Engaging Articles of 2009

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.

Read the rest of the article…

Post to Twitter Post to Facebook

November 30th, 2009

Attainable Requirements

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.

Read the rest of the article…

Post to Twitter Post to Facebook

November 3rd, 2009

Design-Free Requirements

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.

Read the rest of the article…

Post to Twitter Post to Facebook

September 28th, 2009

Kano Analysis for Product Managers

Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems.  I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.

Read the rest of the article…

Post to Twitter Post to Facebook

August 3rd, 2009

Concise Requirements

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.

Read the rest of the article…

Post to Twitter Post to Facebook

July 29th, 2009

Valuable Requirements

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.

Read the rest of the article…

Post to Twitter Post to Facebook

July 6th, 2009

Writing Complete User Stories

User stories can make requirements management a lot easier.  They shift some of the communication from up-front documentation to ongoing dialog.  That’s the main reason they work so well for agile teams.  And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?”   The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough.  Add a small dose of traceability, and you can easily validate the completeness of your user stories.

Read the rest of the article…

Post to Twitter Post to Facebook

June 22nd, 2009

User Goals and Corporate Goals

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

Read the rest of the article…

Post to Twitter Post to Facebook

April 29th, 2009

Personas Make Blue Ocean Strategy Proactive

Blue Ocean Strategy provides an interesting reactive analysis of companies and markets.  Personas are used to understand your customer’s needs.  Combining the two provides powerful proactive insights when positioning your product for market success.

Read the rest of the article…

Post to Twitter Post to Facebook

April 22nd, 2009

You Must Not Write “The System Shall…”

A lot of books and blogs and experts tell us to use “The System shall…” when writing requirements.  Read on to find out why that’s not a very good idea.

Read the rest of the article…

Post to Twitter Post to Facebook