Prioritization Puzzles: Practices for Prioritizing Product Requirements

Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement-or whether you should delve into them at all-you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this week's column, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with.

Ellen Gottesdiener's picture Ellen Gottesdiener
When Requirements Collide

Could it be that not every set of business requirements has the customer's best interest in mind? Karl Wiegers had always believed that implemented software functionality should enable users to accomplish their goals and help the business achieve its objectives. But a recent experience with a less-than-helpful parking meter system suggested to him that conflicts sometimes might exist between business and user requirements.

Karl E. Wiegers
Building Requirements Quality through Coverage and Testability

As we look to deploy or improve a requirements practice, the output should lead to a set of complete and quality requirements. A way to get there is to ensure that requirements have been captured in all pertinent categories and are testable. Often times, requirements focus on user needs and limited functional areas. But what may be overlooked are lesser requirements categories (e.g., security, usability, etc). It is therefore essential to capture requirements that ensure coverage in the requirements space.

Mario  Moreira's picture Mario Moreira
Requirements Issues Found During Acceptance Test Do Your IT Projects Suffer from Requirements Clarity Issues?

Vague or missing requirements are a frequent source of delay when planning and managing testing and result in system defects and omissions, difficulties estimating test effort, and precious time spent getting clarity. In this article, Clare Roberts shares insights from recent projects, including checklists for spotting gaps in requirements and suggestions for prevention.

Clare Roberts
 Factors Influencing Requirements Adaptation Tailoring Requirements Development and Management

In part 1 of this article (published as a weekly column on May 22), Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management.

Ellen Gottesdiener's picture Ellen Gottesdiener
Bridging Documents

Are your developers and testers happy with the requirements
specifications they get from the business analyst? If not, maybe your documentation isn't properly bridging the gaps between requirements, construction, and testing. In this week's column, Karl Wiegers explains that one should write documents from the perspective of the downstream consumers of the information, not from the author's point of view.

Karl E. Wiegers
brain with headphones Adapting Your Requirements Practices

Should your requirements practices embrace the change-driven approach of agile methods--lightweight models, minimal documentation, and little process? Or should you take a risk-driven approach--robust models, careful validation, and rich documentation? In this two-part weekly column, Ellen Gottesdiener explains that you should tailor your requirements practices to your project and product.

Ellen Gottesdiener's picture Ellen Gottesdiener
Write a Blockbuster Using User Scenarios

Big projects require many little user stories. But if these scenarios don't add up to one good story, then you're probably missing out on the big picture. In this week's column, Jeff Patton describes how his team weaves many small tales into a single strong report by identifying key characters and themes.

Jeff Patton's picture Jeff Patton
Using Mocks to Verify Interactions

In the March 2006 issue of Better Software magazine, Dan North began a discussion of the evolution of behavior-driven development from test-driven development. Here, North continues the conversation with closer look at "mocks," utility classes that, for testing purposes, pretend to be some component or service with which your object will interact.

Dan North's picture Dan North
swing hanging from tree Finish on Time by Managing Scale

When deciding how a user's task is to be supported in our software, we often look at possible design solutions and select one that's best for the product and the user. As the project deadline approaches, however, we might choose to dismiss some features outright. In this column, Jeff Patton suggests we try keeping more features by adjusting their scale.

Jeff Patton's picture Jeff Patton


StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.