In any software implementation project, the requirement is the stepping stone. Be it a waterfall methodology or be an agile project. And incomplete requirements can cost in havoc consequences.
When Can Incomplete Requirements Be Caught?
During the requirement gathering phase, the gaps in requirements or incompleteness can be picked up in a review by the team. As long as the whole team reviews the requirements and business stakeholders, that should be an excellent first place where the team will find any incomplete requirements or requirement gaps. As we know, the early we catch bugs is better and cheaper. This process should work regardless of which methodology is being followed. In scum, we have grooming sessions for this.
Suppose some gaps in requirements are missed during requirement grooming, which is likely and happen all the time, then during application architecture design and review of architecture. In that case, the team can find these gaps in diagrams and review them with the team and business stakeholders. Business stakeholders are supposed to be knowledgeable. But in my experience, if the organization is implementing a brand new application, where nobody has prior IT experience and has process-related knowledge, business SMEs can miss some requirements, as they cannot visualize the end product. That is why agile scrum is so much better than any other methodology.
And the software engineers are engineers; they are not subject matter experts. So, one should not expect the IT team to find out gaps in requirements. I mean, they will suggest where they can, but SMEs are accountable.
The final stage is functional testing or user acceptance testing; any incomplete requirements should also be caught. Now, please understand, a gap in requirement could be a requirement defect and not a system bug. The system could be designed as per specification. Saying all these, a system demo or system review that happens after sprints in agile has better chances that any incomplete requirement will be caught.
What Do You Do If The Requirements Are Not Clear?
If requirements are not precise, the first thing you will do is post your questions to the business analyst or the equivalent product owner. Do not send out separate emails to the business analyst; put all questions in one single spreadsheet and keep that in a SharePoint, so everyone in the team has access.
Set up a call to get questions clarified with the team. The product owner will work with the product manager from the client side and gain clarity on requirements. Do not start development with half-baked information or not 100% clarity. Share your understandings and get sign-off.
Why Are Requirements Incomplete?
We need to see the situation. If the client promised you to provide the required or not, did you not ask for the requirement? The client might not know what they want at this moment. But, it is kind of on you that you do not start working without clarity. There are many ways to approach this. First, you prepare a list of questions and then share it with a business analyst or product owner for answers. If there are existing test cases, you can go through those and confirm that you can use them for your testing. Make sure to share the same with the development team.
How do you test when there is no requirements?
First, you write test cases based on your understanding, send those to the product owner or client if that is possible, and get sign-off on your test cases/ scenarios. Share the same test cases with the development team.
If your understanding is unclear or the test cases are not complete or correct, the product owner should call out. In that case, you will revise your test cases and get a sign-off.
Which model is used when requirements are not clear?
Agile scrum XP, TDD , kanban anything will work better if the requirements are not clear. Because you can start small and whatever is clear, then gradually as you get clarity your incremental value delivery will be better.
What is the negative consequences of poor requirements?
Incomplete requirements start causing issues from the very beginning. Developpers go by whatever requirements they get; testers design test scenarios and test cases by whatever they have. Incomplete requirements will create a preliminary application with a lot of bugs. Moreover, there will be confusion about what is a bug and what is enhancement. Any final requirement that was signed off should be considered baseline, and deviation from that would be regarded as a bug. Any new requirement will be considered as an enhancement. But the major issue comes during development and testing. So, whenever you are not clear about requirements, raise flags and ask questions. Get into clarification calls with the product owner, product manager to gain clarity.
How do you test product if there are no clear requirements?
The first question you should ask is, what is the developer basing their requirements on? Maybe your company or project agreed upon that no requirement will not be a problem and they can still develop, but develop based on what? It could be an existing application. To find that out.
Next, you should have test scenarios and test cases before you start testing. See if there are existing test cases. Else raise clarification questions, design test scenarios, and test cases and get them reviewed, get sign off. And perform testing based on signed-off test cases.
If you do not have test cases, create test scenarios. You will get clarity on requirements and you will understand what you need to test. And if you do not have time to create test cases, test scenarios will be helpful. Get the scenarios signed off by business analysts, just to validate that your understanding is correct and you are not missing anything.
505 thoughts on “How to Resolve Incomplete Requirements In Software Engineering?”
Comments are closed.