User Requirements: Recommended Core Attributes

Uniquely identifies the record.

Keeps the identity of the record if its Hierarchical UR Number or other data changes.

Typically this is generated by the tool being used and may be suppressed from reports.

Do not duplicate any value within a URD.

Do not change the Unique Identifier if the record moves position within the URD.

Defines the position of the record in the hierarchy.

Use a hierarchical numbering system so that records in a database can be viewed within their hierarchy, and records in a flat list can be positioned within a hierarchy.

Defines the required service, outcome, effect or constraint.

For User Requirements, each statement should:

• Be singular.
• Identify the user, by role or appointment.
• Explicitly define what service the user needs to be able to deliver, or the outcome / effect that the user needs to be able to achieve.

To quantify the required level of service or magnitude of effect see ‘Effectiveness Envelope’ below.

To define the circumstances in which the service must be deliverable, or the effect achievable, see ‘Effectiveness Envelope’ below.

To record why the service, outcome or effect is needed, see ‘Justification’ below.

A typical construct is: “The <named> user shall be able to deliver the <defined> service to <identified beneficiary> in order to achieve <a defined> objective.”

Each statement should also define any essential dependencies. e.g. “ …using the same information source as <another named user> …”.

The scope of the requirements should include readiness, availability, and sustainability of the capability.

Easily forgotten categories include:

• Requirements for benign coexistence with other capabilities on the same platform or in the same network.
• Requirements for resilience to threats, inc. pollution, and accidental damage.
• Requirements for concurrency of operations and peak loading.

For Capability Constraints each statement should:

• Be a single constraint on the solution to the SSON or how the solution can be used.
• Identify the origin of the constraint (e.g. a JSP invoking national legislation), and the capability stakeholder responsible for its inclusion in the URD.
• For recording why the constraint is needed, see ‘Justification’ below.

Typical constructs for constraints are:

• “ The capability shall not …”
• " The capability shall comply with …”

Requirement and Constraint Notes:

• Avoid duplication. If two users / stakeholders have a common interest record both sponsors against a single statement (one might change their interest later). Only consolidate if every element of the duplicated items, including tradability, is common.
• Use terminology understood by the user and stakeholders.
• Be explicit.
• Avoid ‘how’ statements.
• Exploit the hierarchy to minimise repetition. Statements can inherit characteristics from parent nodes.
• Group and list similar types of statement in a table.
• Statements must be no more solution-specific than the Concept of Employment (CONEMP) allows.

Quantifies the requirement / constraint.

Defines the solution trade-space where appropriate.

Defines Service Acceptance expectations.

Refer to Effectiveness Envelope.

Records why the requirement, effectiveness envelope, or constraint is included.

Provides an audit trail back to where the requirement, effectiveness envelope or constraint originated, and / or who the originator was (typically a capability stakeholder or proxy).

Helps ‘impact analysis’ during trade studies.

Inhibits ‘wish-listing’.

Protects against inadvertent trading.

Record the justification for each requirement, effectiveness envelope, and constraint. Express this, typically, as an operational outcome, e.g. ‘Permit …‘, ‘Enable …’, ‘Prevent …’, ‘Reduce …’, ‘Enhance …’ etc.

The audit trail is a protection against staff turnover and reorganisations. It facilitates trade-off decision taking. Include specific references wherever possible. For example, OA Study CDA/xxxx/99, Tech Int Report xxx or Defence Planning Assumptions 96 Para xx. The audit trail also enables currency of the requirement to be reviewed through-life, by reference back to its source.

Records how to demonstrate that the requirement is satisfied or that the constraint is complied with.

Helps clarify what constitutes a ‘pass’ or ‘fail’ for acceptance purposes, if necessary.

The satisfaction of all User Requirements shall be testable, likewise compliance with Capability Constraints. The Validation Criteria records the class of technique to use for the generation of acceptance evidence, e.g. Military exercises, Range Firings, OA. etc.

The Validation Criteria carries forward into the Integrated Test, Evaluation and Acceptance Plan (ITEAP). It enables forward planning, budgeting, and resourcing of Test and Evaluation activity, including provision of Government Furnished Assets (GFA).

It may initially be an assumption, subject to review and refinement as the acquisition programme matures.

Identifies the potential for trading, relative to statements in the same URD.

Prioritise each requirement or constraint to indicate its scope for trading. Tag each requirement as follows:

• M = Mandatory (e.g. legislative).
• K = Key Requirement included in Part 2. Assume un-tradable without formal agreement of the URD owner. Trading will require re-submission to the IAB.
• 1 = A high priority requirement. Trading will require reference back to the DEC / CWG.
• 2 = A medium priority requirement. Trading will require reference back to the DEC.
• 3 = A low priority requirement. Trading can be decided by the EC Desk officer.

A URD owner may specify, in his CSA(A) and / or the URD Part 1, how the priorities should otherwise be interpreted.

Priorities are not normally applied to Capability Constraints, though they may be if appropriate.

Provides supplementary information.

Used as necessary, typically to reduce ambiguity, to amplify aspects of a requirement, to record a requirement-specific assumption, and to record trade-off or version history.

Ensure that requirements or constraints do not appear in the 'Remarks' field.

Records the current validity of the individual user requirement or Capability Constraint.

Status codes for Part 3 requirements and constraints are:

• Candidate - on first addition to the URD, or re-instatement.
• Traded - if the need is still valid, but satisfaction is deferred indefinitely, typically as a consequence of trade-off activity.
• Transferred - if relocated out of the URD into another URD, typically as a consequence of trade-off activity.
• Cancelled - if no longer valid because the operational need has changed.

Provide an explanation (e.g. when, why, where-to) in the ‘Remarks’ field if re-instated, traded, transferred, cancelled, or otherwise changed for whatever reason.

For audit purposes, do not physically delete any requirement from the database. Retention of ‘traded’ requirements facilitates later re-consideration.