requirements management


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
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
The Trouble with Tracing: Traceability Dissected

Traceability! Some crave it. others cringe at the very mention of it. For hardcore configuration managers and requirements and systems engineers, it is a fundamental commandment of “responsible” software development. For many hardcore agilists and other developers, the very word evokes a strong “gag” reflex, along with feelings of pain and frustration. Traceability requires work and discipline! So how does traceability add value to our business and how can we make it easier?

Requirements-Based Development: A Software Configuration Management View

It seems so obvious that we should develop systems based on requirements, and yet it turns out to be rather hard to do and thus many organizations are doing it very badly. From a software configuration management standpoint, we could perhaps leave the whole process of requirements engineering to one side and focus on the management of requirements and thus the aspects of change control and traceability. That would perhaps be unduly ducking the issue, and, of course, we can’t resist giving an opinion anyway!

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

Ponder for a moment the impact of mints on your life. They provided an extra degree of confidence during some of life's most important moments from job interviews to first dates. Some people may even have a spouse and kids because a mint helped out in a crucial moment. In this column, Dion Johnson points out that the requirements improvement techniques called RequireMINTs can similarly impact the life of your software projects because like mints, they are small, refreshing, and effective.

Dion Johnson's picture Dion Johnson
What Is a Customer?

When we communicate, the words sound familiar so we think we understand each other. But understanding fizzles when we attribute different meanings to the words we use. In this column, Naomi Karten illustrates how differences in the way departments and companies define their terms can cause confusion, flawed conclusions, and faulty decisions. Naomi asks us to question the meanings of terms before starting a project to ensure that we understand what's called for.

Naomi Karten's picture Naomi Karten
Writing Requirements Documentation for Multiple Audiences

When writing requirements documentation it's important to consider your audience. In this article, the author shows you what questions to ask yourself when you're preparing your project plan.

Susan Wensel's picture Susan Wensel


StickyMinds is a TechWell community.

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