Spreadsheet Requirements 5 - Development and Risks


Picture by Gerd Altmann - https://pixabay.com/users/geralt-9301/



In this final post in this series, we will look at the requirements development process and the risks to you if you do not follow the guidelines we have discussed in this series.


There are four basic steps in the Requirements Development process:

  1. Elicitation - Gathering all information related to the project from all affected stakeholders.

  2. Analysis - Determining if the information collected is a requirement or if it is additional information needed to support a requirement's specifications.

  3. Specification - The process of documenting the requirements and ensuring that requirements are specific, unambiguous, and necessary.

  4. Validation - Obtaining agreement on the requirements from all parties. Note that it is not enough to get agreement from everyone - you must be sure that all stakeholders clearly understand the requirements and how they affect the final application.


What are the risks if you do not follow these basic steps and fail to heed the guidelines discussed in the other articles in this series?

  • Insufficient client involvement - Without the client's full participation, it is certain that the client will not be satisfied with the final product.

  • Creeping client requirements - This is why everything must be documented. You need to have an objective source you can refer to if it seems the scope is expanding beyond what was originally agreed upon.

  • Ambiguous requirements - As discussed, requirements must be clear and specific in order for you to avoid scope creep and the client's disappointment with the final product.

  • Gold Plating - This means you have a spreadsheet application with many features that are not needed and add nothing to the value or functionality of the spreadsheet application.

  • Minimal Specifications - Almost the opposite of gold plating, this is the risk that you will fail to include specifications that add value and increase the functionality of the spreadsheet application.

  • Overlooked User Groups - This risk underscores the importance of ensuring that you include all stakeholders in the requirements development. It is important that the client company's management provide input into what the spreadsheet application must do, but you cannot exclude input from the employees that will actually use the product.

  • Inaccurate Planning - If your requirements are not specific, you will fail to plan properly. The result will surely be the need to go back and fix the application, which we have seen can be quite an expensive undertaking.


Follow the process for proper requirements development and you will have a successful project, completed on time and within budget.