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:

• system-related,
• process-related, and
• personnel-related

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:

• Owners: the owners of the Biggie Burger restaurant for whom the system is being specified
  
• Customers: the food-ordering restaurant customers who will use the food ordering subsystem.
  
• Managers: the restaurant management staff, including the owners, who will use the inventory control subsystem.
  
• Developers: the team or individual who will procure and/or develop the system to meet the specifications set forth in this document.
  
• Analysts: the authors of this specification document.

• The system shall respond to any single customer ordering operation within five seconds. "Respond" means that the appropriate operation output will be displayed to the user within the five second limit.
• When the AllDone selection is made and confirmed by the customer, the receipt shall be produced within ten seconds and the customer order shall be transmitted to the cook within five seconds.
• The overall performance of the inventory control system shall be no worse than the average performance of comparable systems currently available in the market place. Average performance data are based on the article "Comparing Restaurant Inventory Control Systems" appearing in the November 1990 issue of Restaurant Owners Digest.

• The overriding characteristic of the customer ordering interface is simplicity of operation. If any interface changes are made (see below), this goal of simplicity must be met.
• Simplicity is also a desired characteristic for the inventory control subsystem.

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.