Writing a Requirements Document
By G.E. MorrisNote:
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 descrīption 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 (seeWriting 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:
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 訤irst 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.
