Our new QA section
explains how to make
your Website work the
way you need it to!
Fonts.com
 

2008


Home Page
Feature Archive
A&I Column Archive
Production Tools
State Marketing Data
US Marketing Data
World Marketing
Classifieds
Service Directory
Quality Assurance
3D Printing

Subscribe to Advertising & Marketing Review!
Contact Ken Custer at 303-277-9840.


Writing a Requirements Document


By G.E. Morris

Note: This article is from our forthcoming book, "A Basic Guide to Website Quality Assurance." This article explains how to write a Website requirements document which specifies what a Website is actually supposed to do, and how it will be structured. This article assumes that you already have determined what the structure and function of Website should be. This issue is a topic unto itself will be covered in another section.

The product requirements document is the cornerstone of product quality. Without it, the chances of getting a quality product a very small. If you don't know exactly what a program is supposed to do, it's impossible to tell if it really does it.

In this example of a two field registration form, a product requirements document has been created that specifies exactly how the page should look and perform. The lengthy description is not overkill. In fact, this is about the bare minimum of documentation that could be used that could create a quality program.

The structure of the requirements document is nearly identical to the structure of a test case document. especially relative to numbering. Done properly, each requirement should have a test case with the same number.

In the previous example of testing a simple registration form (see Writing Thorough Test Cases), the number of test cases required to test a two field registration page increased to over two dozen. Even this number might not be enough. So how do you really know when you have enough test cases?

A good way to handle it would be to base the test cases on the product requirements document. This method establishes a one to one relationship between the requirements document and the test case document, so that every requirement has a corresponding test case (to be precise, both documents will use a corresponding numbering system so each test case will be numbered the same as its requirement).

Another reason for this approach is that it establishes a written document specifying exactly what QA is responsible for testing, and what QA is not responsible for testing. This approach puts the burden of determining coverage on whoever is responsible for defining the product requirements (which by definition is usually not QA).

So what does a product requirement document look like? Well, the usual format is a multiple number system with numbers separated by periods, as in 1.1.1. for example. This format makes it easy to insert additional requirements and test cases without having to renumber the whole document.

In applying the multiple number format to a product requirement document for the two field registration Webpage, the first number will represent the general category of tests like page appearance or individual fields, the second number will represent a type of tests, like field validation, and the third number will represent specific variations of field validation tests. Requirements and test cases ending in 0 are sub-titles.

The Registration Form:

Registration Form

Enter your first and last names and click the Submit button.

First Name:

Last Name:



The requirements document should have several sections, each dealing with a specific area of the product. The general format would look like this:

1.0.0 General Page Appearance Requirements

2.0.0 First Name Field requirements

3.0.0 Last Name Field requirements

4.0.0 The Submit Function


Registration Page Requirements Document

1.0.0 General Page Appearance Requirements

1.1.1 The title "Registration Page" shall be left aligned at the top of the page.

1.1.2 The words "Registration Page" shall be spelled correctly.

1.1.3 The words "Registration Page" shall be in 26 point type.

1.1.4 The words "Registration Page" shall be in sans sefif type.

1.2.1 The instructions "Enter your first and last names and click the Submit button." shall appear left aligned below the title.

1.2.2 The words "Enter your first and last names and click the Submit button." shall be spelled correctly.

1.2.3 The words "Enter your first and last names and click the Submit button." shall be in 12 point type.

1.2.4 The words "Enter your first and last names and click the Submit button." shall be in sans sefif type.

1.3.1 The words "First Name:" shall be left aligned below the instructions next to The First Name entry field.

1.3.2 The words "First Name:" shall be spelled correctly.

1.3.3 The words "First Name:" shall be in 12 point type.

1.3.3 The words "First Name:" shall be in sans sefif type.

1.4.1 The words "Last Name:" shall be left aligned below the label ‘First Name" next to the Last Name entry field.

1.4.2 The words "Last Name:" shall be spelled correctly.

1.4.3 The words "Last Name:" shall be in 12 point type.

1.4.4 The words "Last Name:" shall be in sans sefif type.



2.0.0 The First Name field

2.1.1 Entry with a blank First Name shall result in an error message being displayed saying The First Name must be filled in.

2.1.2 Entry with a valid First Name shall be accepted.

2.2.0 First Name field maximum characters.

2.2.1 First Name field will accept a maximum of 50 characters.

2.2.2 First Name field will not accept more than 50 characters.

2.2.3 If more than 50 characters are entered in The First Name field an error message will be displayed saying "The First Name field will not accept more than 50 characters."

2.3.1.0 The First Name field will not accept numbers.

2.3.1.1 Entry with numbers in The First Name field shall result in an error message being displayed saying "The First Name field will not accept numbers."

2.4.0 First Name field character restrictions.

2.4.1 First Name field will not accept the characters: "`~!@#$%^&*()_:";'{}[]+<>?,./".

2.4.2 If any of the characters: "`~!@#$%^&*()_:";'{}[]+<>?,./" are entered in The First Name field an error message will be displayed saying "The First Name field will not accept the characters "`~!@#$%^&*()_:";'{}[]+<>?,./".

2.4.3 First Name field will accept the 50 character: "-".



3.0.0 The Last Name field

3.1.1 Entry with a blank Last Name shall result in an error message being displayed saying The Last Name must be filled in.

3.1.2 Entry with a valid Last Name shall be accepted.

3.2.0 Last Name field maximum characters.

3.2.1 Last Name field will accept a maximum of 50 characters.

3.2.2 Last Name field will not accept more than 50 characters.

3.2.3 If more than 50 characters are entered in The Last Name field an error message will be displayed saying "The Last Name field will not accept more than 50 characters."

3.3.1.0 The Last Name field will not accept numbers.

3.3.1.1 Entry with numbers in The Last Name field shall result in an error message being displayed saying "The Last Name field will not accept numbers."

3.4.0 Last Name field character restrictions.

3.4.1 Last Name field will not accept the characters: "`~!@#$%^&*()_:";'{}[]+<>?,./".

3.4.2 If any of the characters: "`~!@#$%^&*()_:";'{}[]+<>?,./" are entered in The Last Name field an error message will be displayed saying "The Last Name field will not accept the characters "`~!@#$%^&*()_:";'{}[]+<>?,./".

3.4.3 Last Name field will accept the 50 character: "-".

4.0.0 The Submit Function

4.1.1 Entering a valid first and last name and hitting the Submit button shall result the names being added to the registration list.




For more advertising and marketing help, news, resources and information visit our Home Page.


Back to top



QA and the Software Development Lifecycle

CMMI Levels

Writing Repeatable Test Cases

Writing Thorough Test Cases

Writing Product Requirement Documents

Basing Test Cases on Requirements Documents

Test Case Formats

Multipart Test Cases



Constant Contact -- FREE Email Marketing

null