Regardless of how thoroughly one works on eliciting requirements, there is no way to be sure you’ve found them all. There is no sign that lights up with “You’re done!” when you finish the elicitation process. Throughout the project, one must always strategize on drilling down new requirements.
Frequent changes in requirements is a sign that important requirements have been ignored during elicitation. This article offers some suggestions for closing gaps caused by missing, implied and assumed requirements.
Missing requirements are the most prevalent form of shortcomings. They are hard to spot as they’re invisible! The following checklist will help you identify previously undiscovered requirements.
- High-Level requirements need to be broken down into enough details to identify exactly what is being asked for. An undefined, high-level requirement that leaves room for interpretation for a reader may result in a gap between what the reader has in mind and what the developers build.
- Make sure all stakeholders have provided their inputs. Ensure that the minimum requirement is identified for each stakeholder.
- Trace user requirements, system requirements, event-response list, and business rules to ensure functional requirements are captured with respect to the needed functionality.
- Validate boundary values for missing requirements. For example, if the requirement states that the transaction cost of adding FIAT (CAD) below CAD $100 is 5%, while above CAD $100 is 7.5 %. But, what is the transaction cost for adding exactly CAD $100? It’s not specified. A bit of requirements clarity is missing here.
- Requirements for complex Boolean logic (ANDs, ORs, and NOTs) is often incomplete. The developer must conclude what a system should do, or provide an answer if there are no functional requirements for a set of logical conditions. Conditions of “Else” are often ignored/overlooked. To cover up all possible scenarios and their complicated logic, use activity/workflow diagram. They are helpful when testing design.
- For common functional areas, create a checklist that needs to be considered in your project. Some examples of this can be error logging, reporting, printing, and user preference configuration. Compare this list regularly with the functions that are already specified to find gaps.
Prepare a data model to find out missing functionality. The system will manipulate all the data entities for the corresponding functionality. This is more commonly referred to as ‘CRUD’ which stands for ‘Create them, Read them from external sources, Update present data and/or Delete them.’
Avoid analysis paralysis. It occurs when the decision-making process is “paralyzed” as a result of overanalyzing information. This means no agreement/solution is reached to conclude a decision.
Assumed and Implied Requirements
Assumed and implied requirements are those which an individual expects without expressing them explicitly. An assumption made by an individual as evident might not have the same meaning to various developers. Requirements that are implied in nature are important due to another requirement but are not explicitly mentioned/stated.
Developers may face difficulty or will not implement features that they are not aware of. Implied and assumed requirements both depend on teammates’ telepathy and perceiving things that are incorrect from the perspective of a software project’s lifecycle. This does not build a good technical base.
On the other hand, an individual will never be able to document 100% requirements for any project. This poses a risk if the solution’s requirements are not specified and might result in a different solution being built than what the stakeholders expected. The presumed solutions will not align with the original plan. This compromises accountability for the missed expectations or requirements.
Areas for identifying incomplete implied requirements can be covered by studying the results of the initial elicitation sessions.
- Does an undefined high-level requirement need to be further broken down so that the stakeholders can understand it better?
- Is there a requirement that needs to be a part of a logical set and is not defined exactly?
An interview might be needed again with some of the same stakeholders to complete the missing requirements. Try to identify new stakeholders (if required) who know the topic and can identify gaps.
Always try to read between the lines to figure out features that stakeholders expect without having said so.
Raise global context-free, high-level and open-ended questions that elicit data in an informed way for conveying the business problem and the potential solutions. Stakeholders will certainly respond to such questions.
A suitable example in this context would be: “What are the different types of end-users who will be using the system?” The corresponding reactions from the stakeholders will provide definitive conclusions to open-ended queries with standard responses. Meanwhile, these interactions will also unveil valuable insights to manage requirements.
An individual will not be able to identify and document every single requirement for a software system. But if you are able to keep your eyes open for missing, assumed and implied requirements, you will be able to close many of the gaps that could otherwise trigger headaches for development, project costs and most importantly stakeholder’s expectations.
Author — Santosh Kumar, DLT Labs™
About the Author: Santosh Kumar is a cheerful advocate of Agile (SCRUM) practices with an emphasis on leading team growth, and is a valuable member of the DLT Labs team. He is a result-oriented professional who has worked in various domains including Investment Banking, e-Commerce, Loyalty and Payments. He translates business user concepts and ideas into comprehensive business requirements.