Typically, requirements are defined as follows:
- A function that the product or process must have, or a process must do (e.g. a functional attribute like the ability to sign-off the approval of an Engineering Change Notice or ECN following a specific number of steps in a specific service timing, and convert it into an Engineering Change Request or ECR upon approval).
- A property or attribute that the product, data or system must have (e.g. non-functional property like the performance of an engine, the payload on a system by number of transactions per minute).
- A constraint on the product, system, data or process (e.g. boundary conditions or multi-system interfaces).
Requirements must possess certain characteristics from a quality perspective, such they are SMART, accurate, classified (by importance, difficulty, risk, standard, common, unique, must have vs nice to have), verifiable (clear success criteria), traceable, consistent, concise, unambiguous, and they can be prioritized, tracked and validated throughout their implementation and verification, and clearly owned by one or more stakeholders. It is also critical to manage change, not only until they are marked as completed or deployed, but also beyond implementation for future reference and analysis.
Traceability is critical during and after their implementation to maintain a register of what has been deployed and being able to analyse potential change impacts, mitigate risks or investigate issues. Requirements can also be raised or deferred for future implementation (e.g. in a future project phase and associated with a specific change request).
It is important to follows some level of rigor and governance when documenting and reviewing requirements so that they are consistently understood, analysed, approved and monitored. They typically need to follow a specific terminology: ‘Has to, Shall, Will’, or other approaches such as the MoSCoW method (Must have, Should have, Could have, Won’t have).
Requirements can be grouped and connected from one to another (multiple to multiple dependencies) so that detailed and high level requirements are interconnected. They will also need to clearly link to expected business value, assumptions and scope of the business case. This is especially relevant for validation and benefit realization. Requirements will feed into a set of design blueprints, technical and functional requirement specifications for technical and non-technical elements.
More specifically, business and IT-related requirements cover 3 perspectives: people, process and technology (the “Golden Triangle of Change“) and their various inter-dependencies (gives and gets between the different project, phases, systems, processes, workflows, checklists, forms, stakeholders, etc.). They are based on AS IS and TO BE process mappings and quality / value driver reviews, including predefined standards (…). Green field projects might also require predefined requirement framework to align an initial consistent building block architecture.
Product Development and Manufacturing Engineering process related requirements typically come to light across validation use cases or scenario to enable implementation teams to validate the solution (product, process, and / or system) across multiple functional groups and business functions (involving the relevant stakeholders and governance).
Requirements must be captured in a Process Requirements document or database, including requirements that define gaps. Process modelling techniques and tools are used to allow consistency capture, knowledge sharing and future reuse. Any requirement needs to be adhere to the requirements quality criteria, such as uniqueness, traceability and testability(for verification purpose – typical V-model approach).
Requirements Management (and broadly speaking Requirements Engineering) is premised on accepting several key assumptions as reality and planning for them:
- Most business change or product programs are increasing in size and complexityand thus require an iterative / agile (or evolutionary and future reference) development approach.
- Requirements will, in fact, change over the life of the project due to changes in technology, user needs and the test environment.
- Requirements emerge as knowledge is obtained during development (discovery/plan, Proofs of Concept, design, build and test).
- Requirements drive the verification and test process; late identification of requirements can have significant impact to the cost, quality / expectation, and timing of the implementation.
Robust Requirements Management, including capturing / gathering, attributes, analysis, specification, validation, tracing and change management, seeks to reduce the risk of cost and schedule overruns by establishing a way to control the continuing definition of requirements as changes occur and unforeseen needs arise and as knowledge is gained during implementation.
The successful implementation of Requirements Management depends on having flexible contract scenarios that require the establishment of a process to manage requirements (in lieu of rigid predefined specifications) that addresses specification, change control and traceability, and identifies what stakeholders must be involved in the various activities of the process throughout the life-cycle. It must be a jointly managed process between all implementation parties and system integrator. Contingency and risk mitigation plans must be considered depending on the type of commercial agreement, engagement model, solution complexity, scale / size, cost, timing, etc. Different level of control will also be required, formal vs informal, based on these parameters.
Critical success factors (CSFs) and Key Performance Indicators (KPIs) of successful Requirements Management are illustrated below (non-exhaustive list).
Benefits from effective Requirements Management include:
- On-time, on-quality, on-cost delivery.
- Transparency of impacts and cost.
- Limited number of late change requests.
- Scope creep avoidance.
- Stakeholder engagement and change ownership.
- Control of implementation cost, benefit and cost of ownership.
Both Science and Art
From many aspects, Requirements Management is a science as it requires a robust approach and framework, combined with execution experience and skills. Nevertheless, there is no ‘recipe’ for success and the above framework might be mandatory, albeit not sufficient to deliver successfully against these requirements and manage the required change, including the people related aspects of the change. For this reason, Requirements Management can also be considered as an art, especially when reflecting on how cultural and political factors, communication, engagement levels, complexity, etc. can significantly impact the speed and quality of delivery.
What are your thoughts?
This post was originally published on LinkedIn on 6 November 2015.
About the Author
