| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 |
||||
|
|
|
||
|
||||||||||||||||||||||||||||||||||||||||||||||||
 TEST CENTER Requirements set the mark By Bruce Abbott, For InfoWorld Test Center March 2, 2001 Good software development depends on good requirements management. Take a collaborative approach to gather and refine requirements, and your software projects will finish on time and within budget
Yes, even my grandmother knows that software often fails to live up to its promises. But of course her software problems are nothing compared to those of the average U.S. corporation. According to the Standish Group, a research firm based in West Yarmouth, Mass., 31 percent of software projects are cancelled before they ever reach a customer's hands, and 53 percent ultimately cost 189 percent or more of their original budgets. Software projects that do get completed by the largest American companies typically retain only about 42 percent of the features that were originally proposed. The primary culprits are bad requirements. Requirements are the expression of the needs and desires of all the stakeholders in a software development project. They include everything from an application's basic functions to esoteric capabilities that end-users wish for but may not get. Bad requirements come in a variety of forms, reflecting poor understanding of the business processes to be addressed, insufficient detail for developers to do their jobs, and insufficient feedback from customers over the life cycle of a software project. Dean Leffingwell of Rational Software estimates that between 40 percent and 60 percent of software defects and failures can be attributed to bad requirements. Although a certain failure rate was acceptable in the past (hey, if the payback is 10 to one, why not roll the dice?), current economic realities dictate that we do a better job of managing software projects and software requirements. Typically, requirements are gathered by the project leader who interviews all concerned: the paying customer, end-users of the different parts of an application, indirect users who are affected by the results of the system, various levels of management, developers, system architects, and quality assurance staff. This process results in a requirements document that serves as the main driver for a successful software project. The requirements document can then provide the basis for testing, documentation, and system acceptance. When payment depends on acceptance, customers both inside and outside the organization are often surprised at how well the requirements meet their needs. So if we all know how important requirements are, why don't we begin software projects by gathering thorough requirements? (See our related illustration, "Not all requirements are created equal".) The hurdles Part of the problem rests with the developers themselves. Fish like to swim, birds like to fly, and true to form, developers like to develop -- not gather requirements. Developers often have difficulties seeing a problem from the business manager's or end-user's nontechnical points of view. Many are more interested in the latest technology toys than in understanding a business process. Consequently, development often begins before the requirements are understood. When that happens, we like to call it "premature compilation." What you get is a big mess and unsatisfied customers. At the same time, the customer who is not familiar with the software process does not always understand the value and necessity of creating a clearly documented set of requirements before the actual software development begins. The same person who wouldn't think of building a custom home without a clear set of blueprints often thinks a multimillion dollar software project can be built without detailed requirements. Even if customers recognize the importance of documenting the requirements at the outset, they typically express their needs and desires for the software in terms that aren't easily translated into the formal requirements the development team needs. In other words, the problem is exacerbated by the lack of a common language between customers and developers. For example, we all have a pretty good idea of the design options for a kitchen. Although there is still latitude for interpretation, we can easily describe and understand the various types of stoves. We can touch them, measure them, even operate them. Such shared knowledge is not always true of software. So even when software developers and users do talk, they may not be talking about the same thing. Users can't easily articulate something they haven't seen, and developers may not have the skills to elicit responses. Communication breaks down. Furthermore, paying customers often don't want to sit in a meeting with a bunch of highly paid developers. They see eight taxi meters zinging along, racking up the dollars. They've already described what they want the system to do, and if they are paying these people so much money to do it, they should be able to just get on with it. Bridging the gap Of course, the customer is never wrong. For that reason, the software project leader must bear the responsibility of making sure that customers and stakeholders understand the need for requirements, that requirements be discussed in a clearly understood common language, and that requirements be in place before the project begins. Dominick Perritano, lead software engineer at IAS, an Oakland, Calif.-based asset management solutions provider to the shipping industry, believes "a requirements document should allow a smooth and seamless flow through the development process, where it becomes easy to trace the requirement from analysis to design to development and, finally, to testing. By breaking the application into a set of logically partitioned requirements documents, or use cases, you can easily delegate development tasks and group tasks by release." Karl Wiegers, principal consultant at Process Impact, a software process consulting firm based in Clackamas, Ore., goes so far as to propose a software customer's Bill of Rights. But along with these rights come responsibilities; developers who make these promises may expect something in return. Whereas customers have the right to expect analysts to speak their language and to learn about their businesses and objectives for the system, they also have the responsibility to educate analysts about their businesses and to define business jargon. Customers must also provide domain experts to explain the various business processes that are being modeled by the software. The customer's domain experts should remain closely involved throughout the project. Even under the best of circumstances, many key decisions must be made during the development phase, often by a developer who was not involved in the gathering of requirements. For their part, developers must change their mode of working with the customers and users of the system by fostering more frequent communication. At the very least, the time between development and user feedback must be short. Development teams should also structure the information presented during requirements elicitation into a written software requirements specification. This means the customer must plan to provide requirements, clarify them, and flesh them out. Customers must also be detailed and precise when providing input about the system's requirements. The customer must be told at the outset that ongoing demands will be required of their time and resources. In return, they can expect clearly defined requirements which will greatly increase the project's chances for success. Requirements management software can provide a framework for a formal requirements process in your organization. Just make sure the product suits your needs without becoming a project unto itself. Features you should look for are team-based collaborative input, storage of documents in a variety of formats, and the capability of tracking the requirement attributes essential for your project. Some of the more popular products on the market are RequisitePro from Rational Software, OnYourMark Pro from Omni-Vista, RDT from Igatech, and Vital Link from Compliance Automation. Rolling with the changes Changing requirements is the major cause of software project cost overruns. Alan M. Davis, author of Software Requirements: Objects, Functions, and States, estimates that a requirements change in the development stage costs five times more than if it were ferreted out in the gathering phase. Changes that occur after a product is in production can impact costs by a factor of 100. But how can requirements be nailed down in exact detail when the customer has difficulty imagining and articulating what is needed? In many cases, customers are not aware of the options available. Prototypes or storyboards can elicit responses from customers that are especially useful for gathering GUI requirements. A simple mock-up of the user interface without the internal logic is presented to the customer. It doesn't have to be anything complicated. Sometimes simple drawings will suffice. The more the customer can interact with the prototype, the more likely the project leader will be able to gather clear and specific requirements. As any project progresses, customers are sure to change their minds or make new requests. This is a good thing, especially if changes are anticipated and managed properly. Sometimes the business process changes. Sometimes, after working with early versions of the software, customers discover new possibilities for valuable features. Short iteration cycles, which encourage users to use the product early on in the development cycle, help to minimize expenses. Good documentation of initial requirements serve to clarify where, when, and why changes occur, and additional changes become easier to understand. Understanding the value of good requirements and managing them well can be the single biggest factor in lowering the cost and improving the success rate of software projects. Good requirements start with an active project leader who anticipates change, customers who understand their role in the process, and developers committed to understanding the customer's business needs. In the end, a collaborative, team-based approach on the part of both customers and developers will result in good software and a successful software project. Related article: Teamwork is the key to remote development Bruce Abbott (heyabbott@mindspring.com) is a self-employed Java developer.
 RELATED SUBJECTS  Software DevelopmentSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
