Home Category Based List TM A Subjective View on the Requirements Development

Main Menu


The McKinsey Quarterly

A Subjective View on the Requirements Development PDF Print E-mail
Written by Alex Smirnoff   
TechnologyAs 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:
  • Discrete - The requirement is a single concept, stated clearly
  • Unique -Content is not addressed by any other requirement (all redundant requirements are consolidated)
  • Concise - All non-essential language is removed
  • Verifiable - Compliance with the requirement can be verified by analysis, inspection, test, or demonstration; Test Case field method in a requirement data repository is populated.
  • Unambiguous - There is only one interpretation of a given requirement.
  • Traceable - All but customer level requirements have a "parent" requirement, design component and a rationale for their existence identified
  • Necessary - The requirement is essential to meeting the customer’s operational need or (for lower design levels) the requirement has a parent requirement.
  • Sufficient - The requirement and its sibling requirements, taken together, satisfy the parent requirement.
  • Implementable - The requirement can be met through design.
  • Affordable - The requirement does not pose a significant risk to meeting cost and schedule constraints
  • Well-Allocated - A requirement has been uniquely allocated to a design component, verified against quality criteria and reviewed in an operational concept thread review. Uniquely allocated to a component means that the component can fully satisfy the requirement (no shared responsibility with other components).
A special attention should also be paid to requirements specification being reflective of intended system functionality. This is not as easy as it seems. In a modern world large scale systems are usually build by system integrators who know well how to build systems yet do not necessarily know enough about their customer business. On the other hand, customer representatives know the business yet do not necessarily know how to develop a good requirements specification. Needless to say that this split between business knowledge and requirements development skills provides for plentiful opportunities to cause a major disaster

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:
  • System Performance
  • System Availability, Reliability and Maintainability
  • Network Requirements (if any)
  • System Usability, Access for Person with Disabilities
  • System Storage
  • System Security & Authentication (if it is not a core functionality item)
This team should include representatives from all major subsystem development groups (i.e. application engine, portal, integration layer, data warehouse, etc.,), non-functional requirements experts and be chaired by a System Architect or Chief Engineer.

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:
  • Approving all requirements being developed
  • Mediating amongst IPTs as needed
Cross Functional IPT is composed of:
  • Program Manager (or PM representative)
  • Chief Engineer / Chief Architect / SW Architect (whoever exists for a particular program)
  • Functional IPT Leads
  • Depending on a program, it also may include a selected subset of senior technology experts.
To summarize:
  • A set of functional IPTs develop functional requirements
  • System IPT verifies functional requirements implementability, consistency and completeness and develops non-functional requirements
  • Cross-functional IPT governs requirements development process
In all fairness, I do believe that an ultimate need for a requirement spec is debatable. One could argue that the system may be fully documented via a set of Use Cases and Business Rules. I do not claim an expert knowledge of this approach. I wouldn’t, however, reject its potential viability. At the same time I would argue that if only Use Cases and Business Roles are used as a system specification, a Concept of Operation document should be developed. I also would argue in favor of development a set of Mission Objectives (a DoD term) for defining top level business requirements representing a system scope. Agile methods represent yet another variation on the requirement management process that is beyond the scope of this article.

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.


Add your comment

Your name:
Your email:
  The word for verification. Lowercase letters only with no spaces.
Word verification: