As users persist with their gripes that applications built by corporate developers don’t meet their needs, IT managers are increasingly turning to tools and processes that can ease requirements definition and management efforts.
Several large companies and US government agencies say that, in recent months, they have bought or built tools to automate paper-based or verbal requirements-definition methods. Some businesses are also planning to integrate the requirements management process with the rest of the application development lifecycle to improve communication between users and developers.
The urgency to improve requirements management processes has prompted some companies to create new positions within IT departments to oversee such efforts.
Last year Ed Barkley was named to the new post of process improvement leader in the IT shop of a large health-care company that he asks not be named.
Barkley’s new role: to implement changes that increase end-user satisfaction with new applications developed inhouse. His first order of business was to overhaul the development operation’s requirements-management process.
“In many cases, we are not delivering to the customers what they want,” he says, noting that developers often wrongly assume that they understand the needs of their users.
“You see how the current requirements are being developed, [and] you discover that the requirements aren’t being understood or documented correctly, if at all, [by IT developers]”, says Barkley, who also heads the Kansas City Rational Users Group. “That is the beginning of the problem — [IT] people assume what the customer wants.”
Turning to templates
To help bolster the process at the health- care company, IT developers created requirements-management templates to provide users with a formal process for listing what they need in new applications.
The company began using the templates this month, Barkley says.
The company hopes use of the templates can first halt the practice of users passing their needs on to developers either verbally or in notes with large “paragraphs of rambling”, according to Barkley.
The new process also calls for users to approve work on an application at multiple stages of development, he says.
Once the system has been in place for an undetermined period, Barkley says IT will start auditing the process to determine whether user needs are being met and whether users are satisfied with the resulting applications.
If the audit determines that the new process is accepted by users and developers, he says, the healthcare firm plans to link the templates to IBM Rational’s RequisitePro requirements-management tool, which it has used intermittently in the past, he says. After that, the company will link the integrated requirements management process with the Rational testing tools it uses, he says.
Brian Kilcourse, chief strategist at Retail Systems Alert Group, a US-based IT research firm, says the inability to meet user needs at many large companies has offset recent major advances in software development technologies — such as integrated development environments and ever-improving code-generation tools.
“We’ve been in commercial computing for almost 50 years, and we’ve automated all kinds of tasks,” Kilcourse says. “But requirements management is the one thing we haven’t got to in any meaningful way.”
Kilcourse contends that a lack of communication between users and developers is the primary reason for the problem. “IT people don’t sit around designing things nobody wants because they are dumb or they are focused on malfeasance,” he says.
Indeed, Carey Schwaber, an analyst at Forrester Research, maintains that developer misunderstandings of user requirements are the leading cause of defects in software. Compounding the problem, she adds, is the emergence of globally-distributed development and government regulations, like the Sarbanes-Oxley Act in the US, that require users to prove that their IT systems meet business requirements.
The US Internal Revenue Service has been plagued with requirements management problems since it began to replace its tax administration and financial systems seven years ago, according to a report by the Government Accountability Office.
According to the report, released in March, cost over-runs and delays have plagued the US$1.9 billion (NZ$3.1 billion) IRS project. The report blamed inadequate development and management of requirements, among other things.
As the problems mounted early on in the project, the IRS, in October 2004, created the Requirements Management Office. However, the office doesn’t expect to have final requirements management policies and procedures in place until March 2007, the report says.
No more mind reading
Debra Jensen, vice president of system development at Jack in the Box, in San Diego, says the restaurant chain is currently evaluating requirements management tools as part of an initiative to overhaul the process of collecting requirements from users.
That effort began about a year ago, when the company started using internally built templates to collect user requirements. The process now demands that users formally certify that finished applications meet their needs.
The Jack in the Box IT requirements management overhaul was initiated because in the past, “there [was] a sense that IT should just know the business needs and write the requirements for [users],” Jensen says.
The need to comply with the Sarbanes-Oxley Act has been used by IT to further persuade users to embrace the templates. “We said the auditors were going to be looking for these requirements in writing,” Jensen says.
With the first phase of the new process in place and accepted by users, Jensen says, Jack in the Box’s IT department is starting to work under the philosophy that if business users don’t have time to define requirements, “we don’t have the time to implement them”.
Further down the line, Jensen says, the company plans to buy a business process engineering tool that will be integrated with the requirements management product it chooses. Such an integration promises to create a system that can automatically capture the various requirements associated with specific business processes, such as order processing, she says.
The Workplace Safety and Insurance Board in Toronto, which manages Ontario’s workplace safety initiatives and provides disability benefits, recently purchased IBM Rational’s Portfolio Manager tool to better align the requirements management process with the rest of the development lifecycle.
Vitalie Temnenco, an architect in the organisation, says the board plans to integrate the Rational tool with the SteelTrace Catalyze requirements management tool from Compuware, which the agency already uses.
Temnenco won’t speculate on when the integration project will start but noted that the board is planning to train its developers, business architects and requirements analysts to use the integrated toolset.
“If we feed all the requirements information into the portfolio management tool we’ll be able to provide for a quick turnaround of project data,” he says.
Clearer communication
New York-based OgilvyOne North America, the direct marketing arm of advertising company Ogilvy Group, plans to acquire an enterprise licence for the Catalyze tool before the end of this year, says Jonathan Karpoff, senior partner and director of information architecture at OgilvyOne.
The company currently has three individual licences for the software, he says. The number of developers using the tool will at least triple with the new licence, he says.
At the same time, Karpoff said OgilvyOne may soon integrate the Catalyze tool with Rational development, testing and quality assurance tools it is evaluating for purchase. Such an integrated system could dramatically lessen the number of communication mix-ups that routinely occur during telephone conversations between groups of users and development teams, he says.
The company has used Catalyze for the past year and a half to gather and manage requirements for the websites it builds for external clients. “It allows us to identify issues, conflicts, things that we and the stakeholders had not thought about previously,” Karpoff says.
The Requirements Management Business Analysis Centre of Competency at the Bank of Montreal has completed implementation of a requirements-management process and now plans to expand it to help the bank reuse user prerequisites, says Kathleen Barret, consulting manager at the centre.
Barret says talk of reuse only became serious after users accepted a formal requirements management process. “The business people really bought into the requirements process,” she says. “They are no longer saying, ‘Why do I need to do this?’”
The latest effort will begin later this year with the launch of several workshops to train the bank’s business analysts and developers on the need to document the requirements for certain business processes — like retrieving a customer profile — so that they can be reused, she says.
Barret notes that applications could have varying requirements for the same business process and, with 800 applications in production, reusing requirements could generate substantial savings.
“We need to articulate what is involved on a step-by-step basis in retrieving a customer profile [and] identify what will be automated and capture it in requirements,” Barret says.
The bank has been focusing on streamlining requirements management since 2003, when it identified the process as being the weakest in the IT shop, she says.