Requirements Streamlining

Introduction

With a federal budget deficit estimated at over $14 trillion, many government agencies are facing drastic budget reductions. Program offices have, accordingly, come under pressure to simultaneously increase performance and effectiveness while reducing costs and maintaining accountability. Information Technology requirements often impose unnecessary costs and can be cut to meet budget goals; program offices, however, require experienced analysts and advanced data tools to determine which IT priorities can be funded with a decreased budget and which must be deferred or foregone.

In this white paper we introduce a streamlining process that helps answer one of the main questions within a program office: “Are we focusing on the most critical requirements and investing in the most appropriate capabilities?” In today’s environment of tightening budgets, the answer to this question may mean the difference between continuing a program and terminating it. Our process allows programs to focus resources on fulfilling the most important requirements while deferring or removing those that provide less “bang for the buck.” Our aim is to meet budget constraints by trimming requirements (and thereby software size, effort, and cost) to only the most necessary.

Many program offices attempt to screen requirements without fully analyzing their benefits and costs. These efforts can be lengthy and costly, failing to generate meaningful discourse on the relative value of the requirements in consideration. Our 4-step process provides real-time feedback on progress toward meeting the budget goal, while simultaneously facilitating solid justification for the necessary changes using both visual aids and analysis. By following this process, program offices can make informed decisions on technical requirements, and thereby reduce workload and resource costs.

The steps of the process are as follows: 1) Screen and highlight requirements; 2) Analyze benefits and costs; 3) Plot relative values; and 4) Compare costs to the program budget.

Step 1: Screen and Highlight Requirements

Over time, program needs, business rules, and policies can change. To avoid operational inefficiencies, program analysts must ensure that requirements have not been superseded and are still desired by the user community. Accordingly, the first step of our process is to review program requirements for obsolete items.

In this preliminary reviewing stage, program managers should review deliverables (usually recorded in the Functional Requirements Document) to ensure that all requirements originally identified are still pertinent. Similarly, managers should compare requirements against the strategic goals of the organization. In many cases, a requirement may be misaligned with mission goals, tackling a problem that falls more logically under the jurisdiction of another department. These requirements add excess baggage and should be archived to boost efficiency.

Requirements often cannot be deleted due to policy, regulation, public law, agency agreements, or binding relationships with other requirements. Such entrenched requirements should be segregated and identified as non-discretionary. When comparing requirement costs to the program budget (Step 4), these items are considered an immoveable bloc that cannot be cut. The remaining items form the analysis “trade-space,” consisting of those requirements that can be deferred or eliminated. Tables 1 and 2 list mandatory requirements (highlighted in red) and trade-space requirements (not highlighted).

Step 2: Analyze Benefits and Costs

To ensure accurate screening of requirements, program managers must conduct individual assessments of the benefits and costs of each requirement. These assessments should be conducted through group sessions facilitated by an evaluation team. Ideally, this team should be composed of Subject Matter Experts and other relevant program personnel.

To perform benefit assessments, the team can employ a variety of methods, including pair-wise comparisons, rank ordering, and benefit/penalty valuation. Logapps, LLC prefers to employ benefit/penalty valuation, which assesses both the relative benefit of having a requirement and the penalty for not having it. The output of this process is a normalized benefit score for each requirement based upon the aggregation of assessments. Table 1 illustrates the benefit/penalty valuation process.

Next, we use a multi-step process to estimate requirement cost based on the effort and labor rate needed to satisfy each requirement. The requirement cost is first measured in terms of function points or Source Lines of Code (SLOC). For each requirement, we estimate the effort required to successfully deliver the corresponding amount of code, taking into account environment, developer capability, and other factors. The resulting person-month effort is then applied to a composite labor rate to arrive at an overall cost, as shown in Table 2.

To estimate software costs, we employ parametric cost estimation tools, such as COCOMO, Price-S, and SEER. If they exist, current project or program cost estimates can be leveraged to generate much, if not all, of the cost information. To ensure data reliability and accuracy, software sizing and cost estimation should be performed only by personnel with significant experience in these fields. In our model, we use a simple spreadsheet-based COCOMO formula to calculate effort and cost for each requirement.

Step 3: Plot Relative Values

Having assessed costs and benefits, the program can now visualize the relative values of each requirement by plotting their functionalities on a simple two-by-two chart. In Graph 1 below, benefits are plotted on a ten-point scale, divided by a red horizontal line representing the lowest acceptable value for any requirement. Similarly, costs are plotted using an appropriate scale, and divided by a red vertical line representing the maximum cost-per-requirement set by the program. The result is a four-quadrant graph that provides visual justification for maintaining or foregoing requirements.

Quadrant 1 contains the highest-value, lowest-cost requirements – those that provide the most “bang for the buck,” and should be preserved. Conversely, Quadrant 4 contains the lowest-value, highest-cost requirements, which are most eligible for cutting or deferral. Program managers will focus their attention on this quadrant in order to meet budget constraints.

Step 4: Compare Requirement Costs to the Program Budget

The final step of our requirements streamlining process is to compare requirement costs to the program budget, and on this basis determine the number of requirements to be cut. In our sample calculations, illustrated on the next page, we assume that the program must meet a budget of $10 million. The total project cost exceeds this budget by $3.06 million. To come closer to meeting the budget, the program will cut discretionary requirements that fall in Quadrant 4 of Graph 1: R-1, R-4, R-21, and R-24. In addition, the program can defer low-value requirements that fall in other quadrants to save over $2.5 million in costs and arrive within about $500,000 of the established budget.

Conclusion

Information Technology requirements are numerous and often costly to maintain. As program needs shift and technology advances, it is crucial to review the benefits and costs of existing IT requirements and ensure they remain relevant to program goals. By streamlining this process using proven data analysis methodologies and visual aids, program offices can facilitate meaningful discussions on requirement benefits and costs, and thereby significantly reduce workload and resource costs.

Our 4-step process uses rigorous data analysis to help program offices determine the relative costs and benefits of existing IT requirements, and on this basis make informed decisions on which requirements to cut or defer. At its core, this approach provides a visualization technique that facilitates compromise and consensus amongst program stakeholders. By employing this process, program offices can not only save time and money, but make better decisions on which requirements to keep and which to defer.

References and Further Reading

Aslam Khurum and Gorschek, Tony. A Method for Early Requirements Triage and Selection Utilizing Product Strategies. Ronneby, Sweden. Blekinge Institute of Technology, Department of Systems and Software Engineering.

Boehm, Barry W., et al. Software Cost Estimation with Cocomo II. 2000. Upper Saddle River, NJ: Prentice
Hall, Inc.

Jones, Capers. Estimating Software Costs: Bringing Realism to Estimating, Second Edition. New York, New
York: The McGraw-Hill Companies, 2007.

Kundra, Vivek. 25 Point Implementation Plan to Reform Federal Information Technology Management.
U.S. Chief Information Officer. Dec 9, 2010.

Wiegers, Karl E. Software Requirements, Second Edition 2nd ed. February 26, 2003. Microsoft Press.