Estimation Issues – Part 2: Interface-driven Requirements

In Part 1 of Estimation Issues, I discussed issues that often surface during program area analyses. We have seen on several programs that inadequate estimation of the size of the effort is a common problem, which impacts the cost, schedule and an organization’s ability to deliver on time. Diseconomies of Scale occur estimating lines of source code; when using sources lines of code (LOC) as an estimation measure, if the range is within the 10,000 LOC to 100,000 LOC the growth is usually linear, however for programs over 100,000 LOC, the typical growth accelerates and can grow exponentially.

In this second post of our two-part series, I’ll introduce a second common issue — a lack of understanding of requirements. While one may argue that customers, as well as systems engineers and developer often do not fully understand the user-level requirements, let’s assume for a minute that they do understand the “high-level” requirements. The bigger issue in large multi-tier systems is that cost estimates do not account for derived requirements (feature impacts). These derived requirements are associated interface changes resulting from design decisions. The vertical dependencies down through the infrastructure are not tracked to understand the impacts. Horizontal dependencies prevalent in service-based/distributed systems and non-functional design decisions (e.g., security, reliability) are not factored into the estimate.

What’s a derived requirement? Derived requirements are “lower-level” requirements created as a result of making design decisions. Design decisions result in system components or modules that have new or modified interfaces. These types of requirements can result from technology or platform choices and details. There can be many levels of derived requirements. The key concept is:

If there is an Interface Boundary, then there are Derived Requirements

The interfaces associated with a derived requirement play a significant role in the estimation because interfaces are more directly related to the components than the derived requirement statement.

Conceptually, the approach is straight forward — simply look at the interfaces that will change at each component boundary and attempt to estimate the impact. Identify the number of attributes that must be produced as outputs or attributes that must be processed as inputs. That processing directly relates to requirements that must be developed and corresponding tests that must be planned, designed and executed.

Program managers, project leads, system engineers, and customers can use the information to understand detailed impacts on a requirement-by-requirement basis. This information can support better cost estimates and delivery scheduling. Personnel resource scheduling can be better factored into the development effort and cost. If tradeoffs are needed to address schedule or costs for a particular release, the quantification of the relative cost impacts can be discussed with customers who should have a better understanding of the immediate system needs.

We have developed an instrument to support the estimation process, which:

  • Promotes a more complete description of the requirements through systematic refinement of customer or high-level requirements
  • Provides a better understanding of the allocation of the requirements and associated interfaces related to the derived requirements
  • Quantifies the impact of a requirement across subsystems or components
  • Enables visualization of component dependencies as they relate to derived requirements and the various interface types
  • Promotes a more consistent and complete definition of interfaces across the different system components
  • Provides more accurate cost and schedule estimates through use of more fine-grained information

Let us help you with a program area analysis. Our method and tools helps us work with you to dive deeply into program issues. We work with the team members and discuss the details of the system while discussing issues. We often identify gaps in engineering practices. Ideally we help teams understand those issues, resolve the issues, and bridge those gaps on current or for future programs.

Please contact me to discuss how our approach might help your team improve its estimating effectiveness.

 

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Estimation Issues – Part 2: Interface-driven Requirements

  1. Great post thanks, like your blog layout too. Is it Drupal?