Requirements

In the rail industry it is common to have a defined set of requirements in detailed design phase and associated contract. It is elaborated based on previous experiences of rail operator, industry regulations and best practice. However, it is sometimes occurring that the set of contract requirements may not be tailored to match the intended system, emerging in the design and delivery under contract. In such case, designers have to justify applicability of contractual requirements and derive new specific requirements to make a tailored and comprehensive set of requirements for the intended system. 

While allocation and justification of contractual requirements is a top-down workflow, from Customer to Contractor, derivation of specific requirements is a bottom-up workflow, from Contractor to Customer. Management of derived requirements is often constrained by contractual requirements, whereby derived requirements are typically present merely a detailed view of some broadly formulated contractual requirements, or those relevant to process of identification of specific requirements. Commercial interests are guarded by Customer and Contractor, and derived requirements are typically limited to the spirit of contractual requirements, avoiding bespoke or novel solutions, the ones clearly uncomfortable for accommodation by the Contractor without additional commercial provisions. 

As designer identifies specific derived requirements, they are progressively allocated to design workflows and deliverables with consideration of the complete life cycle of the system. Specific project activities, studies, assessments produce records where derived requirement could be sourced from. Where not explicitly specified in the project plans for potential sources of derived requirements these should be identified by system engineering teams via systematic review of all project records and deliverables with intent to identify implied, scattered or aggregated requirements, which clearly enhance system's arguments of reliability, maintainability, availability, useability, dependability, security and safety. Further, as such requirements often span across various phases of the life cycle and change ownership in between, clearly defined tools and mechanism for requirements management and transfer should be in place. Benefit of derived requirement should be clear and not present an overburden for the project resources without adding value. 

Good practice for requirements management is long established in ISO 15288 standard and should be the first point of reference during the project planning phases. It guides engineering teams as to the basics of the "requirements to requirements". A quality of requirements primary text and its meta-qualities cover the aspects of Singularity, Non-ambiguousness, Clarity, Completeness, Correctness, Testability, Prioritisation, Traceability, Achievability, Categorisation, Relevancy, Conciseness, Uniqueness, Conformance (non-contradiction to itself and others), Ownership, and Consistency.

Typical sources of derived requirements are mostly aggregated records, like safety risk registers, FMECA or RAM logs, Human Factors issues logs, Security risk registers, Fire risk registers. As such, these registers present a structured information readily convertible into derived requirements along with associated meta-data or attributions. Below are some further guiding principles of derivation, based on practical examples from rail projects in Australia where safety risk register is managed for derived requirements originating from recorded current and proposed controls.

1. If a type of control is "Administrative" or "PPE", controls should be reviewed and acknowledged as covered in project planning framework and other OHS/SMS frameworks, which have their own management paths. No derivation required.
1. If administrative control is outside of planning and OHS framework AND has clearly identifiable safety benefit AND it is NOT intended for Transfer - it should be a derived requirement, e.g., "additional non-mandatory signage", "additional training session for remote stakeholders".
2. If a current control had been already implemented in design at the time of analysis AND it is mandated in the contract or sub-referred standard, it does not need a derived requirement, as this would add little to no benefit to trace a mitigation already implemented in design, this relies on quality of delivery per design and change/configuration management.
1. Where controls are incorrectly identified as current but imply future action with benefit - these should be relocated to proposed with derivation.
2. Where current control contradicts contractual requirements is must be recorded as proposed control with justification of safe decision, and commercial management, where adopted.
3. Where current control refers to other planned and accounted adjacent design scopes without specifics or added benefit, no derivation is required.
4. Where current control carries explicit safety benefit without reference to a standard traceable to contract, it deems appropriate to manage a derived requirement to ensure implementation, otherwise a formulation should be updated with reference to standard mandated in the contract.
3. If a current control has ongoing nature or refers to future activity which is NOT explicitly planned in phases post design, such one should have a derived requirement for the benefit of management in delivery phases.
4. If a proposed control is owned by primary designer AND it is NOT recorded explicitly in the contract, it shall become a derived requirement to inform designs.
1. Care to be taken for scope coverage of the contract and extrapolation thereof, e.g., contract means a requirement only for a specific site, but risk record extrapolates this to other sites.
2. Requirements to secondary/workshop drawings designer shall be derived, where of non-PPE type. Alternatively, they must be presented as notes or comments of drawings of primary design.
3. Proposed controls with incomplete safe decisions ("Explore further") shall be derived as uncertain at the time of processing, later removal can be done, if justified as rejected.
4. Proposed controls allocated for ownership to adjacent package primary designer (peer designer) should not be derived, they are managed via Transfer process with status record in risk records and requirements tools.
5. Care to be taken of overlaps between current and proposed controls, and overlaps within each category (current, proposed) across all phases, with adequate formulation of all requirements.
5. If a proposed control has allocated ownership to Constructor/Commissioner, it does not need a derived requirement. A Transfer to construction/commissioning risk register from design risk register should be undertaken with safe decisions recorded in construction/commissioning risk register for adopted/transferred controls and in design risk register for rejected ones. Construction/commissioning OHS frameworks will provide enforcement and traceability of controls.