Process of documenting analysing, tracing, prioritising, and agreeing requirements and then controlling changes



Competency Level



Through Professional/Personal Study Gained Through Experience
  • Structure and link them - Correct, Complete, Clear, Consistent, Verifiable, Traceable, Feasible, Modular, Design-independent.
  • Types – End User, Customer, Business, Functional, Non-functional/Constraints, Conflicting, Unachievable, Undesirable.
  • MoSCoW Method of prioritising, analysing and trading requirements.



Together with Responsibilities / Accountabilities
  • The difficulty of developing requirements when the customer or end user has only vague ideas of what they want or in some circumstance know there is a problem, but don’t know how to approach it terms of high level requirements. I was responsible for helping to develop both high level and low level requirements, as well as architectural patterns and use cases.
  • When developing a very large support solution, it was a real challenge trying to negotiate with the customer who felt that all requirements had the same importance and was reluctant to prioritise the requirements to allow for trades to take place in order to move to an affordable solution. We spent a large amount of time negotiating a particular requirement, of no functional or user significance, that only had aesthetical value, but sometimes that needs to be done.
  • One particular occasion a set of requirements had been developed by the customer based on a perception on how the end user would use the capability, that turned out to be wrong and another set of requirements had to be developed instead. Luckily, I had set the system up so it had been architected in modules, and there was only minimal changes needed to allow the system to work in the new manner. The customer may not always be right, and be prepared for change.
What does Requirement Management Involve?


Together with lessons Learnt
  • Visualise, manage and create traceable linked customer needs, requirements and contracts
  • Always control change and capture/track metrics (especially to test cases) and record trends
  • Show people what good requirements look like and reuse good requirements


Together with Any ‘So What’ Statements of Insights
  • Establishing the requirements for a large support contract and negotiating favourable outcomes for the IPR of selected sub-systems.
  • Negotiating the requirements for a particular difficult platform integration and assembly contract, which proved a win-win for all parties involved.
  • Assisting in the capture, collection and recording of detailed technical requirements in order to allow sub-system solutions to be individually contracted out, but allowing the company to retain role of Technical Design Authority.

Signup Success

Thank you for registering for our newsletter.

Email not correct

Please provide valid email address

An Error Occured