3. Non-Functional Requirements

Here are dumps of fodder from the old biggie burger and rolodex.

Rolodex Fodder

The non-functional requirements for the Rolodex Tool are organized into three major categories:

In general, the non-functional requirements for the Rolodex Tool are limited, given the simplicity of tool's functionality and the fact that it is public domain non-commercial software.

3.1. System

System-related non-functional requirements cover performance, operational environment, and general system characteristics.

3.1.1. Performance

Given the limited functionality of the Rolodex Tool and its limited user community, performance is not a significant issue. In general, the speed of all operations must be comparable to similar tools, such as those cited in Section 1.5 on related systems. "Comparable to" means that the Rolodex Tool operations must execute at a speed that is in the same order of magnitude as similar tools under similar computer load conditions.

There are no specific requirements for the allowable size of a rolodex in terms of the number of cards. A Rolodex on the order of thousands of cards is the likely maximum size during normal use. However, there is no specific reason that the size of the Rolodex be limited.

3.1.2. Operational Environment

There are no specific requirements for the hardware or software platform on which the Rolodex Tool must operate. As discussed in Section 2.13 , specific elements of the graphical user interface may differ per the conventions of a specific operating environment.

There are no specific requirements for interoperability with external software, such as other database programs.

3.1.3. General Characteristics

The functionality of the Rolodex tool is sufficiently straightforward that the tool must be 100% reliable, accurate, and correct. "Reliable" means that the system must not fail due to a software fault that is traceable to one of its functional software components. "Accurate" means that the system must not loose or corrupt data due to a software fault that is traceable to one of its functional software components. "Correct" means that in the absence of external hardware or external software failures, the system performs all operations as defined in the Rolodex Tool formal specification.

The system must be robust in the face of hardware power failures in terms of data loss. "Robust" means that when computer power fails or is interrupted, the Rolodex Tool performs a Save operation on the currently open rolodex file, if the workspace is modified.

There are no specific requirements for security, privacy, safety, portability, modifiability, or extensibility.

3.2. Process

The system is to be developed using the software process employed by Gene Fisher in his software engineering classes at Cal Poly university. The process is currently described in lecture notes for the graduate course in software engineering.

3.3. Personnel

The development is to be conducted by a single individual (Gene Fisher) who is assumed to have the necessary knowledge and skills to complete the project. There are no specific requirements for the end users of the Rolodex Tool. Given its simple functionality, it is intended to be usable by end users with only basic computer literacy skills.

Biggie Burger Fodder
Named "Goals, Constraints, and Non-Functional Requirements" there

This section contains the information indicated in the section heading. Examples for the Biggie Burger system follow.

Given below are quantitative and qualitative constraints that must be met by the Biggie Burger system. Also given are constraints on the procurement and development of the system. The following terminology is used:

3.4. System Performance Constraints

3.5. Qualitative system characteristics

3.6. Development Goals and Constraints

The owners seek to have the system fully operational within six months from the date of issuance of a contract to the developers. All on-site development work must be done after normal restaurant operation hours.

The concrete user interface defined in the final section of this document is subject to change by developers if they deem it necessary. Any such interface changes must be fully negotiated with the owners and analysts.

The developers shall install the system in the following stages, to allow a graceful phase-in of the new system:

  1. The owners shall evaluate the entire system prior to any installation in the restaurant.
  2. Five restaurant tables will be equipped with the new food ordering system in the first stage of operation.
  3. After evaluation of the first stage, including any necessary system upgrades, the remaining tables shall be equipped.
  4. The inventory management subsystem will be installed after the initial five- table test phase.
  5. After complete evaluation, the system shall be deemed fully operational.
  6. During all stages preceding full operation, the extant food ordering and inventory control system shall remain in place, and can be brought into service immediately in case of failure in the new system.





Prev: functional | Next: developer-overview | Up: index | Top: index