top of page

Requirements Capture - The key to a successful project

Managers, directors, analysts and engineers often peer back along a project life-cycle questioning at what point it all went wrong, at which point in time drained all the funds?More often than not, the answers are vague and incorrect. The true underlying determining factor? Poor requirements capture and definition at the very beginning.


Recently, I've been rather fortunate to visit customers across a breadth of engineering disciplines and have been exposed to, and part of, projects at all stages of the 'V lifecycle'. For those of you who are unfamiliar with Systems Engineering, I shall give you a short 'SE 101' introduction.


Systems Engineering traces its first origins back to World War II to the Bell Laboratories. What is a System? Simply put, a combination of things that achieves a function. Its a door opening and closing on a train but its also the controlling actuators of a gas turbine on a naval aircraft carrier. Systems Engineering follows a rather simple 'V Cycle' (Figure 1). It spans the breadth of engineering disciplines and employs the polymath of engineers.


On big projects Systems engineers are aligned to a certain part of the 'V Cycle' and work as a standard engineer within the discipline of choice; electrical, mechanical, controls etc. On small projects the engineer controls large chunks of the 'V Cycle'.


📷


Figure 1 - The Systems Engineering V Cycle

Upon debating 'requirements' with a highly experienced engineer, David Kimbell, ex Rolls Royce requirements guru; he distilled two underlying principles for success.


  1. Use Pareto's principle; do 20% of the work which delivers 80% of the value. Keep it simple stupid.

  2. Human beings love to add complexity and over complicate things, just for the sake of it - don't do that.


With these principles in mind, one may begin to capture requirements. Requirements are broken down into the following categories:


  • Operational Requirement - identifies the system's capability

  • Functional Requirement - identifies the functions of the system

  • Non Functional Requirement - Additional system entities which don't deliver a function

  • Performance Requirement - At what level the function shall be carried out

Requirements which are easy to interpret follow a basic english sentence structure and are free of unverifiable terms such as 'user friendly' and 'easy'. For example, as I drink my cup of tea, this comes to mind;


"The cup shall contain all fluids without any leakage"


So follow this sort of structure:


The 'system entity' shall 'verb' by means of 'function'.


So here's an example of a short list of requirements. I'll allow you to figure out which is functional / non functional etc.


  • The cup shall be capable of holding fluid whilst allowing the user to lift and transport the vessel to and from a chosen location

  • The cup shall hold a volume of 330 millilitres

  • The structure shall have a lifting mechanism

  • The cups exterior shall be blue


Now you have a basic level of understanding how requirements are written, its worthwhile delving into methods of 'eliciting requirements'. Bearing our two principles in mind, speaking with the customer or key stakeholder is a good place to start. Initially, start small and think in an agile format. What small list of requirements can get my project off the ground? Begin with an operational requirement, then with some functional requirements. This usually is enough to set the ball rolling. Ensure they are verifiable and spend a moment in reflection by trying to understand if delivering such a requirement shall add value to the end user. There are some tools to help requirements gathering such as UML use cases, sequence diagrams, context diagrams etc. I usually find drawing a rich picture of my system with what it's trying to achieve and the associated sub systems is a good start.


To play on the ethos part of Aristotle's 'ethos pathos logos' triangle where I appeal to your emotions rather than your logical rational, here are some lessons learned from my past experiences when eliciting requirements;


  • Each requirement must be able to be 'verified and validated'. Verified meaning - is it written correctly, did I build the system right? Is it attainable? Validated meaning - did I build the right system? A future article shall delve into the 'V&V' process.

  • Make requirements traceable. Assign a number to each requirement to allow ease of discussion, architecture can later be linked to each requirement. Use a simple tool such as Excel or a complicated tool such as IBM DOOR's to track changes and maintain version control of your requirements.

  • The requirements process should be driven with the end goal in mind. This does not mean that your requirements contains the design. This means 'can I validate my project successfulness by these list of requirements?' Ultimately, projects have a customer or key stakeholder that want to see proof that they have been given what they paid for. A process driven by your design validation team means they can easily link the test results to each requirement as a sterling example of your steely requirements.

To quote Plato - "A good start is half the battle". A proper set of requirements which provide direction and means of validating your success is half the battle.


I truly wish the above article may aid at the very least, one reader. I kindly ask you share your thoughts, comments and past experiences by any means you see fit.



Thank you!

Comments


bottom of page