Requirement Products
Overview
Requirements surround us, whether implicit or verbal (e.g. instructions from your immediate manager) or formal written ones (e.g. user requirements, functional specification, interface requirements, contract, legal). They may often be presented or issued in many types of document which do not have 'requirement' or 'specification' in the name e.g. process, formal technical or management plan.
Identifying and understanding the correct set of requirements, expressing them in simple uanmbiguous and veriable ways and then assuring against them is essential to
- achieving the original 'design' intent
- producing feasible, verifiable repeatable products
- minimising technical debt (e.g. arising through not properly documenting the requirements being designed or worked-to)
- minimising the risk of failure.
Experience
Eclectica Systems Ltd. has worked with and producing requirements, including requirement tools and the production of requirements over 40 years in many areas and at many different levels using tools such as IBM DOORS (Classic and Next Generation) and Jama to produce requirement models and a traceability / artefact architecture spanning input requirements to design assurance/compliance artefacts. We have also produced requirements models using the UMLand the SysML and linked requirement models to the architecture description of the system of interest.
The scope of the requirement artefacts over the years includes:-
- levels (business, customer, user, system, sub-system)
- domains (aerospace, defence, government, space, utilities, power and distribution)
- types of requirement document
- Acceptance Specification
- Business Process (including interfaces and checking for dependency gaps)
- Capability Requirement (includes product and business capability)
- Commissioning Specification
- Data Product Specification [data / dataset requirements to support particular ptoduct]
- Functional Specification
- Information Needs Analysis (INA) [conceptual/logical data, relationship and data quality requirements]
- Interface Control Document (ICD)
- Interface Requirements
- Stakeholder Requirement Document (StRD)
- System Requirement Document (SRD)
- whole system
- sub-system
- User Requirement Document (URD)
- Design Verification (Assurance) Requirements
- Trial Requirements
covering a wide variety of subjects from rail, communication systems, training service, software, radar, ground vehicle, aircraft, nuclear, HVDC power distribution, the odd part of a future space vehicle propulsion system, safety and protection to business capability and change requirements.
A requirement model can be the basis for an assurance/verification case and support creation of a Compliance Matrix (TRAK MV-04 Assurance View)
Typical Tasks
Tasks/ deliverables/products might include:-
- assessment / setting up a requirement management capability
- integration with tools such as IBM DOORS (Classic and Next) or enterprise architecture tools such as Sparx Systems Enterprise Architect
- review / production of Requirement Management Plan (or the Systems Engineering Management Plan (SEMP) )
- production of a requirement document or a model containing the requirements (user, product, system, process)
- review / improving the quality of an existing requirement document (including structure, suitability of boundaries and interfaces)
- support for a design review e.g. System Requirement Review (SRR), Test Readiness Review (TRR) or similar.
- mentoring / training of staff