Defining Requirements

By Doug Bartholomew  |  Posted 2006-08-10 Email Print this article Print
 
 
 
 
 
 
 

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.

Defining Requirements

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:

  • Elicitation. This includes not only collecting a list of business needs, but also what one consultant calls "invention and discovery" of requirements—i.e., delving deeper into the business to discern otherwise hidden or overlooked requirements.

  • Analysis. This involves deriving a detailed set of requirements and ranking them according to priority. Kaiser chose to include analysis as part of the specification step below.

  • Specification. In this step, each requirement should be written in a form that clearly communicates its meaning. The requirements analyst expresses each business need, capability or condition in writing and enters it into, say, CaliberRM, which becomes the hub of the RDM process.

  • Validation. This step ensures that developers have a good set of requirements that accurately meet customer needs. As a technique to improve validation, Kaiser is using Caliber DefineIT to visualize and validate elements of a system.

  • Requirements management. This step ensures that the organization has a process for dealing with requirements that change during a project, as well as a means to track its status over time. Kaiser uses the StarTeam SCCM tool to do this.

    In effect, the days when a software development team at Kaiser could go off and do its own thing—assuming it knew what the business group wanted—are 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 creep—what 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 requirement—coders, developers, testers and business representatives—is 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 access—both the I.T. team and the business people—was 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."

    NEXT PAGE: Kaiser Permanente Base Case



  • <123>
     
     
     
     
    Doug Bartholomew is a career journalist who has covered information technology for more than 15 years. A former senior editor at IndustryWeek and InformationWeek, his freelance features have appeared in New York magazine and the Los Angeles Times Magazine. He has a B.S. in Journalism from Northwestern University.
     
     
     
     
     
     

    Submit a Comment

    Loading Comments...

    Manage your Newsletters: Login   Register My Newsletters