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.
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 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.
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
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 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
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.
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 components and decisions such as the following:
Processor and Direct Access Storage Device type (DASD)
System Control Program
Data organization, placement and management
Process and data relationships
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,
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
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 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
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
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)
Which users and what systems use this data today
Availability considerations (such as periods when data is unavailable because of database maintenance or batch
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
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
· 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:
· 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
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
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
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
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 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
Security policy defining management responsibility and standards for user authentication, access control and data
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:
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.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.
The recommended approach to establishing availability requirements is as follows:
Identify the true users of the system, the business processes they are performing, and the hours when the users
perform those processes
Analyze the impact of service availability (or unavailability) on users' ability to accomplish their business
Specify availability requirements that directly reflect what the users require to accomplish their business
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
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
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
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
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,
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
How is the business/financial impact of a service interruption anticipated to change during the projected life of this
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.
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
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
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
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
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.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
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
4. Are there any general policies, such as Freedom of Information acts, that might influence the security design of
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:
Open terminal sessions in public place
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
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.
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
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.