Requirements Specification - Hypermedia and the Web

The goal of this phase is to write a document containing a detailed specification of the functionality, and constraints on that functionality, of the Web application being developed by your team. Additionally, this document will contain revised and improved paper prototype or storyboard figures. Your requirements specification must contain the following elements (more details can be found in the template):

• Change Record: Every time the document is changed, an entry is made in this table.
• Table of Contents: Must show the functional grouping of requirements in the requirements section.
• Overview: Provides a high-level overview of the goals of the Web application you are developing.
• Reference Documents: Documents and Web sites that are useful in understanding the domain of the project, and the current document. For example, if you're developing a Web application for a specific organization, list its current Web site.
• Definitions: Definitions of important and specialized terms and acronyms used throughout the remainer of the specification.
• Classes of users: The kind of users expected to be using the system. For a Web application developed for a specific organization, the kinds of users might include the general public, members of the organization, officers of the organization, and full time staff members.
• Scenarios document feedback: (This section only applies if you have an external customer (i.e., if your customer is someone not associated with the class)). Comments and improved understanding developed from discussing the project scenarios document with your team's customer. There are two parts to this section:
  • A printout of an email message from your project customer stating:
    
    "I have read the project scenarios document produced by {your team name} and have discussed its contents with them. I am satisfied that the team understands the problem well enough to proceed with writing a detailed requirements document."
    
    
  • A written summary of any changes in understanding or functionality that resulted from reviewing the project scenarios document with your customer. The intent of this section is to make it easy for your customer to see what changes have occurred between the scenarios document and this requirements specification.
• Requirements: A precise description of the capabilities of the Web application. Each specific requirement must be individually numbered, so they can be referred to again in future documents. This usually means that every sentence or paragraph is numbered (depending on how concisely requirements are stated). These requirements can describe:
  • Functionality - define specific functionality, that is, what the application should do, not how it does it. If the functionality is specific to a particular class of user, that should be stated.
  • Performance - characteristics of the performance of the application, such as minimum acceptable levels, or maximum number of users
  • Usability - how users must be able to interact with the system, such as minimum times to learn system features
  • Constraints - limitations on the functionality of the system (e.g., no more than five players)
  • Wish list - system features that will be implemented if time permits

Requirements must be:

• Understandable: The meaning of the requirement must be clear from the text in the document.
• Unambiguous: Each requirement must have a single, clear meaning.
• No redundancy: Each requirement should be stated only once.
• Complete: Every functional behavior in the implemented project must appear in a requirement, and the requirements must capture the entire functionality of your modifications to the system. All functionality described in your scenarios must be described by a requirement.
• Consistent: The requirements must not contradict each other.
• Correct: The requirements must not specify invalid or undesirable behavior.
• Testable: It must be possible to construct a test that can be executed by a person who is not a member of the development team to determine whether the requirement is satisfied.

The user interface diagrams must capture all of the major menus, screens, behaviors, and dialog boxes of the project.

For more information, see the template.

Last updated: 4/20/2005