Inadequate requirements and what to do about them
Software requirements are often subjective and poorly written resulting in inadequate requirements documentation. In this tip, QA Director John Scarpino describes some of the reasons behind poor requirements and ways that this can be addressed.
John Scarpino
In my own professional experience, I've witnessed an increasingly common practice of business analysts and project managers providing software testers with very few requirements, if any, against which to test and little guidance during the creation of test plans and procedures. It is also becoming more common for requirements to be written subjectively instead of objectively – those who write the requirements are often the same people who are expected to test them. Of course, both of these situations defeat the purpose of having requirements, which is to guide and communicate the business, system and/or customer information to quality assurance, development, infrastructure and related departments. Why is this such a common problem and what can be done?
Just a check box
These days, it seems as if requirements are being generated simply to fulfill the industry expectation of having them (i.e., "we do this because it's what my boss says we're supposed to do") as opposed to fulfilling an actual need for information to communicate the system, business or impact to the customer. And when project timelines are reduced (as they often are), so is the time available to create effective requirements. Software testers are being forced to deliver results within a shorter time than originally planned, thereby driving them to accept whatever documentation is given to them, no matter how vague.
Why has this become such an issue lately? One explanation may be that the high rate of turnover in today's Information Technology organizations is taking a toll on innovation and quality. Unstructured business environments can make employees more concerned with choosing colors for a flowchart than producing meaningful documentation for development, software testing, the business and its customers. As more people leave a company, the expectations rise for employees who remain. Corners may be cut for the sake of saving time. It pains me to see more external documents being created within the IS/IT industry to fulfill customer requests than detailed, internal documents to help further the project's quality for the customer. What's really happening here is that we're putting on a façade, whether we realize it or not. As long as the customer is happy with the documents we give them, they don't know any better – at least for a while. We are giving the customer an impression that everything is under control, while the process behind the scenes lacks quality assurance and constructive test plans and test development.
Balance between customer requests and quality
I'm not saying that making your customer happy isn't important. On the contrary, I believe good customer service and relationship-building is a crucial pillar that bolsters any IT company's success. But when "making the customer happy" comes at the expense of your product's or service's quality, it is necessary to take a step back and evaluate why your BAs feel like they have to give in to the customer's every demand. Your company's reputation will eventually suffer if they don't learn how to say "no." There will always be some customers who think they know software / technology development better than your IT organization; they will argue with you to do it their way, even if "their way" is clearly not the right way. Saying "no" to these customers can be tricky, but if done in a professional manner with the right information backing up your claims (case studies from past successful rollouts are wonderful resources to share) you'll likely see that light above their heads flip on. The majority of customers do understand the value of quality done right – or they wouldn't have hired your expert organization. And these are the same customers who won't mind if your BAs spend less time on drawing up documentation if it means that your company can deliver a better product. They are also the kind of customers who will keep coming back to your business.
Include the right people in requirements meetings
The presentation of inadequate documentation will inevitably start a blame-game, especially if quality issues are brought up by a defect or system failure. If the system is broken it must have been a glitch that occurred during the development phase. Or, it is QA's fault because they didn't test the product thoroughly enough. Hardly is there a thought that the problem occurred because requirements did not make sense to begin with; they were passed down through the lifecycle by people who didn't create them in the first place; and those individuals weren't given any direction by the people who did create them. Therefore, take care during the analysis phase to make sure you have the right people in requirements meetings, so that the right information is passed on in the right manner. Pointing fingers at one particular group or department when a quality issue pops up does little but make tempers flare. The quality issue itself is usually just a symptom of a larger problem with organizational communication. It is completely up to each department or team to ensure their roles operate at the highest quality standard, and communicate if they are not receiving the appropriate support.
Accept change
While communication is key, so is the ability to accept change. There is no such thing as a "perfect process" within the software development lifecycle. The customer's acceptance of the product does elevate the project's success, but one must also consider if the product was created with a quality approach throughout its lifecycle. Again, if quality assurance is valued from the beginning of a project and carried through the end, there is a 99.9% chance of a greater quality outcome. I am not inferring that process and procedures should never change. No matter how perfect you think your process is, there will always be a need for modest change to processes and procedures as technology evolves. In most cases, the process will get better. Organizations that resist adopting even small changes for the sake of increasing the quality of process and procedures, risk being unable to innovate and grow with its competitive set (usually the opposition is based on "if its not broke, don't fix it").
Create a culture of quality
A culture of quality is imperative for the creation of good requirements. Yes, meeting deadlines and staying on budget is important, but if those are the only things your company is worried about then you have a long road ahead. Several aspects of quality assurance are to develop pockets of productivity, enhance communication, analysis, design and signoff of requirements. Without proper quality assurance, the requirement documents will become virtually meaningless.
To conclude, it is up to the technology offices and senior management to recognize, support and lead requirements initiatives and other quality-related strategies. A "quality" mindset must trump a "deadline-driven" one. If not, then software projects will be more costly in terms of money, time … and ultimately, customers. Operating from a quality mindset helps to fill-in the holes among process and procedures, ensures that the requirements are effectively working towards customer satisfaction and improves the engineering, testing and overall quality of the end product.
About the author
Dr. John Scarpino is director of quality assurance and a university instructor at Robert Morris University in Pittsburgh. You may contact him at [email protected].
