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, of your chosen project. Additionally, this document will contain a series of figures describing your project's user interface. 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 your system and its functionality. 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 libraries you are using, or rules of the game you are implementing.
• Definitions: Definitions of important and specialized terms and acronyms used throughout the remainer of the specification.
• Requirements: A precise description of your 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
• Coding Standards - rules for organizing and formatting your source code. You can choose any established set or make up your own, but we recommend the Sun Java Coding Standards.
• Preliminary User Interface: A series of sketches showing the user interface of your 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 and grading guidelines. There is also some example documents from last quarter that may be helpful.