Cover the fact that user calendar files in the central host repository must be
encrypted so there contents are not visible by any other means than through the
calendar tool, this to prevent users on the central host computer, including
administrative users, cannot see private calendar items.
3.2. Performance
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.
System-related non-functional requirements cover performance, operational
environment, and general system characteristics.
3.3.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.3.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.3.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.4. 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.5. 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 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: