I like the definition for Software Quality Assurance the I found on InfoBeagle.com, it states "Quality assurance is defined as a set of procedures designed to ensure that quality standards and processes are adhered to, and that the final product meets or exceeds the required technical and performance requirements. Quality assurance is a widely used approach in the software industry to improve upon product delivery and the meeting of customer requirements and expectations."

So, if software quality assurance is defined as meeting or exceeding the required technical and performance requirements, then the process of creating these requirements is the root where all quality is derived for software. Sure there are quality processes that are put in place during development which add quality to the end software product, but these are designed to meet the originally defined customer specifications.

The input used to create user requirements must be considered very carefully and the correct people must be involved in the process of gathering these requirements to ensure the end system meets each need of the business process. Business process mapping must be done first and then assigned to functions of the system to ensure that each business process is accounted for in the final user requirements. If business mapping is left to be an implementation step, then no amount of adherence to requirements will help the end users perform their business process tasks with the new system.

A common mistake to make while deploying software, especially software like a global LIMS system, is that the new system should replicate all functions of the current electronic or paper system. This is the wrong approach to gathering user requirements. Instead, the complete business process must be determined and written down as the very first step prior to determining all of the steps that must be executed to perform each business process. This top down approach will allow for the end users to avoid missing any key steps in their process that should be met with the new system.

Once the user requirements are determined, the functional requirements can be written by the design team. Beyond producing the functional requirements that will drive the development cycle, the design team should provide a written document in end user level language of exactly how the new system will address each of the high level business processes. This will allow the user community to review and accept the approach defined by the design team to meet their required business practices. This approach should minimize the number of 11th hour design updates to meet go-live requirements and remove the difficult task of fitting a known business process into a developed system. With this approach to forming system requirements, end users take responsibility for how they will be using the system and hopefully remove any surprises of lack of functionality.