5.1 Requirements

Requirements are specifications of what a system must do independently of how the system is designed. Requirements are not first-order elements defined in the UML; however, they are specified to be in the upcoming UML Profile for Systems Engineering [1]. A taxonomy of requirements is shown in Figure 5-1. A set of requirements specifies one or more systems, while in turn a system realizes a set of requirements. Use cases organize sets of requirements. Requirements are validated by tests applied to the system. Tests are part of test suites. Test fixtures optionally drive the system under test according to the specific test. Requirements relate to other requirements in a couple of ways. Requirements may contain nested, or sub, requirements. This allows us to view requirements at various levels of abstraction, such as "Get a rock on Mars" and "Attain Mars Orbit." This is shown as the aggregation of requirement by requirement. A slightly different relation is the association with the role end "derivedRequirement."In this case, design constraints may interact with requirements to result in more specific forms of a requirement.

Figure 5-1. Requirements Taxonomy

At the high level of the requirements taxonomy are three requirements: operational, functional, and quality of service (QoS).^[1] Operational requirements have two primary subtypes: interaction requirements and interface requirements. Interaction requirements have a system representation as a scenario, modeled as a sequence, timing, or communication, or possibly an activity diagram. Functional requirements are met by collaborations (sets of interacting object roles). QoS requirements are typically modeled as constraints and come in a variety of types: performance and timeliness; safety; reliability; security; and a variety of quality requirements. Quality requirements may include reusability, portability, adherence to standards and guidelines, and meeting objective quality metrics.

^[1] The currently ongoing work for UML for Systems Engineering identifies several more requirements: operational, design constraint, functional, interface, performance, physical, storage, stakeholder need, and specialized. These can easily be mapped to the taxonomy used here.

This requirements taxonomy helps us understand the relation of requirements to the system and its test, as well as understand how requirements tend to be represented.