How To Take Effective Requirements.

A proper requirements document, or framework, can make or break a project.

Well defined requirements can be a projects’ greatest asset. They will allow you, the developer, to deliver exactly what your client expects. They also let the client know what to expect in terms of delivery.

From a developer perspective, having a good set of requirements will increase adoption and decrease time to delivery. They can stop scope creep and give you a goal to work towards.

A good approach to gathering requirements will always include a discussion with your projects’ sponsor and your end users.

• Clearly state the customers needs and wants - This is great for avoidance of doubt, meaning you and your client are exactly aligned on what should be delivered. This is also a good point to pause and fact find. There may be points made during this discussion that require further investigation.

  The outcome of this investigation may be that some points will not be deliverable or may increase expected delivery times. These points should be articulated to your customer.

  Good things to include in this part of the requirements gathering include;

  • Functionality — Functional needs to be able to solve customer’s problem or desire.
  • Price — Customer’s budget will need to be well understood.
  • Customer Experience — Customer’s experience needs to be easy to use.
  • Design — Product or system design needs to be easy and intuitive to use.
  • Performance — Product or system needs to perform correctly to achieve customer’s goals.
  • Accessibility — Customer should be able to access product or service by multiple channels.

• Use simple language in your requirements document - This document should be understandable by anyone that looks at it. Technical documentation can accompany the document, but first and foremost both the devlopers and client should understand the requirements document. Using simple language in the document will avoid any doubt when it comes to the contents.

• Even if your language is simple, include enough detail - This goes back to avoiding doubt, there should be little need for anyone new to the project, having read the document, to ask questions or need clarity on any point within it. Not including enough detail in the requirements document can have far reaching consequences, from delays in delivering to devliering a product not fit for purpose leading to re-work.

  • Functionality — Functional needs to be able to solve customer’s problem or desire.
  • Price — Customer’s budget will need to be well understood
  • Customer Experience — Customer’s experience needs to be easy to use
  • Design — Product or system design needs to be easy and intuitive to use
  • Performance — Product or system needs to perform correctly to achieve customer’s goals
  • Accessibility — Customer should be able to access product or service by multiple channels.

• Communicate & Collaborate

• Prioritise Requirements

• Manage the requirements change effectively

• Work closely with your stakeholders to validate the requirements captured