Balancing Act

Reduce project development time by effectively capturing and managing requirements

By Tom Spitzer

Continued from Page 1

The Requirements Maze

Although it's not news that effectively managing requirements is the key to managing schedules, it's still a difficult thing to do. In the best-case scenario, when you build a product or application without understanding the true requirements, your users or customers will let you know what's wrong or missing when you show it to them. In the worst case, they will abandon or ignore the product or service. If you survive, you must add or change features in response to the new information, which will increase the cost and delay the effective release of the product. Slightly less damaging to the possibility of delivering on time is the tendency of the requirements to expand throughout the development process. As they expand, you need to invest time and effort into protecting the original scope or broadening the product.

When developing corporate applications, you can determine requirements by analyzing the corporation's business processes and reviewing task requirements and business rules with prospective users and management representatives. To be successful, business software products (whether delivered as a product or a service) need to support all of the scenarios that a customer may encounter within a given application domain. Further, they need to provide sufficient flexibility to support practices and rules that can vary substantially from business to business. When gathering requirements for products, teams need to gather requirements from several potential customers and then resolve inconsistencies between their practices and rules. As a result, I believe that specifying requirements for products is more difficult than for corporate applications.

Certainly the development team is going to be happiest and most productive if you create clear, comprehensive requirements before starting to design or build solutions. On the other hand, management gets extremely nervous watching the release date approach without much application code getting produced. Compressed within a four-month project window, this development scenario creates an extremely stressful situation.

We have been working with one of our clients, iTango Software, on tuning the development cycle to increase the comfort level of both parties. We are working to dovetail requirements-gathering with the development schedule so that we provide our development teams with the documentation they need, when they need it, but not sooner. Additionally, requirements analysts and designers are working closely to product requirements specifications in a format that feeds directly into the software design process.

Use Cases as a Requirements Vehicle

Use cases provide the most effective way to organize and prioritize requirements and deliver them to the development teams. These cases provide a vehicle for establishing traceability among marketing requirements, design, development, and testing. A "good" library of use cases clearly defines the various branches that may be followed through a task, and it clearly defines the relationships between the system under design and other systems with which it needs to interact. Although it can be a sizeable effort, producing a good library of use cases ultimately enables faster completion of the product. Developers can take these cases and quickly determine the responsibilities that each component must fulfill, and how each component must respond to other components. This process is the essence of software design. Once the design is complete, available development tools provide sufficient leverage to empower developers to build a great deal of functionality in a short time.

Although use cases are a necessary part of the requirements specification, they are not sufficient. Use cases are ideal for capturing interaction-driven functions, but it's difficult to shoehorn articulation of business rules and requirements regarding performance, uptime, training costs, and so on into use cases. While our team could do it, the results would be cumbersome. Instead, we created a catalog of business rules and a catalog of requirements and allowed analysts to associate rules and requirements to the use cases that they support.

Providing a Structure

Because most people are unfamiliar with using a relatively structured approach to documenting requirements with use cases, rules, and requirements, it helps to provide a consistent structure for creating and accessing them. To do so, our team created a database application with forms for entering these items and associating them with one another, and a set of queries and reports so analysts and designers can produce documentation on specific subsystems and functions.

On the first pass through the process, we aimed for breadth rather than depth. Our objective was to determine the scope of the system by capturing many use cases quickly, but not flesh them out with much detail. It took two people a couple of days to summarize the use cases for an employee benefits application that needed a supporting employee profile function that linked to several preexisting human resource systems. We were able to turn this set of use cases over to our project manager to start building a project plan and to the management team to make scoping decisions. A review of the use cases enabled us to assign "A, B, C" priority ratings to them. Next we added some meat to the "A" use cases and turned them over to the design-and-build team to start building object models.