Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities [MAL2001].

While many of the functional requirements will be documented in Use Cases, there are some functional requirements that cannot be applied to specific use cases.  For example, reporting, auditing, printing, security, licensing support/enforcement, authentication requirements, etc.  Such functional requirements should be documented in the Supplementary Specification.  

If there are a significant number of system-wide functional requirements, it is important to give some thought into the organization of this section.  A typical organization is by feature/feature set, but alternative organization methods are also possible.  For example, organization by user or organization by subsystem, may also be appropriate.

Functional requirements represent the 'F' in "FURPS+.  For more information on "FURPS+", see Concept: Requirements.

Non-functional requirements include both qualities and constraints [MAL2001].  In this step we discuss qualities.  Constraints are addressed in a separate step.

[System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. [MAL2001]

Qualities represent the "URPS" in "FURPS+".  The concerns of each of these categories of requirements is as follows:

• Usability:  Aesthetics and consistency in the user interface.
• Reliability:  Availability (the amount of system "up time"), accuracy of system calculations, and the system's ability to recover from failure.
• Performance: Throughput, response time, recovery time, start-up time, and shutdown time.
• Supportability: Testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.

For more information on "FURPS+", as well as capturing non-functional requirements, see Concept: Requirements.

Depending on the number of qualities to be documented for the system, you may want to provide sub-sections for each of these quality types.

The following sections provide some examples of the kids of information you might want to capture for each of these qualities:

Usability

When describing usability requirements, you may want to specify:

• Required training time for a normal users and power users to become productive at particular operations
• Measurable task times for typical tasks
• Requirements to conform to common usability standards, for example, IBM's CUA standards or Microsoft's GUI standards

Reliability

When describing reliability requirements, you may want to specify:

• Availability – specify percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, and the like.
• Mean Time Between Failures (MTBF) – this is usually specified in hours but it could also be specified in terms of days, months or years.
• Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has failed?
• Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems output.
• Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs/function-point.
• Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a "critical" bug; for example, complete loss of data or complete inability to use certain parts of the functionality of the system.

Performance

When describing performance requirements, you may want to specify:

• Response time for a transaction(average, maximum)
• Throughput (for example, transactions per second)
• Capacity (for example, the number of customers or transactions the system can accommodate)
• Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)
• Resource use: memory, disk, communications, and so forth

When documenting performance requirements, be sure to include specific response times. Where applicable, reference related Use Cases by name.

Supportability

When describing supportability requirements, you may want to specify:

• Coding standards
• Naming conventions
• Class libraries
• Maintenance access
• Maintenance utilities

In this step you document any design constraints on the system being built. In general terms, a constraint is a restriction on the degree of freedom we have in providing a solution [LEF2000].  Design constraints represent design decisions that have been mandated and must be adhered to. 

A Constraints represent the '+' in "FURPS+" and can be further categorized, as follows:

• Design constraint: Specifies or constrains the options for architecting and/or designing a system. For example, requiring that a relational database be used for persistence.
• Implementation constraint: Specifies or constrains the coding or construction of a system. For example, required standards, processes, tools, implementation languages, hardware platforms, operating systems, third-party components, class libraries, and resource limits (use of memory or disk space).
• Interface constraint: Specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction.  For example, interfacing with an external system via message queues.
• Physical constraint: Specifies a physical constraint imposed on the hardware used to house the system — shape, size, or weight, for example.

Depending on the number of constraints to be documented for the system, you may want to provide sub-sections for each of the constraint types. Additionally:

• If the requirements include the purchase of third-party components, be sure to document any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards. A separate section per purchased component is recommended.
• If the requirements include specific interface requirements, it is recommended that you provide separate sections for the different types of interfaces (e.g., user, hardware, software). For each interface, be sure to include adequate specificity, protocols, ports and logical addresses, and so forth, so that the software can be developed and verified against the interface requirements. Specifically:
  • For user interfaces, describe the user interfaces that are to be implemented by the software.
  • For hardware interfaces, include logical structure, physical addresses, expected behavior, and so on.
  • For software interfaces include a description of the interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this system, but with which this software application must interact.

For more information on "FURPS+", as well as capturing constraints, see Concept: Requirements.

By compliance, we include standards compliance (including regulatory standards, coding standards or user interface style guides), as well as legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, and/or logo compliance.

Compliance requirements may be realized in terms of other requirements (functional, non-functional, and constraints).  In such cases, the details of those requirements should be documented in the applicable sections of the Supplementary Specification as described in the earlier steps.  However, it is important to summarize the standards and policies that a system must comply with.  The resulting compliance requirements may refer to the applicable detailed requirements, as necessary.

Depending on the number of compliance requirements to be documented for the system, you may want to provide sub-sections for the different kinds of compliance affecting the system.

The following sections provide some examples of the kids of information you might want to capture for different kinds of compliance:

Licensing Requirements

Define any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software.

Legal, Copyright, and Other Notices

Describe any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo compliance issues for the software.

Applicable Standards

Describe (by reference) any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.

In this step, you describe the requirements, if any, for documentation. Documentation requirements may include requirements for online help, as well as and end-user documentation (e.g., installation guides, user's guides, training material, etc.).  

Like compliance requirements, documentation requirements drive other types of requirements.  Specifically functional requirements (the system must provide support functional access to the online help), as well as usability requirements (on demand access to system usage information supports the overall usability of the system). 

Thus, like compliance requirements, detailed requirements supporting documentation requirements should be documented in the applicable sections of the Supplementary Specification as described in the earlier steps, but it is also important to document and summarize the overall documentation requirements for the system. The resulting requirements may refer to the applicable detailed requirements.

Depending on the number of documentation requirements to be documented for the system, you may want to provide sub-sections for the different kinds of documentation to be provided for the system.