Introduction

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.

Derived requirements

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:

1. The system must work in temperatures below 32 F / 0 C.
2. 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

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 approach.

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.