System Requirements Practice

  • Verification Requirement Example

    System Req.: "The system weight shall be less than 2,000 pounds."

    Verif. Req.: "Compliance shall be established through statistical analysis, based on component measurements on calibrated scales with less than 0.5% error, that show that at least 95% of units will meet the required system weight value."

    Notice that this statement could be traced to several weight requirements

    		•
  • Ask yourself:

    What are the consequences of not meeting the requirement?

    How much risk is involved in achieving or establishing compliance?

    How precise or sensitive is the requirement?

    		•
  • Two Basic Requirement Types

    Pimary: Has force of contract Must be done to satisfy contract Change requires contract re-negotiation

    Derived: Doesn’t have force of contract May be traded-off as long as still remains within scope of primary requirement

    Note: The requirement derivation process can produce additional primary requirement statements

    		•
  • Primary Requirement Types

    Critical or Key: System will be rejected if any of these are not met

    These should have Technical Performance Parameters (TPP’s) identified for Technical Performance Measures (TPM)

    All others Still mandatory but customer may waive them if push comes to shove (unless there are too many of them)

    The norm is to meet all requirements

    		•
  • A Good Requirement I

    Describes ‘What’, not ‘How’

    Is atomic (basically one statement)

    Single purpose (not compound)

    Applies to single product

    Is clear, concise, and complete

    Is achievable

    Is unique (I.e. no repeats)

    Identifies applicable system

    Modes

    States

    		•
  • A Good Requirement II

    Is necessary

    Is a condition for acceptance

    Is not gold-plating or unneeded item

    Is unambiguous

    Admittedly hard to do in natural language

    		•
  • Good Requirement III

    Traceability to higher level

    Rationale

    Assumptions

    Qualification method

    Qualification level

    		•
  • Use Cases

    Some people claim that Use Cases can take the place of functional requirements, not so because Use Cases:

    Are at higher level than simple functions

    Are compound (non-atomic)

    Have implied requirements (incomplete)

    		•
  • Use Cases != Requirements

    Also, in Use Case form it is hard to:

    Check for functional completeness

    Allocate to items

    Trace to items

    Conduct queries and searches

    Centrally manage requirements

    Baseline

    Attribute (e.g. status, type, qual. method).

    		•
  • Before You Write The First Requirement:

    Define the system’s scope; Use a System Context Diagram

    Identify the system lifecycles under contract; e.g. Maintenance, Deployment, Retirement

    Know the full set of system’s stakeholders

    Define the systems goals and objectives; Including the customer’s, the user’s, and ours

    Identify system constraints, including what we bid and negotiated

    		•
  • Writing Good Statements

    Use active voice

    Use simplest wording to convey meaning

    Cite referenced documents with:

    conforming to ...

    as specified in ...

    in accordance with ...

    		•
  • Use Precise Language

    "Shall" - for mandatory stipulations; Not subject to tradeoffs

    "Should" - for preferences; Subject to tradeoffs

    "May" - for allowed options

    "Will" – denotes intent

    Avoid vague words such as:

    Optimize, maximize, and minimize, Simultaneous, real-time, As appropriate

    		•
  • Specify Dimensions Completely

    Use standard units of measurement

    Specify tolerances as well as dimensions; but, ensure they are not too tight, over-specified tolerances increase cost

    		•
  • Specify Limits Correctly

    Avoid ambiguity in limits by using:

    "… shall not be greater than …"

    "… shall not be less than …"

    Avoid "up to"; it can be interpreted three ways!

    All values from minimum to the number

    A single number between the limits

    Sometimes as great as, but not necessarily

    Use "not less than" instead

    		•
  • Language to Avoid

    "Capable" - Being capable of doing something is not the same as actually having to do it. Specify what system must do

    "To the greatest extent possible" - Can be taken quite literally

    "/" and "and/or" - "Spell out" what you mean instead

    "As a minimum" and "not limited to" - These have no effect and are just noise

    		•

    Soda Machine Example

              Because people get thirsty,
          and because they may wish to quench their thirst with a soda,
          and assuming people carry American currency,
          if the user makes a soda selection,
          and if the user has provided sufficient money to cover purchase price,
          and if sufficient money is available to give any change required,
          and if there is at least one can of the selected soda left in stock,
          the system shall dispense the selected soda,
          producing a ‘Thank You’ message,
          producing the change if any be due,
          ensuring that the can is delivered to the user,
          with selection to dispense time not > 3 seconds,
          ensuring that correct change due is provided.
          with selection to change time not > 5 seconds.

    Resulting Requirements

    1. The system shall dispense a user selected soda if sufficient money to cover purchase price has been provided.

    2. When the system dispenses a soda, the time period from selection to dispense shall not exceed 3 seconds.

    3. When a soda is purchased, the system shall provide the required change.

    4. When the system provides required change, the selection to change time shall not exceed 5 seconds.

    5. The system shall process a selection only if there is at least one can of the selected soda left in stock and sufficient money exists to give correct change.