Requirement

From Risk Engineering

This page is under construction ...

See also

See also Project Development, Project Definition, Project Life Cycle and Phase Models, Project Delivery Methods.

Quote

The hardest single part of building a (project) is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements... No other part so cripples the resulting (project) if done wrong. No other part is as difficult to rectify later.[1]

Basic considerations

"Most contemporary design methodologies avoid premature freezing of requirements.

...

Traditional design engineering is still pursued, but it is less and less isolated by trade-offs and optimization within a discipline-limited set of purely physical variables. This is nowhere more evident than in the linkages of design variables to economic considerations. Representations of interactions of product and process variables on costs have become central to product realization in many domains. Multi-attribute, multi-stakeholder design contexts, laced with uncertainties and rich in information, are the norm. The framing of critical design decisions across contributing disciplines is central to success in such contexts."[2]

Semantics and logical framework

(Under construction.)

The semantics and logical framework for the concept of requirements in civil engineering projects has several dimensions.

  • The semantics problems are ...fold.

...

The logical framework for the concept of requirements in civil engineering projects has several dimensions:

Within the requirements term definition are more subcomponents such as assumptions, constraints and dependencies. The three definitions for requirements used several common terms (material and reasonable) for the first time and they should be defined in the project management context. (An aside on this point is that the case holds equally well for the engineer conducting the design process, which we will get to later.)

Practice frameworks for Requirements

It is helpful to lay a foundation for this discussion with PMI's concept of requirement.

Project Management Institute BoK

PMI defines a requirement as a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.[3]

PMI uses the term in defining project management, noting that it applies knowledge, among other things, to project activities to meet project requirements. One of the striking features of the PMI definition is the overlapping usage of requirements and objectives as well as a lack of integration with constraints.

Although the BoK glossary does define requirements, contextually some sections allow a synthetic definition to be developed (see Sec. 5.2 “Collect Requirements”, p. 110).

In PMI's vision, requirement ....[4][5]

International Organization for Standardization (ISO)

The International Organization for Standardization (ISO) in its ISO 21500 document intends to provide overarching guidance on project management and is not intended for certification or registration purposes.[6]

Software Development Process

Wikipedia notes that the Unified Software Development Process or Unified Process (UP) is an iterative and incremental software iterative and incremental development process framework.[7]

As a process, it provides the guidance and necessary steps to implement a software project; i.e. "a complete set of activities needed to transform users' requirements into a product; a process is a template for creating projects."[8]

It defines requirements as ...

Civil Engineering practice frameworks

(Under construction.)

Programmatic frameworks for Requirements

Office of Management and Budget (OMB)

(Under construction.)

Department of Defense (DOD)

(Under construction.)

Department of Energy (DOE)

DOE's program guidance notes that all DOE projects have a "...single, vital commonality: the preparation, documentation, approval, implementation, and verification of project requirements."[9]

These requirements define the framework for going forward with the detailed descriptions and design necessary to meet the project performance (products, deliverables) established in the Mission Need Statement (MNS).

Requirements define and describe the extent to which a function(s) must be executed, and are generally measured in terms of quantity, quality, coverage, timelines, safety, environmental, products, deliverables, etc. (DOE, op. cit., p. 7.)

Department of Transportation

Federal Aviation Administration (FAA)

(Under construction.)

Federal Transit Administration (FTA)

FTA's PCM has ... instances of reference to requirement while PMI has ... and ASCE has none. In this case, ASCE does not use the term "project phase" or "project delivery" in its body of knowledge. For a stakeholder or sponsor this is very problematic. Lastly, FTA doesn't define the term but PMI in its BoK does.

Federal Highway Administration (FHWA)

(Under construction.)

Regulatory framework for Requirements

(Under construction.)

Further Guidance

(Under construction.)

Beneficial Outcomes

(Under construction.)

Working definition of the term

Conditions or capabilities in the form of material assumptions, dependencies, and constraints that are to be met by the project or present in the product, service, or result to satisfy a set of objectives which includes the needs and expectations of the project sponsor, customer, and other stakeholders and established as part of an agreement or other formally imposed specification.
Requirements are to be quantified and defined in adequate, detailed documentation that is totally satisfactory as a basis for establishing the project scope baseline and performance measurement once project execution begins.

Limitations of the definition

(Under construction.)

See also

Google searches on project delivery:

Notes

(Under construction.)

References

  1. Heimdahl, Mats PE. "Let’s not forget validation." (2005) accessed at [1] on 26 October 2016. Heimdahl cites F. Brooks, "No silver bullet: Essence and accidents of software engineering", IEEE Computer, April 1997, pp. 10–19.
  2. "2. Decision Making in Engineering Design." in Theoretical Foundations for Decision Making in Engineering Design. Washington, DC: The National Academies Press, 2001, ISBN 0-309-54224-3. [2]
  3. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th edition, 2013, Glossary, p. 557.
  4. Project Management Institute, PMBOK® Guide, 5th edition, 2013, op. cit.
  5. Project Management Institute, PMBOK® Guide, 5th edition, 2013, op. cit.
  6. Wikipedia article on ISO-21500, accessed 5 February 2015.
  7. Wikipedia article on Unified Process, accessed 15 March 2015.
  8. Booch, Grady; Ivar Jacobson; James Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999, p. 15.
  9. Project Management Practices, Engineering Support and Requirements Generation, Analysis, and Use, Sec. 2.0 Requirements Generation, Rev. E, June 2003.