requirements gathering

Articles

Kill by Wire

Linda Hayes has worked in the software industry for a long time and through a lot of changes. But a series of recent events has led her to question whether the industry has changed for the better or worse. In this article, she recommends some attitudes we should lose and some we should adopt in order to save our software and—in some cases—our lives.

Linda Hayes's picture Linda Hayes
How Agile Practices Reduce Requirements Risks

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating those risks.

Ellen Gottesdiener's picture Ellen Gottesdiener
SDLC phases and activities Requirements Engineering: Our Best Practices

This article focuses on a methodology adopted during a requirements and functional specification phase of a project. The chosen model for requirements engineering was founded on a combination of six sigma techniques and a set of best practices adopted from within the organization.

Bonney Joseph
one way to categorize and organize questions Capturing Implied Requirements

Sometimes the user, project sponsor, and other key stakeholders haven't provided in the requirements documentation all the expectations of the software you're building. Instead, these expectations are only implied. In a perfect requirements-gathering process, there would be no such thing as an "implied requirement" because every requirement would be captured in the document. But no process is perfect, in theory or in practice. This article should help you look for and recognize the presence of implied requirements and learn how to capture them and convert them to documented requirements.

Robert Rose-Coutré's picture Robert Rose-Coutré
The Forgotten Side of Quality

Our perception of quality includes objective and subjective factors. In this week's column, Jeff Patton explains the difference between the two and proposes we forget those differences so we can start viewing the two as equals.

Jeff Patton's picture Jeff Patton
 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
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
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
Information Gathering

If your customer interview questions focus too narrowly on a problem that must be solved, you run the risk of missing information that could be critical to a successful outcome. In this column, Naomi Karten says playing detective improves your ability to gather information. To improve the odds of success, it's important to ask questions from multiple perspectives—and to pay attention not only to the customers' response, but to how they say it as well.

Naomi Karten's picture Naomi Karten
The Requirements Definition Process It Is Still The Requirements

Why are information systems requirements so difficult to define? What causes the yawning chasm between documented requirements and the actual implemented system? Requirements definition is difficult for two major reasons. First, the customer may have only the vaguest idea of what an information system should look like prior to implementation and use. Second, system developers lack sufficient knowledge of the business functions a system must support.

James A. Ward's picture James A. Ward

Pages

StickyMinds is a TechWell community.

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