1. Developing the Supplementary Specification

2. The Role of the Supplementary Specification
Some requirements can’t easily be expressed as use cases.
It supplements the use case model by describing those requirements.

3. Expressing Functional Requirements in the Supplementary Specification
Although most functional requirements can be expressed as use cases, some cannot easily be specified in this form.
Examples of systems whose requirements might not be easily expressible as use cases:
Systems that are primarily algorithmic and computational in nature – mathematical expressions, statistical algorithms, etc. may be used instead of use cases.

4. Expressing Functional Requirements in the Supplementary Spec. (Cont’d)
Behind the scenes applications like those for industrial automation and robotics – state machines, sequential logic expressions, etc. may be used to augment the use case model.
Applications that parse input strings, compile code, or translate from one language to another – finite state machines, or other mechanisms might be better than use cases for expressing these kinds of requirements.
In these cases the Supplementary Specification takes on a more primary role in the requirements process.

5. Nonfunctional Requirements
Usability
Reliability (availability, correctness)
Performance (efficiency)
Supportability (flexibility, maintainability, robustness, testability)
Safety
Security (integrity, privacy)
Others (adaptability, interoperability, portability, reusability)

6. Usability
Specify the required training time for a user to become minimally productive and operationally productive. This may be different for different classes of users (novice, normal, expert).
Specify measurable task times for typical tasks or transactions that the end user will be carrying out.
Compare the usability of the new system with other state-of-the-art systems that the user community knows and likes. E.g., the requirement might state, “The new system shall be judged by 90% of the user community to be at least as usable as the existing XYZ system.”

7. Usability (Cont’d)
Specify the existence and required features of online help systems, wizards, tool tips, context-sensitive help, user manuals, and of the forms of documentation.
Follow conventions and standards that have been developed for the human-to-machine interface. E.g., you can specify a requirement to conform to common usability standards, such as IBM’s Common User Access (CUA) standards.

8. The User’s Bill of Rights [Karat 1998]
The user is always right. If there is a problem with the use of the system, the system is the problem, not the user.
The user has the right to easily install and uninstall software and hardware systems without negative consequences.
The user has a right to a system that performs exactly as promised.
The user has a right to easy-to-use instructions (user guides, online or contextual help, and error messages) for understanding and utilizing a system to achieve desired goals and recover efficiently and gracefully from problem situations.

9. The User’s Bill of Rights [Karat 1998] (Cont’d)
The user has a right to be in control of the system and to be able to get the system to respond to a request for attention.
The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion.
The user has a right to be clearly informed about all system requirements for successfully using software or hardware.

10. The User’s Bill of Rights [Karat 1998] (Cont’d)
The user has a right to know the limits of the system’s capabilities.
The user has a right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns.
The user should be the master of software and hardware technology, and not vice versa. Products should be natural and intuitive to use.

11. Reliability
Availability – The system must be available for operational use during a specified period of time. E.g., “99% availability between 9 AM and 5 PM.” The requirement must also define what available means.
Mean time between failures – Usually specified in hours but could be days, months, or years. What constitutes a failure must be defined.
Mean time to repair – How long is the system allowed to be out of operation after it has failed? E.g., “90% of failures must be repaired within 5 minutes.” What is meant by repaired must also be defined.

12. Reliability (Cont’d)
Accuracy – What precision is required for numerical outputs? E.g., accurate to the nearest penny or to the nearest dollar?
Maximum bugs, or defect rate – This is usually expressed as bugs/KLOC and categorized according to bug severity (e.g., critical, severe, minor, trivial). These terms must be defined.

13. Performance Response time for a transaction: average, maximum.
Throughput: transactions per second.
Capacity: the number of customers or transactions the system can accommodate.
Degradation modes: the acceptable mode of operation when the system has been degraded.
If the system shares hardware resources with other systems, it may be necessary to stipulate how the application will use shared resources.

14. Supportability
Ability of the software to be easily modified to accommodate enhancements and repairs.
Requirements may stipulate the use of certain programming languages, database system environments, programming tools, table-driven support utilities, maintenance routines, programming styles and standards, etc. (these really become design constraints).

15. Design Constraints
Restrictions on the design of a system, or the process by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.

16. Sources of Design Constraints
Restriction of Design Options
Conditions Imposed on the Development Process
Regulations and Imposed Standards

17. Restriction of Design Options
Most requirements allow for more that one design possibility.
When requirements do not allow for a choice to be made (e.g., use Oracle DBMS) the design has been constrained.
This reduces design flexibility and development freedom has been lost.

18. Conditions Imposed on the Development Process
Compatibility with existing systems: “The application must run on both our new and old platforms.”
Application standards: “Use the class library from Developer’s Library on the corporate IT server.”
Corporate best practices and standards: “Compatibility with the legacy database must be maintained.”

19. Regulations and Imposed Standards
Constraints may be imposed by government regulations:
Food and Drug Administration (FDA)
Federal Communications Commission (FCC)
Department of Defense (DOD)
International Organization for Standardization (ISO)
Underwriters Laboratory (UL)
International standards such as the German Industrial Standard (DIN)
It is usually sufficient to include design constraints by reference but be specific.

20. Handling Design Constraints
Distinguish them from other requirements.
Include all design constraints in a special section of your requirements document.
Identify the source of each design constraint.
Document the rationale for each design constraint.

21. Are Design Constraints True Requirements?
Although it can be argued that design constraints are not true requirements, they are necessary to satisfy the obligations of development.
It is probably best to treat them in the same way as other requirements.
Strive to have as few design constraints as possible.

22. Identifying Other Requirements
Physical artifacts (CDs and so on) that are deliverables of the system.
Target system configuration and preparation requirements.
Support or training requirements.
Internationalization and localization requirements.

23. Linking the Supplementary Specification to the Use Cases
Some nonfunctional requirements may apply to the whole application and others may apply to only certain use cases.
When a such a requirement applies to a specific use case (e.g., performance) the specifics of the requirement should be stated as part of the use case, e.g., the response time requirement is “less than 2 seconds.”

24. Template for the Supplementary Specification
1. Introduction
1.1 Purpose
State the purpose of the document (to collect all functional requirements not expressed in the use-case model, as well as nonfunctional requirements and design constraints).
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
2. Functional Requirements
Describe the functional requirements of the system for those requirements that are expressed in the natural language style or are otherwise not included in the use-case model
3. Usability
State the requirements of the affect usability.
4. Reliability
State the requirements for reliability.
5. Performance
State the performance characteristics of the system, expressed quantitatively where possible and related to use cases where applicable.

25. Template for the Supplementary Specification (Cont’d)
6. Supportability
State the requirements that enhance system supportability or maintainability.
7. Design Constraints
State the design or development constraints imposed on the system or development process.
8. Documentation Requirements
State the requirements for user and/or administrator documentation.
9. Purchased Components
List the purchased components used with the system, licensing or usage restrictions, and compatibility/interoperability requirements.
10. Interfaces
Define the interfaces that must be supported by the application.
10.1 User Interfaces
10.2 Hardware Interfaces
10.3 Software Interfaces
10.4 Communications Interfaces

26. Template for the Supplementary Specification (Cont’d)
11. Licensing and Security Requirements
Describe the licensing and usage enforcement requirements or other restrictions for usage, security, and accessibility.
12. Legal, Copyright, and Other Notices
State any required legal disclaimers, warranties, copyright notices, patent notices, trademarks, or logo compliance issues.
13. Applicable Standards
Reference any applicable standards and the specific sections of any such standards that apply.
14. Internationalization and Localization
State any requirements for support and application of different user languages and dialects.
15. Physical Deliverables
Define any specific deliverable artifacts required by the user or customer.
16. Installation and Deployment
Describe any specific configuration or target system preparation required to support installation and deployment of the system.