Better Software Magazine Articles

Gathering Users for Great Requirements

If you buy a hammer, you are not considered a master carpenter automatically. The same holds true for tool knowledge alone solving requirements problems. Kelley Schmidt shares the biggest lesson she learned on a project: commercial process and tools alone cannot lead to project success.

Kelley Schmidt
Testing Your Software's Requirements

Many testing organizations focus primarily on software executable code, but that's not the only thing you can test. For instance, did you ever consider testing your software requirements? When you test only code, you face some big disadvantages, not to mention that design defects often aren't even fixable because they demand too much effort, too late in the release cycle. In fact, it's difficult to even report some requirements defects since the developers have already committed to the design strategy. But if you test your requirements early in the game, you can discover defects before they're cast into designs and code, consequently saving your organization potentially huge rework costs.

Brian Lawrence, Coyote Valley Software
Software Documentation Superstitions

Do you need credible evidence that disciplined document reviews (a.k.a. inspections) can keep total project costs down while helping you meet the schedule and improve quality? The project documentation we actually need should meet predetermined quality criteria, but organizations are often superstitious about writing this documentation-and they let their superstitions inhibit their efforts. This presentation dispels the superstitions and shows you how reinforcements for improving the quality of your software project documentation-such as requirements, design, and test plans/procedures-can occur through disciplined document reviews.

Gregory Daich, Software Technology Support Center
What's That Supposed to Do? The Archeology of Legacy Systems

In testing utopia, all software products submitted for testing have thorough and comprehensive documentation describing how every program function should work. On planet Earth, however, test engineers usually have to make do under less-than-ideal circumstances. It's not uncommon for test engineers to be asked to verify the functionality of a critical legacy system which has no documented requirements whatsoever. While there are many reasons this can happen, the result is the same: You assume the role of an archeologist sifting through the layers of clues to reconstruct the specifications. Patricia Ensworth gives you instructions and tools so you'll be ready to roll up your sleeves and dig.

Patricia Ensworth, Moody's Investors Service
The Road to UML is Paved with Good Intentions

A picture is worth a thousand words. Does that mean that a model is worth a thousand requirements? A thousand test cases? Not exactly, but a model will tremendously aid in the development of requirements and test cases, and help facilitate inter-team communication of requirements and test cases; at least, that's always the intent. One way to help ensure that these good intentions come to fruition is to test the diagrams that the model is composed of, for 4C compliance-completeness, correctness, consistency, and clarity. There are different languages for producing models, but this presentation focuses on the Unified Modeling Language (UML), and methods of testing models that are created with UML.

Dion Johnson, Pointe Technology Group
Modeling Practice and Requirements

Models are useful in different settings in different ways. Models can test facts, ideas and understanding, simulate operation, and aid coordination between systems and people. In this column, Becky Winant lists six model patterns she has seen in practice in software development organizations, talking about where each is appropriate, and the strengths and weaknesses of each.

Becky Winant
Analyzing Requirements Bugs

Analysis of bug reports from previous projects tells us about our most frequent errors, and can help us improve. But very few companies spend the time to analyze bugs from completed projects. Otto Vinter and Soren Lauesen explore using bug reports to improve the software development process.

Søren Lauesen
Visual Modeling with Rational Rose

Darren Pulsipher looks at Visual Modeling with Rational Rose. He concludes: "Rose is far from the perfect Visual Modeling tool, but it is definitely one of the best OO tools on the market, and the most popular. Rational Software has done a great job in supporting its tools with user conferences, training, professional services, and seminars."

Darren Pulsipher
Are Your Requirements Complete?

Every system contains at least one (and probably more) set of requirements that fits into one of these categories: the functional who, what, where, when, why, how, and the nonfunctional design and project constraints. No one method or technique captures all requirements, but this approach can assist quality engineers in identifying missing requirements. Our objective is to spot the gaps in the requirements sets—just as a Tetris player spots gaps in those moving blocks—as soon as possible.

Patricia L. Ferdinandi
Learning from Pathfinder's Bumpy Start

Steve March discusses problems experienced by the Mars Pathfinder. He imparts the following lessons: 1) design defensively in the face of complexity; 2) design defensively for post-shipment problems; and 3) beware of best cases.

Steve March


StickyMinds is a TechWell community.

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