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!

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?

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
Product Risk Analysis Clarifies Requirements

This presentation re-emphasizes that requirements are important. The difference between functional and nonfunctional requirements will be covered. Then, Product Risk Analysis will be described, along with the elements of the analysis and steps toward performing the analysis.

Jim Kandler
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
Escape from Documentation

Common practice says that software projects need documentation. But there's still something of a gap between the preaching and the practice. In small companies especially, managers may claim there isn't time to document, or that "Our project is different." Maybe some of these managers know something the rest of us don't know. Are there factors that might make a project exempt from documentation? I've thought of a few possibilities.

Sheryl Smith
The Innovative Tester

Historically, the development team considers themselves the creators of the system and the QA community is considered as a necessary evil, more so when there is an independent testing group. Since test engineers sometimes work in a hostile atmosphere, they need to equip themselves with more knowledge in both functional and testing skills. This article discusses the importance of developing those skills.

Gunasekaran Veerapillai's picture Gunasekaran Veerapillai


StickyMinds is a TechWell community.

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