REQUIREMENTS STREAMLINING

BY LOGAPPS LLC

Many government agencies are facing drastic budget reductions. Program offices are being asked to simultaneously increase performance and effectiveness while reducing costs and maintaining accountability. Program offices 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?” Our goal 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 the desired outcome. Our 4-step process provides real-time feedback on progress toward meeting the budget goal, while facilitating solid justification for the necessary changes using visual aids and analysis. By following this process, program offices can make informed decisions on technical requirements, reducing 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. Requirements that are found to be misaligned with current goals should be archived.

Requirements often cannot be deleted due to policy, regulation, public law, agency agreements, or binding relationships with other requirements. Such requirements should be segregated and identified as non-discretionary. When comparing requirement costs to the program budget (Step 4), these items are considered immovable blocs that cannot be cut. The remaining items from the analysis are in the “trade-space,” consist 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 COST

To ensure accurate screening of requirements, program managers must conduct individual assessments of the benefits and costs of each requirement. Assessments should be conducted through group sessions facilitated by an evaluation team.

To perform benefit assessments, the team can employ a variety of methods, including pair-wise comparisons, rank order, and benefit/penalty valuation. Logapps, LLC prefers to employ benefit/penalty valuation, which assessing 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 on 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, considering the 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.

We employ parametric cost estimation tools, such as COCOMO, Price-S, and SEER, to estimate software costs. 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 the 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 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.

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. Our approach provides analysis methods and visual aids to facilitate meaningful discussions on requirement benefits and costs to determine which requirements to keep or defer, saving time and funds.

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.