The McKinsey Quarterly
As Leo Tolstoy once noted in Anna Karenina: “All happy families are the same yet all unhappy families are unhappy in their unique ways” Adapting the above to the large scale technical system development programs yields us something like: “All green programs are equally green but every red one is red in its unique way...” There is, however, a feature that is endemic to red programs. They all manage to screw up their requirements development. Statistically, about 80 % of red programs list bad requirements as a factor contributing into their “redness”. Moreover, about 80% to 90% of red programs with requirements problems never recover and stay red for the duration of the program.
Well developed specification is what, to a large extend, separate success from failure in the system development real. A good requirements’ specification starts with a good requirements development approach. A set of functionally focused Integrated Product Teams (IPTs) forms an organizational structure proven to work well for a development of complex requirements’ specifications. Good requirements specification should have two major qualities: It should accurately reflect the functionality and it should be composed of, well, good requirements. Although it may sound somewhat improbable, requirements “goodness” may be defined as a measurable criteria. I use the following attributes to define a good requirement:
Integrated Product Team (IPT) organizational structure is probably the best way of dealing with the above conundrum. System level requirements may be developed within a set of Functional IPTs. Each IPT is responsible for a system function. Of course, it hinges on an important assumption that the program is employing a competent system architect able to perform system functional decomposition needed to define those IPTs scope. Yet again, if no such person exists, the program team is doomed and all further discussions are somewhat meaningless. The IPTs are to be set-up by business function (as opposed to being setup by a subsystem) since the resulting specification should be business driven as opposed to a system design driven
Each IPT should include: subject matter experts contributing in-depth functional knowledge and systems engineers contributing an in-depth knowledge of requirements development and systems’ integration. Those IPTs should be small. I would suggest that each should include no more than 6 people. Recently I recently witnessed a requirements’ development effort performed by 10 people strong IPTs. It didn’t go too well. One should never underestimate people’s ability to talk passed each other. Each IPT takes full responsibility for its functional element.
Internal and external interface requirement development warrants a special consideration. I am of an opinion that internal interfaces amongst subsystems should be reflected in the requirements attributed to the affected subsystems. Therefore, internal interface requirements (if any) will be developed by functional IPTs and further validated by the System IPT (see below). External Interface requirements represent a different issue. External Interfaces are influenced by the system business functionality. I am of an opinion that a dedicated External Interface IPT should be set up to specifically deal with interface requirements
System IPT is a group whose role is to review all requirements coming out of Functional IPTs in terms of their implementabilility, consistency and completeness. System IPT also mediates disputes amongst functional IPTs and pays special attention to interfaces. If needed, System IPT takes charge of developing a set of non functional requirements covering:
Obviously, keeping all the above teams coordinated is a challenge. A Cross Functional IPT is needed to act as an integration layer for all Functional IPTs. Cross Functional IPT acts as a final approving authority for all the requirements being developed. It takes input from all Functional IPTs and a System IPT and has a power to approve or disapprove any requirement being proposed. Cross Functional IPT is responsible for:
About the author: Alex Smirnoff has 20 years of industry experience including 10 years of managing engineering teams involved in developing complex, software intensive systems. He holds MS degrees in Aerospace Engineering and Management and is currently working towards a degree in Applied Mathematics at the John’s Hopkins University.