|
The flexibility with which requirements are gathered and managed shows how disciplined an AD process is. AD organizations with automated requirements definition and management environments will better support change control, gain testing efficiencies and reduce future maintenance burdens.
WHAT YOU NEED TO KNOW
The manner in which requirements are gathered, stored and managed shows the level of discipline in an application development process. Agile approaches to defining requirements, a few at a time, have a place in "just enough" software process architectures. An AD organization with an automated requirements environment will better support change control efforts, gain testing efficiencies and potentially reduce its future maintenance burdens.
STRATEGIC PLANNING ASSUMPTION(S)
By 2009, automated approaches to supporting RDM will enable a reduction in the cost of AD quality by 30 percent (0.8 probability). By 2009, user satisfaction levels with medium-size to large systems that are developed with well-automated RDM processes will usually improve from "fair" to "good," or the equivalent (0.8 probability). By 2009, maintenance- and enhancement-phase costs for medium-size to large systems that are developed with well-automated RDM processes will decline by 10 percent (0.8 probability). By 2008, a growing market encompassing automated RDM tools will exceed $400 million in annual revenue for licenses, related services and maintenance (0.6 probability).
ANALYSIS
At a time when many large, internal application development (AD) organizations have turned to rapid AD (RAD) and NeoRAD (or "agile") approaches for 25 percent to 35 percent of their AD project portfolios, meticulous procedures for thorough application requirements definition and management (RDM) have become suspect. Many AD managers see such procedures as costly overhead ? that is, "analysis paralysis," which introduces unacceptable delays and undermines agile AD. On the AD side, in their eagerness to proceed directly to programming and avoid being perceived as slow, less proficient developers often practically skip the documentation of requirements. On the business side, business sponsors have often been unwilling to provide sufficient numbers of users for multiple joint AD (JAD) sessions to gather, define and validate requirements. As a result, expertise in requirements gathering declined as JAD fell out of favor during the 1990s. Lately, however, the general increase in the external sourcing of AD can pull the same AD organization in the opposite direction ? toward more-extended RDM, to structure contracts with external service providers (ESPs). When sourcing AD services from third parties, clear requirements specifications are necessary. However, these apparently opposing drivers can create tension in many AD organizations. When contracting with an ESP, an internal AD organization's business analysts and designers are best positioned to define and document application requirements. Their access to users isn't seen as billable time, but rather as a natural part of providing the requested system. Their understanding of business processes is often based on years of experience with the same company, often working on related applications.
In addition, their familiarity with the software "ecosystem" provides design expertise exceeding that of contracted AD service providers. More IT organizations in industries that are increasingly enabled by software (for example, financial, retail, communications and others) are realizing that relying on ESPs to capture, define and redefine requirements is often more costly than doing it internally and then coordinating with the ESP (if the programming is to be contracted ? offshore, for example). Regaining expertise in the "lost art" of requirements will reduce the risk and cost of building accurate systems with ESP assistance, and users will be more satisfied with applications that more exactly meet their primary needs. In addition, well-defined and managed requirements can help restrain application total cost of ownership, because staffs performing future maintenance and enhancement work will need less time and effort to identify system elements on which to work. The use of requirements tools ? which increasingly provide collaboration, simulation and other features and interfaces ? will amplify these savings and satisfaction benefits.
|
