There is inevitably a hierarchy of requirements associated with system development, from the least detailed, which
define the mission of the system or the summary user goals or objectives for the system, down to the most detailed,
perhaps through several intermediate levels. At the most detailed level, the requirements can be expressed very much in
the vocabulary of the technology used by the system; whereas at the highest level, they are typically expressed more
abstractly in the language of the domain to be served by the system, as capabilities, services, behaviors, functions,
features, and so on, the choice of word often being arbitrary. It is certainly possible to ascribe different meanings
to these words to be more precise about what is being expressed (for example, it is possible that the description of a
particular behavior of a system does not reveal much about the goal or intention, and some other descriptive type is
needed), but that is not the purpose here.
The refinement of requirements (from the highest level, adding more detail) can proceed in a purely functional
way, that is by splitting functions into subfunctions or subtasks that support them - without regard to any realizing
architecture - and can be taken to a level where what is described would (were the system constructed this way) take
place deep within the system, and perhaps have no direct communication outside the system. This would be the
case, for example, in a structured analysis approach that went as deep as a primitive transform bubble.
This approach is ill-advised, first, because it leads to the identification of things as requirements that are not
requirements at all, but simply work products of the decomposition; second, it can lead to poor architectures (for
example, that fail to meet, or perform poorly against, other non-functional requirements), if the designer maps the
realization very closely to the decomposition. However, there is a valid reason to do some functional
decomposition when the vision goals are expressed at a high level, while limiting the depth of decomposition to
discernible capability or functions, that is, with enough detail to capture all significant (to the stakeholders)
behaviors, features, and so forth, so the designer can realize them correctly. Requirements refined (more or less
directly) from higher-level requirements are one kind of derived requirement.
Here is a straightforward example:
Suppose a user requirement is "the system must work outdoors, 12 months a year in Alaska."
Several derived requirements are:
The system must work in temperatures below 32 F / 0 C.
The system must work in the snow.
There is another type of derived requirement. When the system-level requirements have been expressed with
appropriate detail for realization, then you:
Partition the system (model) into elements (for example, using OOAD methods).
Determine how these elements collaborate to yield the desired system behavior.
Aggregate the lower-level behaviors from the collaboration to yield the element-level requirements.
Such lower-level requirements are derived requirements; they have emerged in concert with the decomposition of the
system. This contrasts with a functionally based approach, where the partitioning occurs without regard to any
architectural decomposition, and refinement of the system-level requirements as described in the introduction.
Allocated requirements are requirements that have been assigned (based on functional considerations) to
components of a system, such as hardware or software subsystems. At the very highest level, when, for example,
reasoning about mission-level requirements for a system-of-systems, it might still be appropriate to elaborate such
requirements functionally, then partition the resulting derived requirements and allocate the groups to systems
- perhaps refining further before realization. Beyond that point, the preference here is to proceed as in Derived
Requirements. Even at the system-of-systems level, you can consider proceeding this way, using a Business Modeling
Note that in a derived approach, one decomposes the system into entities and determines the entities' requirements by
studying how they collaborate to meet the higher-level requirements. In a functional, allocated approach, one
decomposes the requirements and specifies entities that satisfy the lower-level requirements.
The approach to use depends on the context and cultural and contractual expectations. For example, the National
Aeronautics and Space Agency (NASA) [in the Software Assurance Guidebook, NASA Goddard Space Flight Center
Office of Safety, Reliability, Maintainability and Quality Assurance, 9/89] defines requirements to exist at four
levels of detail:
Level 1, the mission level - these are very high-level, and stabilize very early.
Level 2, the system level (allocated) - also very stabilize very early at this level. These requirements are
derived from the mission level and then allocated to segments.
Level 3, subsystem (or segment) level (derived) - the requirements at this level are derived from the system-level
requirements allocated to the segment.
Level 4, configuration item (hardware configuration item [HWCI], software configuration item [CSCI]) level
(detailed) - again, allocated from the previous level and then refined.
Requirements Levels and Mapping to RUP.
Typically, contracts are bid at Level 3. NASA is accustomed to dealing with requirements in this way, and it would be
natural for any organization dealing with NASA to adopt a similar taxonomy. There would still be considerable
flexibility available to developers in how lower-level requirements are derived, but given the very high level
of abstraction of mission-level requirements (these are often more like program-level requirements), the derivation of
system-level requirements (and allocation to segments) can occur naturally along functional lines. Even so, with the
interest in enterprise architectures, it is increasingly common for even system requirements to be derived using
architectural considerations. The figure above illustrates this and shows the mapping of the NASA levels to RUP work
products (including business modeling). Note how, in the RUP process, the allocation shown on the traditional flow is
performed in the Use-Case Realization process and subsequent behavioral aggregation. The blue dashed lines link work
products at a similar level.