Defining RequirementsBy Doug Bartholomew | Posted 2006-08-10 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce REGISTER >
HMO Kaiser Permanente needed tighter alignment between its software developers and its business goals. A new requirements management system proved to be strong, but effective, medicine.
In general, a software "requirement" is a capability needed by a user to accomplish something with a product. The requirements definition process encompasses all the activities that analysts and business representatives go through to identify the necessary requirements for a software application.
Historically, a business analyst performed the "requirements definition" step in the software building process by talking to users and finding out what they needed. Not surprisingly, the ad hoc nature of this procedure tended to yield mixed results. Some projects failed because of a lack of business knowledge and an inability or unawareness on the part of business users to adequately communicate their needs to analysts.
In many instances, large companies hired consultants who brought in their own analysts, who often knew a lot about software but not much about the specific business or its industry. "I'm not a fan of bringing in analysts for hire," cautions Karl Wiegers, principal consultant at Process Impact, a software process consulting and education firm in Portland, Ore., and the author of books on requirements development. "You need people who can ask the right questions. Business domain knowledge is very useful for this process."
Not all companies, though, have rigorous requirements definition and management processes. "Most organizations have come to understand that requirements are critical to a software development project's success, but don't do very well at it," says Wiegers, whose books include Software Requirements and More About Software Requirements. "They realize they have to get better at this."
Before adopting the new process last October, Kaiser tracked software development projects on paper. Projects were managed on an ad hoc basis. "The details of how developers gathered requirements were never that clear," Cannon says.
So, many projects suffered from late changes, cost overruns and missed completion dates. "With the scale of projects at Kaiser Permanente often being massive, discovering issues late in the life cycle has huge impacts on time and cost," Schleifer says.
Projects that came in late, for example, typically ran well over budget. "We knew we needed to increase the quality of our development process and reduce late charges," Schleifer says. Unfortunately, he adds, "There's always been this rush to get to coding, rather than spending the time up front to do the due diligence on requirements."
For Kaiser, a major pitfall in its former process was a lack of detailed review by the project team. "This was a hole in the process previously," Schleifer explains. "The requirements would be sent to managers to sign off on, but they did not look at the details. With our new system, both the developers and the testers can work off this detail."
To help improve its requirements definition and management (RDM) process, last fall Kaiser began using Borland's RDM system and today is using Borland's full suite of RDM products. These include CaliberRM, a database for requirements development and management; StarTeam, a software change and configuration management system to keep track of changes made to a system over time; and Caliber DefineIT, a requirements definition tool that allows analysts and business users to collaborate on creating and changing requirements. DefineIT also permits textual input to be automatically diagrammed into a business process model based on requirements.
Of course, Borland's RDM products can't specify the requirements. "Our developers and technical people determine the quality of the requirements," Schleifer says. "The tool isn't going to spit out a well-written requirement unless they put it in there."
Requirements development and management generally encompasses five sets of activities:
In effect, the days when a software development team at Kaiser could go off and do its own thingassuming it knew what the business group wantedare history. Instead, developers are now required to follow the new process to define project requirements, as well as use the new system to document and track the definition of requirements before a single line of code is put on the screen. "All new projects as of Jan. 1, 2006, are expected to adopt this process and this tool," Schleifer says.
Moreover, those software-building mavericks who would jump the gun and move right to the design phase will be corralled and broken of the habit, because as of the first of the year, all Kaiser development projects must toe the line by using this new process as their standard for development.
"We are making a clear distinction between requirements and design," Schleifer points out. "People tend to jump to the solution before they've defined the problem and the need. In the past, when we had a paper-based requirements process without much structure, there was a tendency to jump into the solution."
Whenever possible, Kaiser wants to reuse a set of requirements, rather start from scratch with each development project. The HMO redesigned the RDM process first, because all other activities depend on that effort for their success.
Most software development experts agree that "scope creep" is next to inevitable for large projects. "That's why we have a process for change control," Schleifer says. "This way, project managers can look at each change request and understand the impact it will have on cost and time line, as well as how far back in the process they need to go to implement the change."
Realistically, Schleifer accepts the fact that development projects will have late-in-the-game changes. "You will still have project managers pushing scope creep, but now we are able to show them why a project is two months late and half a million dollars over budget, and show who signed off on it," Schleifer says. "We can say, 'Midway through the development, you changed two-thirds of your requirements.'"
Consultant Wiegers concurs that scope creepwhat he calls "the uncontrolled growth of requirements over time"is a reality that must be part of an organization's plan. "The problem is that organizations often don't accept the reality of change, and that requirements will grow," he says. "They need to accommodate that change and have mechanisms to deal with it."
A project will occasionally suffer a last-minute hit below the water line when someone discovers that a key requirement has been omitted. "It's more than simply embarrassing if you find out the requirement that was left out was the one that, for instance, turned on a patient's respirator," Wiegers says.
At the heart of the Borland system is a requirements database. Because the system is event-driven, everyone involved in developing a requirementcoders, developers, testers and business representativesis alerted via e-mail when there is a proposed change to that requirement. The system also indicates other requirements that would be affected by the change.
"People can post changes to the requirements, and everyone can see those changes," Schleifer says. "Members of the team can conduct their review directly in the tool, which saves time and reduces the chance of requirements getting lost." Adds Klassen, "This tool maps the process, enabling users to review different business scenarios, which helps in the validation process."
Developers Weigh In
Although it's too early for Kaiser to report any measurable results, the company received positive comments in an informal survey of business unit representatives who worked on requirements for one project that used the new process and technology. Kaiser shared those results with Baseline.
"Having predefined requirements helped reduce confusion during the specifications process," wrote a representative who helped define requirements for the company's new broker sales compensation application, which is used to compensate outside salespeople offering Kaiser health-care plans to new clients.
Added a developer, "It brought us a greater degree of confidence with our business customers." Wrote yet another, "Having a repository of business requirements that we all could accessboth the I.T. team and the business peoplewas helpful." A core team ranging from six to 12 analysts and developers, working with business user representatives, created the requirements.
Unlike in the past, when Kaiser's software development projects would be held up at the eleventh hour because a business requirement had been omitted inadvertently, the new process ensures that all necessary business functions are included from the beginning. As Schleifer puts it: "We joke among ourselves about 'no requirement left behind' being our charge."