Normal 0 false false false MicrosoftInternetExplorer4 Do you face out-of-control software development projects? Completed software that doesn't meet users' needs? Consider requirements management, a discipline which helps deliver on-time and on-budget software which meets users' real needs. By Mathew Schwartz Does the software you develop meet your users' or customers' actual needs? Practically every piece of software built today is new, in the sense that it utilizes new techniques, tools, or technologies, and solves problems existing software can't handle. Accordingly, many software development efforts are "educated guess" affairs. Business analysts chart users' problems, and developers try to code software to solve those problems. Everyone, to some extent, is learning as they go. Frequently, however, developers run into one of two complications: they produce software with too much functionality ¿ users don't need and won't use all the bells and whistles ¿ which means development time was wasted; or else the software doesn't meet users' real needs, leading to delayed, costly projects and software which, when delivered, may be solving last year's business problems. Fed up with the continuing stream of software projects that over- or under-shoot, many project and product managers are turning to requirements management. Simply put, requirements management is the discipline of managing a project by correctly gathering, disseminating, applying, and verifying that software meets users' requirements. Building the Right Software The purpose of software development is clear enough: "to deliver working code that solves customer problems," notes Dean Leffingwell, co-author of Managing Software Requirements: A Unified Approach (Addison-Wesley, 2003). Yet building software is incredibly difficult ¿ no matter whether you're working for an independent software vendor (ISV), or on a company's in-house software development team ¿ because it involves accurately gauging customers' requirements. Thus the job of requirements management is "to mitigate the risk that requirements-related issues will prevent a successful project outcome," says Leffingwell. "If there were no such risks, then it would be far more efficient to go straight to code and eliminate the overhead of requirements-related activities." Managing requirements throughout the project lifecycle helps projects succeed. According to requirements management expert Harold Halbleib, "effective requirements management helps to control quality, cost, organization, and schedule, thus substantially improving your odds of a successful project." Requirements Management Techniques How does requirements management work? In general, you gather four sets of information:

• User ¿ Tasks users must perform.
• Technical ¿ The hardware and software environment.
• Business ¿ All business goals such as higher revenues and increased efficiency.
• Functional ¿ How the product will be built.

Techniques for gathering this information must be tailored to the project at hand, and in particular designed to defuse any potential risks the project team will encounter. As noted in Managing Software Requirements, such techniques include:

• Interviewing ¿ Identify stakeholders and their actual needs.
• Requirements workshops ¿ Achieve consensus between stakeholders.
• Brainstorming ¿ Find innovative new approaches.
• Storyboarding ¿ Ensure the product meets actual needs.
• Use cases ¿ Verify the product will meet users' real needs and work styles.
• Change management ¿ Manage the impact of changes the software will produce.

Requirements Management Tools A variety of tools and techniques exist to help manage requirements, though they tend to be specific to the development methodology used. For example, more traditional software development practices ¿ including Waterfall and Spiral methodologies ¿ are plan-driven: they specify all requirements up front, build a project plan, then commission technical staff to meet that plan. Accordingly, requirements must be precisely specified ¿ indeed, near-perfect ¿ or else developers may create over-engineered software which meets the wrong needs. Some of the tools used for plan-driven requirements management include Borland CaliberRM, Compuware SteelCase, IBM Rational RequisitePro, Mercury's Quality Center, and Telelogic DOORS. By contrast, so-called agile development techniques, including Crystal, Extreme Programming (XP), Lean, and Scrum, are predicated on not knowing all requirements, and expecting requirements to change during development. Accordingly, agile software development teams tend to prioritize requirements, then tackle the highest priorities first, delivering new software in short intervals (typically 1-4 weeks), with each iteration vetted by users. If users sign off on an iteration, that requirement is complete. Otherwise, user feedback guides further development. Ongoing requirements management is essential for agile projects since anything can change at any moment. Accordingly, useful tools tend to be less focused on creating and disseminating a plan, and more on rapid collaboration. Such tools, then, may include spreadsheets, wikis, dedicated agile software development tools, or even the tools used for more plan-driven software development (though they may be overkill). Requirements Exercises for Agile Teams As noted, requirements management includes the process of collecting user requirements, typically dubbed "use cases" or "user stories." Simply put, these record everything a user needs to do, such as "print the security report on standard-size paper for archiving purposes," but preferably without going into too much detail about how developers should realize this feature. For agile development teams, after collecting these user stories, "typically, there are a couple of exercises that boil to the top," says Ryan Martens, founder and chief technology officer of Rally Software Development Corp., which offers agile software development and requirements management products and training. First, he says, write a high-level data sheet detailing what the product needs to accomplish. Then create a product box with the high-level marketing detail: note the value, the audience, the top six features, and the technical specifications. He recommends actually creating this product box. "Cover a cereal box with paper, and use crayons, to make sure metaphorically it's the right approach," he says. Better make four or five. If users reach a consensus on one of the product boxes, developers can start coding. Otherwise, make more. A product box focuses developers on delivering a software application that meets the highest-priority requirements first. Lesser requirements may be handled later, or users may decide such features aren't even needed. This is the beauty, then, of applying requirements management: to deduce the most successful approach, for the least amount of time, effort, and money. Mathew Schwartz is a freelance business and technology journalist based in Cambridge, Mass.