Explanation

The Software Requirements Specification (SRS) focuses on the collection and organization of all requirements surrounding your project. If you have a Requirements Management Plan, you should consult it to determine the correct location and organization of the requirements. For example, it may be desired to have a separate SRS to describe the complete software requirements for each feature in a particular release of the product. This may include several use cases from the system Use-Case Model, to describe the functional requirements of this feature, along with the relevant set of detailed requirements in Supplementary Specifications.

Since you might find yourself with several different tools for collecting these requirements, it is important to realize that the collection of requirements may be found in several different artifacts and tools. For example, you might find it appropriate to collect textual requirements such as non-functional requirements, Design Constraints, etc, with a text documenting tool in Supplementary Specifications. On the other hand, you might find it useful to collect some (or all) of the functional requirements in the use cases and you might find it handy to use a tool appropriate to the needs of defining the Use-Case Model.

A Document or a Package?

We find that there is no strong reason to focus on the differences between the tools used. After all, you are collecting requirements and you really should focus on the efficient collection and organization of the requirements without regard to the tools at hand. Since we are focused on the requirements and not on the tools, we will assume that the collection of requirements in the SRS constitutes a package of information. The elaboration of the various requirements for the system is embodied in a package we call the Software Requirements Specification (SRS).

From Vision to SRS

The SRS Package is obviously related to the Vision document. Indeed, the Vision document serves as the input to the SRS. But the two artifacts serve different needs and are typically written by different authors. At this stage in the project, the focus of the project moves from the broad statement of user needs, goals and objectives, target markets and features of the system to the details of how these features are going to be implemented in the solution.

What we need now is a collection, or package, of artifacts that describes the complete external behavior of the system - i.e., a package that says specifically, "Here is what the system has to do to deliver those features." That is what we refer to as the SRS Package.

A Living Artifact

The SRS Package is not a frozen tome, produced to ensure ISO 9000 compliance and then buried in a corner and ignored as the project continues. Instead, it is an active, living artifact. Indeed it has a number of uses as the developers embark upon their implementation effort: It serves as a basis of communication between all parties - i.e., between the developers themselves, and between the developers and the external groups (users and other stakeholders) with whom they must communicate. Formally or informally, it represents a contractual agreement between the various parties - if it's not in the SRS Package, the developers shouldn't be working on it. And if it is in the SRS Package, then they are accountable to deliver that functionality.

The Project Members' Reference Standard

The SRS serves as the Project Manager's reference standard. The project manager is unlikely to have the time, energy, or skills to read the code being generated by the developers and compare that directly to the Vision document. He or she must use the SRS Package as the standard reference for discussions with the project team.

As noted earlier, it serves as input to the design and implementation groups. Depending on how the project is organized, the implementers may have been involved in the earlier problem-solving and feature-definition tasks that ultimately produced the Vision document. But it's the SRS Package they need to focus on for deciding what their code must do. It serves as input to the software testing and QA groups. These groups should also have been involved in some of the earlier discussions, and it's obviously helpful for them to have a good understanding of the "vision" laid out in the Vision documents. But their charter is to create test cases and QA procedures to ensure that the developed system does indeed fulfill the requirements laid out in the SRS Package. The SRS Package also serves as the standard reference for their planning and testing tasks.

Defining Functional Requirements

See Guideline: Use-Case Model and Guideline: Use Case for a full discussion of the recommended approach to defining functional requirements within a Use-Case Model and the Use Cases.

Defining Non-Functional Requirements

The non-functional requirements of your system should be documented in the Artifact: Supplementary Specifications.  Following are guidelines to follow when defining these requirements.

1 General

1.1 Assumptions and Issues

While gathering and validating non-functional requirements, maintain Assumptions and Issues lists. 

Some tasks will not give you satisfactory answers. This can be due to lack of information, or simply because you consider the answer threatens the viability of the design. Therefore, create two lists, and maintain them through the design study:

Any assumptions you make during the requirements and design process, including the rationale or thought processes behind those assumptions. Assumptions may be used to identify related subprojects or items of work which are outside the scope of or after this project.

Any major issues (significant concerns that could become show-stoppers)

The issues should be reviewed with the customer at the and of each phase. The assumptions need to be reviewed also, at the end of each phase, but the customer might not always be the correct person for the less important ones.

Assumptions and issues apply to all work products, but are particularly common for non-functional requirements.

1.2 Geographic Organization

Document the client's geographic organization.

Document the geographic locations of the part of the business affected by this system. The definition should include those unaffected sites also, which host major IT facilities. Make special note of any part of the organization that is mobile. For instance a sales force that will travel about and use workstations. Note any geographic locations at which you may have to provide special natural language support (NLS).

2 Givens

2.1 Pre-selected Application Packages?

Do the requirements specify the use of any application packages? One very important "given" that may dictate strongly some of the system design decisions is the use of a specific application package that provides predefined software logic and data organization. Some software packages are flexible and allow a great deal of customization; some are very rigid and do not. Packages may dictate components and decisions such as the following:

• Workstation type
• Connection methods
• Processor and Direct Access Storage Device type (DASD)
• System Control Program
• Data organization, placement and management
• Programming language
• Batch interfaces
• Process and data relationships
• Business logic
• Screen design and user interfaces
• Performance and availability characteristics
• Any existing or required architecture for printing, such as preferred print data formats (for example, PostScript, PCL, IPDT)
• National Language Support (NLS)

It is important to understand what influences any given package will have upon your design. If you have a "given" package, make sure you have the right skills and knowledge about this package available to you. This might come from:

• The package vendor
• External consultants
• Specially trained design team members

Do not assume that this knowledge is readily available. Ensure that it will be available to you when you need it.

2.2 Other Givens

Document any other givens in the requirements that will limit the flexibility of your design.

This is to catch any specific requirements not explicitly covered in earlier tasks that might limit the flexibility of your design. Look for any of the following:

• Use of existing processors or operating system images
• Use of existing workstation equipment
• Use of an existing network
• Use of existing system management practices
• Use of a specific model, such as: 'you must use a client/server system model for the design that clearly shows Presentation/Business/Data Access Logic and where and how they interface'.

Will any of these givens affect the new system? If the new system is to run on an existing processor, operating system image, or network configuration, are the characteristics of the existing platform and workload going to affect the new system?

How much connection and processing capacity is already taken by existing workloads?

What security controls are used by existing workloads? Note these, and check them against the security requirements of the new system when you consider the latter.

What are the availability characteristics of the existing workload?

Note anything which might affect your later design of availability for the new system. For example, does the existing workload insist on shutting down the whole of a processor each night?

2.3 Special Hardware?

Do the requirements specify the use of any special hardware?

This might be stated in generic terms ("the system must support a high-speed flat-bed plotter") or be more specific ("the existing Panda Corp ATMs will be supported"). Document, as far as you can:

• Any hardware or software prerequisites
• The vendors and their support organizations
• National Language (NLS) Considerations
• Cryptographic equipment

2.4 Existing Data?

Do the requirements specify the use of existing data? If so, then this will influence your system design. Document:

• On which system(s) the data currently exists
• Its structure (such as, relational or flat file)
• Its size
• Which users and what systems use this data today
• Availability considerations (such as periods when data is unavailable because of database maintenance or batch task)
• Can this data be moved or copied?

3 Standards

3.1 Technical Architecture / Strategic Plan

Does the client have a technical architecture and/or IT strategic plan (or equivalent set of standards)?

A technical architecture is roughly equivalent to the following:

• Enterprise technical platform
• Enterprise technical infrastructure
• Technology architecture

In a technical architecture you might find some of the following defined for you:

• The number and use of computing centers
• The networking connectivity of the enterprise (WAN)
• The localized connectivity of certain establishments (LAN)
• Client/server infrastructure services (middleware) covering

· Directory and naming services that keep track of network resources and attributes
· Security services that protect network resources from unauthorized used by registering users and their authorization levels
· Time services that regulate date and time across the network
· Transaction management services that coordinate resource recovery across various systems in a network

• The development methods that will be used for new applications 
• The accepted set of supported products such as:

· Hardware
· System control software
· Broad application software such as "Office"
· Help desk use
· Security rules

• Printing subsystem architecture

The list may be very extensive and the items in it may be policed on a very rigid basis or may not be enforced at all.

Document any requirements that specifically ask for, or exclude, the use of sub-architectures such as:

• OSI or SNA
• UNIX**
• SAA
• PS/2* with OS/2* EE.

Special architectures that may be implied by the use of a packaged application solution. Remember some application packages are architectural definitions in their own right.

Document the degree of openness (that is, vendor independence and interoperability) required by the client. If there is a technical architecture, then your design will almost certainly have to comply with it. You should read it and understand the rules that will influence design of this system.

3.2 Network Architecture

Does the client have a network architecture to which this system must conform? A network architecture is a common set of rules for high-level connectivity, plus a common transport infrastructure. This might include the definition of a backbone network, including concentrators and lines. If there is such an architecture, then understand the essential rules and topology and document:

Considerations for physical topology (that is, whether the network is essentially rural or metropolitan and whether the network attachment are densely populated versus loosely distributed).

What high-level connection functions are supported by the current network infrastructure.

What communications standards are used (for example SNA, OSI, TCP/IP) to support these connections functions.

What programming interfaces are supported.

Any network architecture definitions of the connectivity between client/server layers or the base system model layers like:

• Relational data access between client workstations and LAN relational servers must be via the protocols of a specific relational database product.
• The presentation logic must always be in the workstation and the data access logic must always be in a centralized host system.

3.3 Connection Policies

Does the client have any stated policies for connections?

Even if you don't have technical or network architectures, you may still have some connection policies.

Document any policies regarding:

• The use of particular protocols or communication facilities (for connections within a single building or external to the building or organization).
• Whether any particular protocols are implicitly required to support existing equipment or software.
• Whether existing physical connectivity facilities are to be used (that is, cabling or wiring, network or peripheral controllers, and common carrier facilities). If not, there may be constraints on the type of physical facilities that can be used (policies, government regulations, physical space, ownership of premises, involvement of third parties). Document these.
• If installation or modification of physical facilities is likely to be required, there may be a need to involve one or more third parties (such as contractors or common carriers). Understand how the contracting or responsibility would be managed. This is particularly important if the business interactions will involve international connections.
• Support of mobile users.

3.4 Other Policies?

Does the client have any other policies, standards or rules not explicitly stated in their requirements? For example:

• All new system interfaces for users must be designed to object oriented principles to allow drag and drop actions.
• All new systems must be based upon the client/server application model.
• All new systems must be defined with open standards
• Standards and policies for National Language Support (NLS) especially anything such as right-to-left text operation.
• Security policy defining management responsibility and standards for user authentication, access control and data protection.
• Application interchange standards (such as UNEDIFACT or VISA) which may imply the use of special equipment for connection or security.

If there are other policies, then make sure you understand them and have access to them so that you can ensure that your design conforms to the standards in the later phases of the design process. The use of a packaged application solution may well bring with it some implied standards.

What is the policy on allowing users or departments to add and/or develop their own local programs on:

• Workstations
• Servers (especially disk space usage)

Without controls, you may find that local usage quickly uses up resources which are needed by the production systems for which the local components were originally bought. You may find that you cannot install the production system by the time it is finally ready for rollout.

4 Numbers

4.1 "Units of measurement"

Work with the applications development personnel to break down the business processes into more granular units such as smaller business processes or transactions.

The reason for doing this is that you are going to capture numbers in the next question, and you have to decide what it is you are going to count.

Be aware that a business process may start several instances of smaller business transactions (for example multiple item orders per customer order) and these multipliers should be remembered when you document the numbers. However, do not get caught up with too much detail, particularly for a complex system.

A business "process" (for example, "customer order handling") will typically be implemented by an "application" (an IT term), or may span more than one application. Within each application, there will usually be many IT "transactions", for example, "query stock level" or "generate customer letter".

Different communities use their own names to identify the units we are trying to agree. For example, "transaction" might mean one thing to people with an applications development background, and a completely different thing to the infrastructure team. It is important to work together to correlate the names and then collect the information.

4.2 "Business volumes and sizings"

Identify and document volume and sizing information for each of the units in 4.1: "Units of measurement", for example:

• How many users are expected to be using each business process or application on average and at peak times
• When the peaks are (daily, weekly, monthly etc., as appropriate)
• At what rate transactions will need to be processed at peak and on average
• The number of data elements and instances in each data group and their sizes.

4.3 "Business process performance criteria"

The client may have performance criteria specified for some or all the business processes. However, remember also to document performance targets for system support processes (such as system backup) and applications development processes if identified. For each category, document:

• The response/turnaround requirements for each category
• Where these are to be measured
• Whether different criteria are acceptable at different times (for example off-peak/overnight)
• Whether the criteria are to be met during recovery or fallback
• If a performance guarantee is required
• What the impact will be on any party if the performance requirements are not met
• Express the minimum performance conditions required for the business process to be considered available (that is, the point below which the system is considered to be "unavailable" instead of "slow").
• If a packaged application solution has already been chosen ensure that you have access to its performance characteristics. You may not need them all now but you should be aware where to get them as they will probably be needed in future tasks. It may also take a long time for third parties to deliver the figures you require, so ask for them now.

5 Availability

5.1 Availability Advice

The recommended approach to establishing availability requirements is as follows:

1. Identify the true users of the system, the business processes they are performing, and the hours when the users perform those processes
2. Analyze the impact of service availability (or unavailability) on users' ability to accomplish their business objectives
3. Specify availability requirements that directly reflect what the users require to accomplish their business objectives.
4. Be aware that if a packaged application solution has already been chosen, its structure and design may have a significant influence upon the availability characteristics of the application as seen by the users. A package that has not been designed to operate continuously may be very difficult to operate continuously, especially as regards maintenance and batch windows.

Consider these guidelines as you form the availability requirements:

• Rather than specifying "global" requirements for the entire system, specify availability requirements at a low level of granularity (for example, by individual process, user group, data group, etc.). This gives the designer more flexibility to meet the users' needs. This is particularly important for systems with very high continuous availability requirements.

Some examples:

• The statement "The system must be up 24 hours per day to accommodate users in New York and Hong Kong" leaves the designer much less design flexibility than the statement "New York users must be able to perform transactions on THEIR data from 7AM to 7PM New York time and Hong Kong users must be able to perform transactions on THEIR data from 7AM to 7PM Hong Kong time". In the latter case, the designer has the flexibility to perform maintenance on one time zone's data or system components while the other time zone is still in the middle of their production day.
• In an ATM application, it may be critical to accept deposits and dispense cash at 3AM Monday morning, while the ability to provide exact account balances at that hour may be less critical.
• Distinguish between availability characteristics that are DESIRED and those that are MANDATORY. For example "The ATM MUST be able to accept deposits and dispense cash 24 hours per day. It is DESIRED that the ATM be able to provide the customer their exact account balance 24 hours a day; however occasional interruptions in the account balance enquiry process can be accommodated, but they MUST be less than 10 minutes in duration and occur between the hours of 3:00 and 4:00 AM".
• If the impact of not meeting a particular availability target cannot be directly related to the users' ability to accomplish their business objectives, that target may not be a good one to state as an availability requirement for the system.
• Availability requirements that only indirectly reflect the availability as perceived by the user (for example "The IMS control region must be up") tend not to be as useful as those that do (for example "Bank tellers must be able to perform processes X and Y").

5.2 "Scheduled service hours"

For each of the business processes and the groups of users who must perform them, identify the hours during which the user must be able to perform that process. Remember also to do this for those processes which are not directly associated with user group(s).

If there are user groups in different time zones (such as the earlier New York / Hong Kong example), treat them as separate groups of users.

Also show if there will be occasional periods, such as business holidays, when the application may not be needed. (This gives the designer the flexibility to use those periods for extended maintenance). What changes are anticipated in these service hours over the projected life of the application?

The service hours of this system may also be affected by those of other systems with which this one interfaces.

How are the scheduled service hours of this system expected to change over its projected life?

5.3 "Service outage costs"

Understand the BUSINESS IMPACT, FINANCIAL COSTS, AND RISKS associated with service interruptions during the scheduled service hours.

To identify what availability requirements are really important for this system, consider the set of business processes and groups of users and identify the business impact that would result from:

• A brief interruption or period of unacceptably slow response time during the scheduled hours. Define "brief" and "unacceptably slow" as they relate to this particular application (see "Business process performance criteria")
• Various longer-duration interruptions in service during the above hours (a minute, a few minutes, 15 minutes, 30 minutes, an hour, two hours, four hours, etc.)
• Extended interruptions in service (a shift, a day, multiple days, etc.).
• Also consider any processes which are not directly associated with a user group (for example, overnight check clearing).

When assessing the impact of each outage, identify fallback procedures and consider how they can reduce the true business impact of the outage.

Try to quantify this impact in financial terms (cost of lost staff or equipment productivity, value of lost current business, estimated loss of future business due to customer dissatisfaction, interest expenses, regulatory penalties, etc.).

Provide as many answers as necessary to reflect differences in the costs and risks associated with outages of different duration's, at different times of the day, whether planned or unplanned, which business processes or users are affected, etc.

How is the business/financial impact of a service interruption anticipated to change during the projected life of this system?

Review each of these agreed important business processes to identify alternatives to allow the most critical elements of those processes to proceed should some portions of the system become temporarily unavailable. The ability to operate temporarily with reduced business function may be a way to help reduce the availability impact of interdependencies among critical processes and data.

Some examples:

• FULL FUNCTION 1 Read and update stock record.
• REDUCED FUNCTION 1 Enter update of stock record and queue for future update.
• FULL FUNCTION 2 Read most-recent customer balance.
• REDUCED FUNCTION 2 Read customer balance from an alternate source, which may not be quite as current.
• FULL FUNCTION 3 Update computer diary.
• REDUCED FUNCTION 3 Update printed paper copy of diary.

Remember that when the system is working with reduced function there may be a limit to which this is acceptable to the business processes. For example, an out-of-date customer balance must not be more than 24 hours out-of-date.

If service is interrupted during the scheduled hours (see "Scheduled service hours") the impact of the interruption will usually vary depending on outage duration and other conditions. Some outages may have minimal impact on the users' ability to perform their business processes (brief outages, those which occur during lightly-used periods of the day, those which impact only a subset of the user group, or those for which an acceptable manual fallback procedure exists). Other outages, such as those which are longer or occur during a "critical" period of the day, may have a more significant impact. 

Some examples:

• A brief outage of manufacturing line control processes might have minimal impact on productivity, since work can continue based on previously-printed work orders and changes can be noted manually for later entry. However, an outage extending beyond sixty minutes may result in the shutdown of the line for the remainder of the shift.
• An outage of a high-dollar-volume financial settlement system during the last hour of trading might result in significant interest costs or regulatory penalties.
• Police and fire department responses to life-threatening emergencies can continue using manual fallback procedures if a dispatching system is unavailable. However the response times may increase, and potentially threaten lives, due to the increased dispatcher workload.
• A peak-period outage of an airline or hotel reservations system may not only result in a loss of current business when customers call a competitor to make their reservations, but may also result in a loss of future business if customers become dissatisfied enough to call another airline or hotel first the next time they need these services.

5.4 "Availability and recovery criteria"

Identify the AVAILABILITY AND RECOVERY CRITERIA that would apply under "normal" situations.

Exclude "disaster" situations, such as an extended loss or shutdown of the entire computing facility.

Based on the business/financial costs and risks identified in "Service outage costs", develop a specification of the availability criteria that must be met to avoid significantly inhibiting user groups from performing their assigned business processes. Such criteria might be specified in forms such as:

• Percentage of outages recovered within a given number of minutes/seconds
• Maximum amount of time over a given week/month/year when the user cannot perform a particular function

Be as specific as necessary to reflect factors such as differences between planned and unplanned outages, the hour during which the outage occurs (for example "critical" periods versus lightly used periods) whether all users or only a few are affected, etc.

Be careful not to specify unnecessarily stringent availability criteria, as this could significantly affect the implementation cost. In general, if significant business/financial costs or risks cannot be identified with a given set of outage conditions, this may be an indication that this set of outage conditions should not be included in the stated availability criteria.

If "Scheduled service hours" suggested that the scheduled service hours are likely to change, and/or "Service outage costs" suggested that the business/financial costs or risks associated with a service interruption are likely to change during the projected life of the system, estimate how the availability criteria would change as a result.

If cryptography is to be used, there will be additional recovery and availability considerations. For example:

• The ability to recover secret information that may be held outside of the system.
• The need to ensure that data which is protected cryptographically is recovered in co-ordination with the recovery of the appropriate encryption keys

5.5 "Disaster Recovery?"

Is disaster recovery required within the scope of this design project (availability during "disaster" situations, such as extended loss or shutdown of the entire computing facility)? If so, what are the criteria for such recovery?

Be aware that probably not all business processes will require disaster recovery facilities. Select only those processes that are critical and do require disaster recovery. Even within those processes, not all functions may need to be covered.

• How soon must service be restored? Is this measured from when the disaster occurs, or from when a decision is made to go to a remote site?
• Under what conditions would the organization decide to recover at a remote site, rather than locally?
• How current must the data be at the remote site for the business to continue operating (absolutely up-to-the-second; within a few minutes of the failure; previous day's data acceptable)?
• When service is first restored from the remote site?
• At some future point in time?
• What is the remote site recovery priority of this set of applications relative to other business applications dependent on the same computing facility?

Note that there may be different sets of criteria for different parts of the system or depending on the type of disaster.

What changes in the above disaster recovery requirements are anticipated during the projected life of the application?

5.6 "Other availability design considerations"

To design a system that recovers as quickly as possible, the designer needs to know what flexibility is available to them in implementing the application, while still meeting the functional requirements of the application. Here are some questions which may be of value to the designer:

1. To accommodate necessary maintenance tasks, may the system operate for brief periods during which it would:

a. Perform inquiry but not update?

b. Accept update requests from the user, but not actually update the DB until after the maintenance tasks have completed?

2. For an outage requiring recovery of data, is it more important to:

c. Restore service as quickly as possible, even if it means using data that is not completely up-to-date, or:

d. Recover all data to their current state before restoring service, even if this takes longer?

3. Should a user request be "in process" at the time of failure, can the user be relied on to re-enter the request following recovery of service?

4. Are there any non-technical considerations that might affect the availability of this system (such as a business policy which says that process A must not be made available to users unless process B is also available)?

Are any of the above design considerations expected to change over time?

For processes that are critical to the business, it is useful to identify alternatives which allow the most critical elements of those processes to appear functional even when portions of the system are temporarily unavailable. The ability to operate temporarily with reduced business function may be a way to help reduce the availability impact of interdependencies among critical processes and data.

6 Security

6.1 "Security requirements"

1. Identify data to be protected

2. Identify the type of threats to which each type of data is exposed:

• Accidental corruption or destruction
• Deliberate corruption or destruction
• Commercial intelligence
• Fraud
• Hacking
• Viruses

1. Identify threats to physical security:

• Theft of components
• Unauthorized physical access
• Physical safety of users

2. Identify the people who may be the sources of these threats:

• Data center staff
• Other IT staff (for example, development)
• Non-IT staff of the organization
• People outside the organization

3. Identify any special or unusual security requirements especially with respect to:

• Access to the system
• Encryption of data
• Auditability

4. Are there any general policies, such as Freedom of Information acts, that might influence the security design of this system?

5. Some packaged application solutions have their own security sub-systems. If you have a "given" package be aware of its security facilities.

In order to establish and classify the security requirements, you may want to use the following approach:

1. List the objects which require protection by logical or physical security.

2. Identify the exposure which is relevant to each object. Typical categories are:

• View access (breach of confidentiality), e.g. account information, client list, patents.
• Update access, i.e. modification of data for fraud, cover-up, diversion of funds.
• Loss of assets, i.e. somebody else gets a possession and it is no longer available to the owner (as distinguished from loss due to disaster). Examples are: client and prospect lists, contracts, etc.

Note that not all objects are sensitive to all of the above exposures.

3. Identify all the threats which are relevant to your environment. Examples are:

• Disgruntled employees
• Unauthorized employees
• Open terminal sessions in public place
• Hackers
• Line tapping
• Loss of equipment (e.g. portable PCs)

4. For each object establish which threat may apply and associate it with the particular exposure.

Note that you may have to review the security requirements for the object both in a static location (e.g. on a hard disk) as well as in transit (e.g. during transmission).

Since the design may extend the location of the object into unsecured areas, you may have to revisit this subject.

The security aspects of some system designs can be very demanding. They can dominate your design decisions. They could cause otherwise good options of structure and component selection to become unacceptable. So make a definite choice now as to whether the system that you are designing has particularly demanding security requirements. For example:

• A sensitive military system
• A high value money transfer system
• A system that handles confidential personal information

If you believe that you have special security demands then you should identify a Security Expert or Practitioner to assist you in the design aspects of your system.

7 Usability

Usability requirements define how high the usability of the user interface must be.

The usability requirements should be set to the lowest level of usability that the system must achieve in order to be used. They should not be set to what you believe the system can achieve. In other words, the usability requirements should not be considered a target, i.e., an upper limit. Usability requirements should define the absolute lowest acceptable system usability. Thus, you should not necessarily stop improving usability when usability requirements are fulfilled

What the system must achieve, in order to be used, depends mostly on what the alternative to using the system is. It is reasonable to require that the system should be significantly more usable than the alternatives. The alternatives can be to utilize:

• Existing manual procedures.
• Legacy system(s).
• Competing products.
• Earlier version(s) of the system.

Usability requirements can also come from the need to economically justify the new system: if the customer has to pay $3 million for the new system, he might want to impose usability requirements that imply that he will save perhaps $1 million per year because of decreased workload on his human resources.

The following are examples of some general usability requirements:

• Maximum execution time - how long it should take a trained user to execute a common scenario.
• Maximum error rate - how many errors a trained user will average for a common scenario.
  The only errors that are relevant to measure are those that are unrecoverable and will have negative effects on the organization, such as losing business, or causing damage to monitored hardware. If the only consequence of an error is that it takes time to fix, this will affect the measured execution time.
• Learning time - how long it takes before the user can execute a scenario faster than the specified maximum execution time.

The following is an example of some specific usability requirements for a "Manage Incoming Mail Messages" Use Case.

• The Mail User should be able to arrange Mail Messages with a single mouse click.
• The Mail User should be able to scroll Mail Message texts by pressing single keyboard buttons.
• The Mail User should not be disturbed by incoming Mail Messages when reading existing Mail Messages.