Guidelines: Software Requirements
Specification
Topics
The Software Requirements Specification
(SRS) focuses on the collection and organization of all requirements
surrounding your project. Refer
to the Requirements Management Plan 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.
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).
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.
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 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 activities 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 activities.
See Guidelines: Use-Case Model and Guidelines:
Use Case for a full discussion of the recommended approach to defining
functional requirements within a Use-Case
Model and the Use Cases.
The non-functional requirements of your system should be documented in the Artifact:
Supplementary Specifications. Following are guidelines to follow when
defining these requirements.
While gathering and validating non-functional requirements, maintain
Assumptions and Issues lists.
Some activities 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 artifacts, but are particularly common
for non-functional requirements.
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).
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 such components and decisions as:
- 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 end 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.
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
activities that might limit the flexibility of your design. For example, look
for:
- 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?
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
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 activity)
- Can this data be moved or copied?
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.
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.
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.
Does the client have any other policies, standards or rules not explicitly
stated in their requirements? For example:
- All new system interfaces for end 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.
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.
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.
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 activities. It may also take a long time for third parties
to deliver the figures you require, so ask for them now.
The recommended approach to establishing availability requirements is as
follows:
- Identify the true end users of the system, the business processes they are
performing, and the hours when the end users perform those processes
- Analyze the impact of service availability (or unavailability) on the end
users' ability to accomplish their business objectives
- Specify availability requirements that directly reflect what the end users
require to accomplish their business objectives.
- 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 end 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 end 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 end 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").
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?
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.
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
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?
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 activities, 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 activities 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.
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.
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.
|