Software Specification Document

Quality Assurance Checklist

General QA Criteria

Content / Format

The document should conform to a standardized format such as IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications.
 

Correctness

The document must be technically correct. The content of each section must fulfill the purpose for which it is intended. All diagrams must follow the appropriate notation.

Writing

The document must be well written.  The writing must meet the standards of the Cal Poly Writing Proficiency Exam level 4 or greater. If you have questions about writing style, refer to a standard style guide such as:  MLA Handbook for Writers of Research Papers.
 

• Is each requirement is simply stated in english?
• Is the document free of spelling errors?
• Is the writing grammatically correct?
• Does the writing use present tense, active voice with transitive verbs, and 3rd person writing?
• Does the writing avoid vague terms such as those in Dan Stearns' bad words list?

Functional Requirements

This section is the core of the document.  It specifies exactly what functionality the system will provide.

Clarity
It is essential that the requirements be clear to all readers so as to prevent ambiguity and misinterpretation.

• Are the requirements written in user language? Do the users think so?
• Are the requirements written in non-technical  language that uses the vocabulary of the client problem domain?
• Are the requirements stated simply and completely so that they are unambiguous.
• Are the requirements stated clearly so there is only one interpretation?
• Do the requirements describe only EXTERNAL behavior, as seen from the user's point of view?
• Do the requirements avoid stating how the problem is to be solved or what techniques are to be used.
• Do all data and processes exist in the problem domain, not the solution domain?
• Is every noun a term from the data dictionary?
• Is every noun emphasized in some way in the document (e.g. underlining) and use the exact DD term?
• Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail?
• Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?

Completeness
A correct, complete set of requirements is one that correctly and completely states the desires and needs of the sponsor. If the requirements are incorrect, the software may meet the requirements as stated, but will not do what the sponsor wants it to do. If the requirements are incomplete, the software may do only part of what the sponsor hoped it would do.

• Is each characteristic of the final product described?
• Are all the tasks the user wants to perform specified?
• Is each requirement relevant to the problem and its solution?
• Are all the inputs to the system specified including their source, accuracy, range of values, and frequency?
• Are all the outputs from the system specified including their destination, accuracy, range of values, frequency, and format?
• Does each function specify the data used in the function and data resulting from the function?
• Are all aspects of the processing specified for each function?
• Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable?
• Do the requirements contain no implied design details?
• Do the requirements contain no implied implementation constraints?
• Do the requirements contain no implied project management constraints?

Consistency
Consistency is obtained if the requirements do not contradict each other. Inconsistency results when one requirement contradicts another.

• Is each requirement unique? (I.e., no redundancy)
• Do all the requirements avoid conflicts with other requirements?

Traceability and Modifiability
Ultimately every aspect of the finished system should be able to be traced back to the requirements.  Therefore this document should be organized to facilitate tracing the requirements into subsequent work products.

• Does the organization adhere to an accepted standard?
• Is the document organized in a segmented, top down manner?
• Is every requirement numbered in a manner that facilitates cross referencing and indexing?
• Can each item be traced to its origin in the problem environment?
• Are all possible changes to the requirements specified?

Verifiability
The requirements must be verifiable in two ways: do the requirements satisfy the sponsor's needs, and does the system satisfy the requirements? In the first case, the requirements must be compared to the sponsor's desires and needs. Do the requirements correctly and completely specify the sponsor's desires and needs? In the second case, once the system has been developed, it must be compared to the requirements. Does the system meet the requirements as they are stated?

• Are all of the requirements feasible? (I.e., possible to implement)
• For each requirement is there a process that can be executed by either a human or a machine to verify the requirement?
• Is each requirement testable or verfiable? Will it be possible for independent testing to determine whether each requirement has been satisfied? 
• Does the writing avoid vague terms such as those in Dan Stearns' bad words list?

Nonfunctional Requirements (Quality Attributes)

This section describes any attributes required of the system that don't provide a function or capability, but some other desired attribute or characteristic. Another way of saying it, is that this section specifies how much quality is required.

These requirements are subject to the same criteria as the previous section.  Special attention must be given to stating the requirements in a manner that is objective and quantifiable; there must be some measurable way to assess whether the requirement has been met.

Consult this online reference as well as your textbook.

Appendices

The appendices contain technical material that is more relevant to the developer than the customer.  Included here are any work products created during the analysis process.

Data Dictionary

• Are all required data from problem statement included (there is a data item for each noun in the problem statement)?
• Do the items describe only EXTERNAL data (i.e, data that is entered by or displayed to the user). No "internal" data, temporary variables should be described. "External" data is what goes in or out of system, not what is involved in intermediate calculations, or what stores data during processing?
• Do the items define only data, not processes?
• Is each item unique? (No redundant entries).
• Are the items consistent with analysis model and the functional requirements?
• Does each item have a definition that uses a standard DD notation?
• Does each item have a description in english?
• Are composite items distinguished from elemental items.
• Do composite data items show the "decomposition" into other data items?
• Do elemental data items show data type; Enumerable types should list all values, continuous and discrete types should list allowed range of values. (Examples: character A-Z, integer 1-99.)

Report Formats

Are all the report formats specified?

Analysis Model

Do all charts and diagrams follow the corresponding notation?

Engineering Analysis (Tradeoffs)

• Is a rationale provided for all significant issues? I.E., is there documentation for any significant analysis decision?
• Are acceptable trade-offs specified for competing attributes?
• Were all possible alternatives considered?.
• Did the analysis used objective and where possible, empirical, criteria?
• Are all tradeoffs documented and the results of an unbiased decision reported?