requirements

Better Software Magazine Articles

Rock, Paper, Scissors: How Testers Uncover Hidden Requirements

The requirements process is not a linear one. In this article, Michael Bolton helps you get in the game by showing how the elements of the requirements process–reference, inference, and conference–interact and influence each other.
Michael Bolton's picture Michael Bolton
November 28, 2006
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
November 21, 2006
A Tester's Role in Agile Projects

Some agile methodologists claim that testers are not needed in agile projects--all testing is done either by developers or users. Chris Hetzler has seen the effects of that approach, and they are not pretty. When customers find
bugs in large projects, the costs can be staggering. Chris believes that testers must be involved in agile projects at an even higher intensity since timelines are shorter and the risk of failure is higher. But Chris explains that testers' roles change and testers must be prepared for that change. In agile projects, the testers' role is one of quality engineer rather than the traditional product
Chris Hetzler, Microsoft
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
September 21, 2006
A Metrics Dashboard to Drive Goal Achievement

Some measurement programs with high aims fall short, languish, and eventually fail completely because few people regularly use the resulting metrics. Based on Cisco Systems' five years of experience in establishing an annual quality program employing a metrics dashboard, Wenje Lai describes their successes and challenges and demonstrates the dashboard in use today. He shows how the metrics dashboard offers an easy-to-access mechanism for individuals and organizations within Cisco Systems to understand the gap between the current standing and their goals. A mechanism within the dashboard allows users to drilldown and see the data making up measurement to identify ownership of issues, root causes, and possible solutions. Learn what programs they implemented to ensure that people use the metrics dashboard to help them in their day-to-day operations.

  • How to build an effective metrics dashboard to help achieve quality goals
Wenje Lai, Cisco Systems Inc
Why Are Requirements So Poorly Defined?

Studies have shown that the quality of the requirements is one of the most important factors in the quality of an application and also in the time and costs required to deliver a system. Yet requirements are almost always ambiguous, incorrect, incomplete, too high level, logically inconsistent, and communicated by rumor. The irony is that the various techniques-which have been around for decades-for writing better requirements have not been widely adopted. The culture and the management of the software process are equally to blame. Richard Bender gets to the root of the problem and discusses ways to address the poor requirements issues. Learn quantitative measures of the quality of the requirements specification and practical approaches to writing unambiguous requirements for your applications.

  • Early validation of requirements through testing
  • Moving user acceptance test design up prior to the start of coding
Richard Bender, Bender RBT Inc.
User Stories for Better Software Requirements

The technique of expressing requirements as user stories is one of the most broadly applicable techniques introduced by Extreme Programming. In fact, user stories are an effective approach on all time-constrained projects, not just those using Agile methods. Mike Cohn explains how to identify the functionality for a user story and how to write it well. He describes the attributes all good user stories must exhibit and presents guidelines for writing them. Learn to employ user role modeling when gathering a project’s initial stories. Whether you are a developer, tester, manager, or analyst, you can learn to write user stories that will speed up development and help you deliver the systems that users really need.

  • Defining a user story and learning how to write one
  • Six attributes of all user stories
  • Thirteen guidelines for writing better user stories
Mike Cohn, Mountain Goat Software
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
June 2, 2006
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
May 25, 2006
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
May 19, 2006

Pages

StickyMinds is a TechWell community.

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