Business Analyst creates a requirement. Requirement implemented by developer. BA performs QA. Bug report includes various bugs that were never requirements.


A requirement is made to display a report. The report is displayed. In QA, the analyst see's that a user can enter invalid data. The invalid data makes the report invalid. Per the requirements, an error message is displayed.

The analyst decides that they want the previously run report to have its data cleared. Currently, when entering into an invalid state the system displays results from the previous report along with an error message.

In this case, the problem is that we are in an error state. The error state requires an error message, but is otherwise undefined.

Is this "bug" scope creep, poorly defined requirements, lack of an overall business process for error management, lack of technical foresight on part of the BA/Dev, a valid request or other? How can you minimize these types of problems?

Other details (specific to this app)
Web app. Persistent State is an overall part of the design (thus the reason you see the report still displayed). There are little to no HTTP POST/GET operations performed outside of AJAX. Navigation menu changes pages without full postbacks. Instead, perform HTTP GET to load HTML/JSON into portions of the web page on click.

  • If you are looking for a formal term for the problem, you may have better chances with the crowd at ProjectManagement.SE... But as @HLGEM writes, "poorly defined requirements" is a good definition of what you are facing.
    – yannis
    Nov 7, 2011 at 23:05

3 Answers 3


The problem is called human nature. It's very difficult to anticipate these sorts of problems without seeing a working implementation, both for developers and requirements writers, although with experience on similar work you get better at it.

Most modern software processes acknowledge this fundamental difficulty and focus instead on tightening the feedback cycle. Instead of working for 3 months and shipping something you deem complete off to QA, you let him see it in whatever state it's in every 2 weeks, or even sooner. If a developer has a choice of how to act in an error condition, he asks the BA right then instead of just guessing or doing whatever is easier. If your feedback cycle is already tight, but the changes annoy you because they seem "unplanned," then plan for them. Schedule in some time for fixing requirements issues found in QA.

  • +1 U r right on target. Feedback does not occur until the very last line of code is checked in. Nov 7, 2011 at 23:16

Most likely it is poorly defined requirements. The best way to minimize stuiff like this, in my opinion, is to push the Ba from the start to make the requirements more descriptive. When you first get them. Ask him how you want the system to handle bad data entry or other things that you think from previous experince have not been adequately covered. In my expereience most BAs don't know what to put into the requirements once you get away from the fields on the User interface. You need to push back virtually all requirements and ask for what you need to handle errors correctly, to handle what needs to go on behind the scenes, etc. If you see a decision place in the requirement, make sure to ask what happens if the less common decision is made (for instance suppose there is amanger approval, many BAs won't tell you without asking what should happen if the manager disapproves the request). The sooner you push back for more answers the less rework is needed.

To help you with this, keep a running list somewhere of what requirements changes you had for things that should have been defined but were not. Then you will know what things to ask about the next time you get a requirement. Fixing a poor requirement is the single best way I know to save time and money on a project.

  • I can't find the image but I saw in a presentation once a pyramid that demonstrated the relative cost of a missed requirement throughout the SDLC. During requirements planning phase it was a cost of 1 at the peak of the pyramid, but each step of the SDLC down the pyramid represented an exponential increase of cost with Maintenance/Post Production being the most costly.
    – maple_shaft
    Nov 8, 2011 at 1:25

scope creep, poorly defined requirements, lack of an overall business process for error management, lack of technical foresight on part of the BA/Dev, a valid request

All of the above... Seriously... EVEN a valid request.

  • It is scope creep because a new feature made its way into the release requiring more development and threatening the success of the project.

  • It is poorly defined requirements because this requirement that the BA wanted was missed in the formal specification.

  • It is lack of overall process in that you are lacking Change Control in your project management. Let's face it, requirements get missed, but change control helps prevent missed and new requirements from creeping in and threatening the deadline of the project.

  • Lack of technical foresight because the requirements must have been reviewed by a tech lead or developer before the sprint/iteration and the developer didn't anticipate the technical issues that the poorly defined requirements COULD lead to.

  • It is a valid request because after all is said and done, the BA's and stakeholders are going to want the software to behave a certain way eventually. It is unfortunate that it was missed but the problem should be owned by the BA or application manager and added to the backlog for the next sprint pending priority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.