Requirements Analysis Document

 

STARS3 Project

15-413 Software Engineering

Fall 2000

Carnegie Mellon University

Pittsburgh, PA 15213

 

 

 

 

 

 

Revision History:

Version R0.1 9/15/98 Robin Loh. Created

Version R0.2 9/14/98 Joyce Johnstone. revised template

Version R0.3 9/21/00 Joyce Johnstone. revised template

Preface:

This document addresses the requirements of the STARS3 system. The intended audience for this document are the designers and the clients of the project.

Target Audience:

Client, Developers

STARS3 Members:

(List STARS3 team members)

INSTRUCTIONS
We encourage you strongly to coordinate your section with other teams via Lotus Notes bboard, discussions in team meetings, architecture API meetings, documentation liason and on the discuss bboard. Submission (must be a HTML document):
  1. Copy this document from the course homepage.
  2. The questions provided under each section are to help you brainstorm for ideas and offer suggestions. You must elaborate on them and produce coherent and descriptive paragraphs. Links to examples from the RAD of the JAMES project are also provided.
  3. Submit your RAD by posting them on the Review of Documents bboard.
MILESTONES

1.0 General Goals

For this section, enter the goals of your subsystem, i.e. what are the objectives of the functions of your subsystem?
Example:JAMES Bonus Subsystem General Goals.

2.0 Current System

For this section, describe the current situation that is relevant to your subsystem.
Example:JAMES Vehicle Subsystem Current System.

3.0 Proposed System

For this section, describe the proposed solution (i.e. your subsystem) under the following headings.
Example:JAMES VIP Subsystem Proposed System.

3.1 Overview
For this section, give a top-level description of your subsystem.

3.2 Functional Requirements
For this section, list out the functional requirements of your subsystem.

3.3 Nonfunctional Requirements
For this section, list out the non-functional requirements of your subsystems in the following headings.

3.3.1 User Interface and Human Factors

For this section, you will have to think about the interaction between the potential users and your subsystem. Consider the following:
What type of user will be using the system (expert, novice, etc.) ? Will more than one type of user be using the system? What sort of training will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from making errors? What sort of input/output devices for the human interface are available, and what are their characteristics?
Example:JAMES Maintenance Subsystem User Interface.

3.3.2 Documentation

For this section, focus on your plans for future subsystem documents. Consider the following:
What kind of documentation is required? What audience is to be addressed by each document?
Example:JAMES Travel Subsystem Documentation.

3.3.3 Hardware Consideration

For this section, think about the hardware issues that your subsystem will be facing. Consider the following:
What hardware is the proposed system to be used on? What are the characteristics of the target hardware, including memory size and auxiliary storage space?
Example:JAMES Logbook Subsystem Hardware Consideration.

3.3.4 Performance Characteristics

For this section, consider the performance requirements and limitations of your subsystem. Consider the following:
Are there any speed, throughput, or response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system?
Example:JAMES Bonus Subsystem Performance Characteristics.

3.3.5 Error Handling and Extreme Conditions

For this section, focus on the possible error occurrences and how your subsytem will deal with them. Consider the following:
How should the system respond to input errors? How should the system respond to extreme conditions?
Example:JAMES Logbook Subsystem Error Handling.

3.3.6 System Interfacing

For this section, think about the I/O of your subsystem. Consider the following:
Is input coming from systems outside the proposed system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must be used for input or output?
Example:JAMES Maintenance Subsystem System Interfacing.

3.3.7 Quality Issues

For this section, focus on the possible quality enhancement or compromises. Consider the following:
What are the requirements for reliability? Must the system trap faults? Is there a maximum acceptable time for restarting the system after a failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to different hardware or operating system environments)?
Example:JAMES Travel Subsystem Quality Issues.

3.3.8 System Modifications

For this section, think about the current infrastructure of your system which will be extended for future features, incorporated or made obsolete. Consider the following:
What parts of the system are likely candidates for later modification? What sorts of modifications are expected?
Example:JAMES Vehicle Subsystem System Modifications.

3.3.9 Physical Environment

For this section, consider the physical environment in which your susbsystem will exist. Consider the following:
Where will the target equipment operate? Will the target equipment be in one or several locations? Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibrations, magnetic fields, ...)?
Example:JAMES VIP Subsystem Physical Environment.

3.3.10 Security Issues

For this section, Focus on all possible security considerations. Consider the following:
Must access to any data or the system itself be controlled? Is physical security an issue?
Example:JAMES Bonus Subsystem Security Issues.

3.3.11 Resource Issues

For this section, think about data management for your subsystem. Consider the following:
How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance?
Example:JAMES Logbook Subsystem Resource Issues.

3.4 Constraints

For this section, consider all the limitations imposed on your subsystem. Consider the following:
Constraints on the programming language. Constraints on the development environment. Constraints on the use of libraries. Constraints on the use of legacy systems.
Example:JAMES Maintenance Subsystem Constraints.

3.5 System Model

You will have to use the UML (Unified Modelling Language) to create the models. If the CASE tool is installed in the lab (Together-J), use it produce the models. To make your models more readable, you have to include some texts to guide the reader along the flow of your model. These text are called Navigational Text because they help to move the reader along the models.

3.5.1 Scenarios

For this section, think about all the possible ways which the users will interact with your subsystem. Present them in a "story" format.
Example:JAMES Travel Subsystem Scenarios.

3.5.2 Use Case Models

Example:JAMES Vehicle SubsystemUse Case Model.
3.5.2.1 Actors
3.5.2.2 Use Cases

3.5.3 Object Models

Example:JAMES VIP Subsystem Object Model.
3.5.3.1 Data Dictionary
3.5.3.2 Class Diagrams

3.5.4 Dynamic Models

Example:JAMES Logbook Subsystem Dynamic Model.

3.5.5 User Interface - Navigational Paths and Screen Mockups

Example:JAMES Bonus Subsystem Navigational Path.
Example:JAMES Maintenance Subsystem Screen Mockup.