Getting Realistic User Requirements
Question 14: Are the User Requirements realistic?
Good Practice: For many projects the total set of User Requirements can be very ambitious, making it difficult or even impossible to deliver a solution, which meets all the requirements in a manner that is robust, cost effective, maintainable and which can be rolled out quickly to a large user base. It is therefore very important to match the User Requirements Specification against the available technology and solutions that can be implemented in a timely, robust and practical manner. This may result in an agreement that some of the requirements, say 20%, will not be delivered. Such a compromise will ensure that the remaining 80% can be delivered quickly. This is commonly known as the 80/20 rule or Pareto Principle. This compromise is particularly important for global projects with a large user base. On such projects the speed and ease of implementation is a very important consideration in the overall solution.
To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:
- Don't assume you know what the customer wants, ask.
- Involve the users from the start.
- Define and agree the scope of the project.
- Ensure requirements are specific, realistic and measurable.
- Obtain clarity if there is any doubt.
- Create a clear, concise and thorough requirements document and share it with the customer.
- Confirm your understanding of the requirements with the customer (play them back).
- Avoid talking technology or solutions until the requirements are fully understood.
- Get the requirements agreed with the stakeholders before the project starts.
- Create a prototype if necessary to confirm or refine the customers' requirements.
- Use a recognised notation, such as UML, for modeling the software.
- Cross check the software design against the requirements and review regularly.
Common Mistakes
- Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'.
- Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle.
- Not enough consultation with real users/practitioners.