The document discusses dealing with bad requirements in software projects. It provides an example where a notification requirement was not fully specified, causing bugs later in the project. To handle bad requirements, the key steps are: 1) Analyze requirements for technical and cost feasibility before freezing; 2) Create use cases and wireframes to define the process flow; 3) Get client approval on documents and address any changes; 4) Have quality analysts verify requirements and flag any issues directly with the client. Proper analysis of requirements upfront can help filter out bad requirements and prevent issues later in the project.

1. How to deal with bad
Requirements of Software
being a Testing Engineer

3. Being a Software Testing Engineer, we often meet a situation
where the requirements are not good enough to complete
the flow of any process.
Let me discuss a recent incident of my current project in
which we are working on the last Sprint and we got a bug in
notification module which was a requirement of the third
last sprint. The project is an application for booking taxi
with administration support. The notification for the driver
approval has to be sent to the client as well as
administration of the app. But currently it is sending
notifications to client only and when testing team has
submitted a bug ticket to development team then developer
acknowledged this bug to the tester, with comment “it is as
per client’s requirements”. But in current sprint the client is
demanding for the notification to the administration. So, in
this situation we have to perform regression testing on the
last three builds. This is an example of bad requirements of
software product. In which there is blocker or may be a
tweak in completing the flow of the process.

4. We have discussed an example of bad requirement; Let us
now discuss how to handle bad requirements. The
Software Development Life Cycle (SDLC) starts from
requirement gathering and analysis of the requirements.
Now for a requirement it depends, how a client has asked
for it, how the project leader got it, how the BA
understood it, how a designer analyzed it, how a
developer wrote code for it and how a tester receive it.

5. After gathering requirements, the very first thing to
be done is
 Requirement analysis Before freezing all the
requirements, client’s requirements have to
analyzed whether these requirements are feasible
or not. There technical feasibility and cost
feasibility both should be consider while freezing
the requirements.
 Use Case preparation Based on these
requirements BA should prepare use cases and
wireframes to draw the flow of the process
involved in the completion of the software product.
 Document Approval These documents should be
sent to the client for approval; if client approves or
asks for any change then these changes should be
considered.

6.  Document Verification Quality analyst then
analyzes the wireframes and docs approved by
client. If a QA gets a bad requirement then an
immediate call (voice or video) should be made
to the client in presence of BA to raise the alarm
for that bad requirement.
 Scrum set up A scrum meeting can also be
made depending on the process what an
organization is following. If client approves that
requirement as final then requirements should
be freeze and should be handled with extra care
after receiving the Software builds. There are
kind of requirements which are specified by
client to be changed later in the project, these
requirement are counted as CRs and should be
analyzed properly.

7. Conclusion
Before freezing requirements a complete analysis is
mandatory both by BA and QA team. Based on these
requirements wireframes, flow chart, use case, test
cases and checklist should be prepared to filter out
the bad requirements. Always remember, a bad or
poorly analyzed requirement can block the road for a
good Software Product.