COLUMN

Software requirements sign-off essential for solid QA

By John Scarpino 11 Apr 2008 | SearchSoftwareQuality.com Software quality news and advice Digg This!     StumbleUpon     Del.icio.us

John Scarpino

Requirement sign-offs and requirement traceability are essential in the software development lifecycle -- especially when it comes to quality assurance.

In certain situations, the software development phase can start during the end of the requirements-gathering process. The problem is developers often believe that the quality assurance (QA) team will always be able to find any issue with the software that may have been missed during the development phase. But, if the project's requirements were not signed-off prior to moving into the QA phase, how can the QA team be expected to ensure that the product will hold up? This is a concern that can arise within basic software development lifecycle techniques along with modern ones such as Agile and Extreme Programming. I have dubbed this all-too-common problem "requirement abuse."

There is an underlying agenda that acts as the driver of requirement abuse, but it shouldn't come as a surprise. Companies try to reduce the time it takes to deliver a product to a client, therefore cutting corners wherever they can. Adhering to requirements is usually what ends up being thrown to the wayside.

The whole essence of QA entails that the requirements are met and the project's needs are being matched to what the client desires.

A defect is only truly considered a "defect" when it can be traced back to a requirement that shows how the problem could have been avoided if the software was developed properly. If a defect is found but is not traced back to a requirement, I consider it to be an "enhancement." If a defect is known to pose a true problem, it would have been thwarted in the requirements for the project. A "defect" in this sense is really just based on personal opinion of how much it affects the product -- when, in reality, it should be considered an enhancement.

When a problematic issue with a software product arises, an evaluation must be conducted to find the root cause of the problem(s). After all, if you want to prevent it from happening again, you must attack the source, not the symptom. There are many reasons for a defect to occur: incorrect/inadequate testing, a sloppy test plan and/or documentation, unclear requirements given by the business analyst or the customer, and overall poor development, to name a few. This is why requirement sign-offs are so imperative to the vitality of a project.

People often have the misconception that a project's requirement is the same as a project's "need." Although you can't have one without the other, they are not the same thing. Within the software development lifecycle, developers are constantly adapting and measuring what the project "needs" based on the already-decided-upon requirements. Only at the end of the entire process, when development is signed-off by the client, can "needs" be considered on the same level as requirements.

The whole essence of QA entails that the requirements are met and the project's needs are being matched to what the client desires. When the requirements are documented during the beginning of the project, the QA team tries to anticipate any issues that may arise, according what the client wants. This is one reason why QA should closely follow the client's mindset. Project management, development and business analyst biases should not have a bearing on the process of meeting the requirements. But many times the QA team is controlled, in one way or another, by a timeline, politics or departmental change. When that happens, the project is prone to defects. Of course, defects increase the project's delivery time and therefore decrease customer satisfaction, ROI for all parties involved, and overall quality.

More information on creating quality software The struggle to create quality software How poor management skills jeopardize software quality Quality process first; quality testing second

Having a customer sign-off is key for any and every type of software testing procedure. When it comes to the requirements of a testing process, a question that can easily arise is, "When is it [the software] good enough?" Therefore, the best way to ensure that the proper requirements (technical, functional, non-functional and design documents) are met is when the project is signed off by the customer and approved by the business. At this point, any new changes to the requirements are considered out of scope and a change request must then be made. If no sign-off occurs, the software development process will eventually loose control of the project.

Software development firms should not confuse this approach with the kind of flawed mindset that says, "We allow our customers to make as many changes as they see fit, just as long as we can keep their business." After all, if the customer is allowed to take control of software development, then why should there even be a QA department? Sadly, many of the problems that arise within the QA testing stage are due to this.

Software development companies are sometimes afraid to end what is called "scope creep" -- the lengthy process of never-ending changes -- for the fear of losing business. Clients who have been in the business for a while know that this kind of behavior is, essentially, a "Welcome" doormat. Thus, many take advantage of their software company's eagerness to please, which ultimately results in incorrect SDLC procedures. I recently saw a doormat that indicated "Your Not Welcomed" and I immediately thought about the aforementioned scenario. Once requirements are signed off, a software company should not accept the customer's request for change (until next cycle). But if they do, it should be kept at a minimum.

Added features, but no added project time
During many projects I've worked on, project deadlines stand firm while the client continues to ask for changes. When a software development company is caught in the rut of scope creep, the customer generally does not allow for the project's timeline to be adjusted accordingly -- thereby severing the amount of time allotted for QA to conduct testing. This ultimately makes the QA tester's job a constant hassle. What was once two or three weeks allotted to get the job done suddenly shrinks to two or three days. To make matters worse, the client still expects the software to have the full range of testing completed by the project's end. I even heard a senior manger say to a tester, "This needs to be tested and finalized by this weekend -- even if you have to buy a cot and sleep here."

Companies that are truly mature and successful recognize that "client sign-off first" should be a mantra that is practiced throughout the entire organization. Employees must be ready to adhere to this process even before taking on their first client. That's not to say that a preliminary development concept couldn't begin without a sign-off, but the meat and potatoes of the development cycle (test design and test planning) must be postponed until the client signs off on the previous elements (namely, the requirements) of the project. That's because the development cycle is based on requirements so as to ensure that both software and infrastructure activities align with each other.

Need to be able to trace requirements
After sign-off it's imperative to have a viable way to trace the requirements. Creating a traceable trail of all testing activities, including the repair of software defects, ensures that the development cycle's workflow is properly documented. If a developer or business analyst has a question about the history of the project or about what was determined to be the cause of a defect, traceability makes certain that they can easily find the answer. Having clear documentation is also important for audits. From changes to requirements, to QA, to development, to the final sign-off, the entire process needs to be proved. If not, many audits will be deemed invalid.

Before the process of quality assurance can begin, the following must be observed:

1. Sign off on requirements to prevent detrimental risks from surfacing.

2. Have proper documentation from both business analysts and project management, including design documents and/or technical, functional and non-functional specifications.
   
   Note: Be cautious of the "smoke and mirrors" approach, which some PMs and BAs use as a way to make the cycle seem to be moving along fine but in reality nothing is being accomplished. This goes for requirements, documentation and milestone planning. (Now, if they actually mention "smoke and mirrors," then you are in trouble!)

3. Analyze requirements to create test plans and to design a testing workflow.

4. Execute tests and report on them. At this point QA acts as a PM to ensure the re-works are delivered on time and correctly, but do not feel that you are done. Work with development in a friendly manner and be sure that development is responsive to the issue.

5. Allow some time for preparation (again depending on your tests) to make sure that the production changes before the project is delivered to go live.

If the above issues are not addressed, risks can occur within the software development phase of the QA process. As Philip Crosby indicates, "Quality is free," but at the same time if the proper steps are not made to ensure quality before the testing process begins, then it will only cost both the client and the software development company more money in the long run -- not to mention give you some pretty disgruntled QA employees.

-----------------------------------------
About the author:John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.

Tags: Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions),  Software Requirements Documentation,  Software testing and quality assurance (QA) fundamentals,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions) Why business analysts are application development key players today Defining report requirements with use cases When it comes to requirements, what is 'just enough'? How requirements use cases facilitate the SDLC GatherSpace beefs up cloud-based requirements management Software development life cycle phases, iterations, explained step by step How to deliver, implement testable software requirements Excelling in the art and science of requirements elicitation Software requirements: Moving beyond use cases Mastering key requirements phases Software Requirements Documentation VisibleThread aims to boost IT documentation quality, improve processes When it comes to requirements, what is 'just enough'? How to deliver, implement testable software requirements Blueprint rolls out Requirements Center 2010 Writing a software requirements specification (SRS) for a portal app Should QA check changes from outside the requirements document? Agile software development tutorial: Agile requirements gathering Defining requirements during software project feasibility analysis Template for requirements use cases What should a business analyst's requirements document include? Software testing and quality assurance (QA) fundamentals Software Testing: New software testing technologies bring new challenges Testing strategies for complex environments Astronaut's STPCon advice: Teamwork delivers "The Right Stuff" How to make your software tamperproof Software consortium seeks standard quality metrics Demo: Using WebGoat, a free software testing tool Seven steps for a quality change and configuration management program Winning responses to "Why is QA always the bottleneck?" Where to find good methodology guides for software testing 5 ways to answer executives' unfair software test, QA questions

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary requirements analysis  (SearchSoftwareQuality.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary