AM Tutorial  (8:00 a.m. - Noon)

The Recursive Nature of Requirements Development

by Tim Kasse
Intermediate level

Summary: Collecting and understanding requirements is the necessary but not necessarily sufficient start of a successful project. Large projects involving systems and software components are required to collect and understand requirements using a more incremental or recursive approach. The SEI’s CMMI-DEV v1.2 illustrates this point.

“The Analyze and Validate Requirements specific goal addresses the necessary analysis to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals.

The processes associated with the Requirements Development process area and with the Technical Solution process area may interact recursively with one another.”

“Analyses are used to understand, define, and select the requirements at all levels from competing alternatives.”  “Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed.”

Abstract: Collecting and understanding requirements is the necessary but not necessarily sufficient start of a successful project. Requirements sources include: Marketing, Program Management, Systems Engineering, Customer, End User, Software Engineering, Independent Test, Trouble Reporting System, Customer Service, Systems and Software Developers, Past Requirements Specifications, Design Methods, and Regulatory Agencies.

The requirements phase for many software-oriented projects has been largely restricted to requirements gathering. Many large projects involving systems and software components are required to collect and understand requirements using a more incremental or recursive approach.

While a handful of the CMMI process areas such as Measurement and Analysis might read as if the practices could happen in the order of the Specific Goals and associated practices, the Engineering Process Areas have always been advertised as iterative and recursive.

Taking a few sentences from the introductory notes of the Requirements Development process areas helps to illustrate this point. “The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.”  “Requirements are identified and refined throughout the phases of the product lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s lifecycle are analyzed for impact on derived and allocated requirements.”

“The Requirements Development process area includes three specific goals:

“The Analyze and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals.

The processes associated with the Requirements Development process area and those associated with the Technical Solution process area may interact recursively with one another.”

“Analyses are used to understand, define, and select the requirements at all levels from competing alternatives.”  “Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed.”

The understanding of the recursive nature of requirements has become so important that its concepts are captured in ANSI/EIA 632, EIA/IS 731 – Systems Engineering Capability Model, ISO/IEC 15288 – Life Cycle Management – System Life Cycle Processes, and most recently the CMMI-DEV v1.2, developed by the Software Engineering Institute, made available to the public, August, 2006.

This presentation intends to present this “recursive” nature to participants and illustrate its validity with industry examples provided by one of the worlds leaders in the mobile phone industry.  Topics covered will include:

Tim KassePresenter Bio: Tim Kasse is the CEO and Principal Consultant of Kasse Initiatives.  Mr. Kasse was a major contributor to the development of the CMM, led the evolution of the SEI assessment method and led the development of the SEI’s Intermediate CMMI® Workshop.  His latest book A Practical Insight Into CMMI was published by Artech House in May 2004. He has participated in over 100 CMM/CMMI Process Assessments in North America, South America, Europe, the Middle East and Asia.  Tim holds a Master’s degree in Computer Science and a Bachelor’s degree in Systems Engineering with over 38 years of systems/software related experience.