Wrox Home  
Search
Adam Kolawa - Co-Founder and CEO of Parasoft
Adam Kolawa is the co-founder and CEO of Parasoft. Kolawa, co-author of Bullet-
proofing Web Applications
(Wiley, 2001), has contributed to and written hundreds of commentary pieces and technical articles for publications, such as The Wall Street Journal, CIO, Computerworld, Dr. Dobb's Journal, and IEEE Computer. He has also authored numerous scientific papers on physics and parallel processing.

Articles by Adam Kolawa

Making Your Requirements Management System Work for You

By Adam Kolawa, Co-Founder of Parasoft

The goal of the recommended strategies for using requirements management systems is to automate requirements management so that you can always determine whether a requirement is truly implemented. Some manual configuration is required, but the payoff is the ability to not only track requirement status, but also to automatically determine whether the requirements are implemented completely and correctly. By following the recommended strategies, you implement a requirements management system that not only tracks requirements, but also frames them with executable test cases that you can use to confirm how well the code satisfies the requirements at any given time. In addition to providing unprecedented objective insight into how well the code satisfies the requirements, this type of system also prevents the many rewrites that are often required as a result of requirement misunderstandings.

To get the most out of your requirements management system, follow these steps:

The architect should define the scope and test requirements for each new feature request, and then enter those details in the bug-tracking system.

For each requirement listed in the specification, the architect defines the scope of the feature requests, defines what tests he believes are needed to verify whether that feature is completely and correctly implemented, and then records this information in the team's bug-tracking system or requirements management system as a feature request. For example, the architect might record that a login functionality should be added, describe how this functionality should be implemented, and then require that the feature be verified with unit test cases, database verification test cases, and global test cases that track the transactions as it passes through the system.

The developer should add regression test cases for each feature request he is assigned as soon as that feature request is entered in the bug-tracking system.

Each feature request entered will be automatically assigned to a developer, using criteria set up in the bug-tracking or requirements management system. Once a developer is notified of a new feature request, he immediately designs incomplete test cases as specified by the architect's test requirements, and adds these test cases to the regression test suite. At this point, each of these test cases should return "incomplete" to clearly indicate that the related feature has not yet been implemented.

These test cases should be added to the project's test suite immediately, then run every night as part of the automated build and testing process. The test cases will fail until the developers implement the code implements the related feature. This ensures that feature requests are not forgotten, and that the code is not deemed "done" until these feature requests are implemented. The team can then track requirements by monitoring the failed requirements test cases and/or by monitoring the bug-tracking system's list of open feature requests.

After the developer implements a feature request, he should modify the test cases to verify the new feature, and then mark the request as "done."

Once the developer has added the code that implements a feature, he needs to flesh out the previously incomplete test cases to verify that the new feature is implemented completely and correctly. If the modified test cases pass, the feature is considered to be complete, and the developer should mark the feature request as "done" or "closed." If the modified test cases do not pass, the developer needs to modify the code before he can consider the request truly implemented.