Generally web site projects contains information that describes the output of the project’s effort; this information deals with the objectives of the final product, defined in the project requirements, and any rules for creating the product, defined in the project specifications.
Requirements Define Necessary Objectives
Any project must have requirements that define what the project is ultimately supposed to do.
There are actually several kinds of requirements; the term requirement is awkward because it describes the concept of an objective or goal or necessary characteristic, but at the same time the term also describes a kind of formal documentation, namely the requirements document. Putting aside the particular document for now, requirements are instructions describing what functions the software is supposed to provide, what characteristics the software is supposed to have, and what goals the software is supposed to meet or to enable users to meet.
A general set of requirements would include documents spelling out the various requirements for the project as well as specifications documents spelling out the rules for creating and developing the project .
Project requirements provide a tool for evaluating the quality of a project, because a final review should examine whether each requirement has been met. Unfortunately, it’s never quite that easy. Requirements tend to change through the course of a project, with the result that the product as delivered may not adhere to the available requirements — this is a constant and annoying facet to the quality assurance process. Moreover, meeting all of the requirements doesn’t ensure a quality product, per se, since the requirements may not have been defined with an eye towards the quality of the end-user’s experience. A project’s specifications are more useful for determining the product’s quality.
Specifications Define How to Meet The Objectives
A specification is literally the discussion of a specific point or issue. A project’s specifications consist of the body of information that should guide the project developers, engineers, and designers through the work of creating the software.
A specification document describes how something is supposed to be done. This document may be very detailed, for example, a specifications document may list out all of the possible error states for a certain form, along with all of the error messages that should be displayed to the user. The specifications may describe the steps of any functional interaction, and the order in which they should be followed by the user. A requirements document, on the other hand, would state that the software must handle error states reasonably and effectively, and provide explicit feedback to the users. The specifications show how to meet this requirement.
Specifications may take several forms. They can be a straightforward listing of functional attributes, they can be diagrams or schematics of functional relationships or flow logic, or they can occupy some middle ground. Specifications can also be in the form of prototypes, mockups, and models.
Project specifications are much more important for determining the quality of the product. Every rule and functional relationship provides a test point.
A critical part of the quality assurance role is proactive involvement during the project requirements analysis and specification phases, where the rational and customer-centered point of view of the QA analyst can be applied to the project’s rules before any code is written. The return on investment (ROI) of this up-front QA involvement has been shown to pay off: several studies have determined that companies will have to pay less to fix problems that are found early in any project cycle. Catching problems when the requirements and specifications are being hammered out is the ideal time to head off problems.
6 test points to be covered when reviewing requirements and specifications are:
- Are these the “right” requirements?
- Are they complete?
- Are they compatible?
- Are they achievable?
- Are they reasonable?
- Are they testable?
0 comments:
Post a Comment