Architected Futures™

Tools and strategies ... for boiling the ocean

Requirements

Requirements are things that are wanted or needed. They may define something that is necessary for something else to happen or be accomplished. In the specification of a system they tend to define the collection of elements and conditions that are necessary, or desirable, for the system to achieve a desired state: become whole, be functional, become viable.

There are 6 types of requirements necessary to define a solution1. They are:

  1. I/O Transformation: Defines what goes into and what goes out of the system. Otherwise might be referred to as "functional requirements". I and O are defined in terms of time dependent trajectories (regardless of the type of system).
  2. Performance: Defines how well the system I/O must be performed. These are quality factors like accuracy, precision, speed, etc. They MUST be attached to (dependent upon) a specific I/O requirement.
  3. Technology Constraints: These are limitations on "what" the system can be made of. They may refer to imposed interface protocols or the use of leveraged materials if imposed. They can also apply to the forced use of particular algorithms.
  4. Cost: Limitations on time, operating cost, development cost, space, etc. Anything you must concede to field the system.
  5. Trade-Offs: These define value proposition between PERFORMANCE and COST requirements. This is akin to the use of a Pugh Selection Matrix or other weighting scheme for making design decisions.
  6. System Test (aka Acceptance/Qualification/Validation): These define what the customer requires to accept the system. This may or may not include verification.

Together these six types completely define the overall value proposition for the system, and apply at all architectural layers.

 

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
SystemsThinking