Requirements and UI Prototype - Software Methodology

The goal of this phase is to write a document containing a detailed specification of the functionality, and constraints on that functionality, that you are adding to your chosen project. Additionally, this document will contain a series of figures describing your best current understanding of the project's user interface (that is, the user interface elements corresponding to the functionality you are adding to your project). 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 original system, and the functionality you are adding. This is similar to the text from your project proposal, but with modifications based on your current, improved understanding of the project.
• Reference Documents: Documents and Web sites that are useful in understanding the current document. For example, the Web site of the project you're modifying, along with useful documentation on that project (user's manual).
• Definitions: Definitions of important and specialized terms and acronyms used throughout the remainer of the specification.
• Requirements: A precise description of your modifications to the chosen system. These requirements can describe:
  • Functional - define specific functionality, that is, what the system should do, not how it does it
  • Performance - characteristics of the performance of the system, such as minimum acceptable levels
  • 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
• Preliminary User Interface: A series of sketches showing the user interface of your modifications to the project. Carefully hand-drawn sketches are acceptable.

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: 10/7/2002