The software development is a very long and complex process, which requires surplus amount of time, cost and efforts. As such, failure of the software project or product would not be acceptable, by any of the organization, keeping in account, the large investment, made by them. However, the organization needs to identify and explore the root causes, behind such failures. Introduction or Involvement of bad requirements, in the software project, may be seen as one of the sources, which directs the development process, towards the failure state. Let's study the concept of bad requirement from a tester's perspective.
It simply means, requirements, which are considered bad, for the software project. In the field of software testing, bad requirements refers to, available specifications & requirements, which are, either inadequate or inappropriate, to carry out the task of testing a software product, so as to achieve the desired quality.
These bad or poor requirements, instead of working as a source, to a tester, to verify and validate the quality of a software product, creates hurdle, in their way, and produces chaos in the process, which may lead to poor quality product, and consequently, the project's failure, to deliver, desired product.
In order to backtrack, a problem/ issue or bugs/defect, with respect to requirements, it is first, necessary, to have the understanding of the possible bad requirements, which may likely, to appear, in the software project. Below given, are some of them.
It is one of the most difficult requirements, to be traced out, as it is completely missing and could not be found, in the documented artifacts. For example, in the event of any sort of failure, it would be hard, to trace and identify, which missing requirement, is responsible behind the failure.
This type reflects the state of confusion between the requirements, i.e. two or more than two requirements states the software application, to work or behave differently, for the same event, at a same moment of time. It may be seen as the result of lack of communication, between the team members or technical writers, involved in the gathering and analysis of the requirements, prior to development phase.
It involves, all those requirement, which are either incomplete or unclear and not being understood by the teams, so as to implement it, in the software architecture, through designing, coding, programming, etc.
The word "ambiguous" means, having more than one meaning. Therefore, ambiguous requirement may be inferred, as those requirements, which may be interpreted, in different ways, from multiple perspectives.
Bad requirements has become a common occurring scenario, in a software project, due to various factors, such as lack of communication, misinterpretation, wrong analysis, etc. As such, it seems, impossible to eliminate the possibility of bad requirements, in a software project. Therefore, to ensure success in the development project, it is better, to manage and deal with these bad requirements.
Following given are the approaches or ways, which may be considered, to handle or without relying on these requirements, to carry out testing activities, in an efficient and effective manner.
This method requires study and analysis of the existing application (if it is being rebuilt or modified) or the similar application, to explore the functionality, features, working and other such traits. Further, with the existing application, a tester have the opportunity, to go through, the previously set up test environment, along with the executed test suites, especially the regression test suites. Accordingly, a tester may design and create suitable test cases, and may ask for necessary help, if any required, from the respective teams.
An experienced tester may implement and make use of his/her experience, gained in the multiple or the respective domain, along with their in-built acumen, to extract out and understand the important and necessary requirement, required to perform testing. Through gained experience, a tester may think from multiple perspectives, including users-perspective, to grasp and understand the link between the requirements.
Tools, like HTML design and wireframes, may be used, to visualize the workflow, internal structure and behaviour of a software product, in order to understand a software product, in detail, which may subsequently, helps in visualizing the understanding the requirements, in a better way. However, this method requires participation of business analysts, who will be responsible, for signing off the requirements, after going through it.
Discussion and meetings with the colleagues and peers may prove, to be an effective step, in direction of having better understanding of the requirements. Discussions and meetings, involves the participation of multiple number of professionals and members, engaged in multiple domains. As such, this method perceives the involvement of multiple brains and eyes, to think and visualize, about the requirements, differently, which may eases the task to understand the requirements, from multiple perspectives.
A better way to have crystal clear understanding of the requirements, directly from the customer or client, itself. However, it would not be advisable to hit a customer, with enormous number of questions. A tester, may make use of certain formats or documents, such as checklist, to ease the task of extracting requirement's, from a customer, in short and precise manner.
A change management system, is a must requirement, to cater the need of tracking and controlling the upcoming and changing requirements. The reports and outcomes of the change management process/system may prove to be fruitful, in deriving and designing the suitable and effective test cases.
IIn nutshell, it may be stated that the bad requirements, not only increases the complexity of a software development project, but also increase the burden of the work, which is required, to rework on a software product. Hence, managing these requirements may be seen as the only way, to avoid or minimize the quantity of the bad requirements.