Supporting Requirements
There is a finite set of requirements to be considered when it comes to gathering system-wide requirements, qualities
or constraints. Many of them are unfamiliar to stakeholders, so they may find it difficult to answer questions related
with topics such as availability, or performance, or scalability, or localizability. Use this guideline, and the
associated checklist, when speaking to stakeholders to ensure that all topics are discussed. Make sure that
stakeholders understand the costs of their selections, and do not end up wanting everything that is on the list.
Functionality
-
Auditing: Is there a need to track who used the system and when they used it? State requirements
for providing audit trails of system execution.
-
Authentication: Will access to the system be controlled? State requirements for authentication.
-
Licensing: Will the system, or parts of the system, be licensed? If open-source software
been used in the system, have all open-source agreements been respected? State requirements for acquiring,
installing, tracking, and monitoring license useage.
-
Printing: Will printing capability be required? State requirements for printing.
-
Reporting: Is reporting capability required? State requirements for reporting.
-
Scheduling: Will certain system actions need to be scheduled? State requirements on
scheduling capability.
-
Security: Will elements of the system, or system data, need to be secure? State requirements
to protect access to certain resources or information.
Usability
Usability requirements are critical to the success of any system. Unfortunately, useability requirements are
often the most poorly specified requirements. Consider the common requirement: "The system shall be easy to
use." This really doesn't help much since it cannot be verified.
While capturing useability requirements it is a good idea to identify issues and concerns first, and later refine these
into verifiable requirements (see Guideline: Writing Good Requirements). According to a traditional definition
[Need Reference from Ana], usability consists of five factors:
-
Ease of Learning: A user with a specified level of experience must be able to learn how to use the
system in a specified amount of time.
-
Task Efficiency: A user should be able to complete a specified task in a specified time (or number
of mouse click).
-
Ease of remembering: A user should be able to remember how to accomplish specified tasks after a
specified period of non-use of the system.
-
Understandability: A user must be able to understand system prompts and messages and what the
system does.
-
Subjective Satisfaction: A specified percentage of the user community must express satisfaction
with using the system.
The following method may be used to identify and specify usability requirements:
-
Identify the key usability issues by looking at critical tasks, user profiles, system goals, previous usability
problems.
-
Chose the appropriate style to express the requirements. These include:
-
-
Performance Style: Specify how fast users can learn various tasks and how fast they can
perform the task after training.
-
Defect Style: Instead of measuring task times, this style identifies usability defects and
specifies how frequently they may occur.
-
Guideline Style: Specify the general appearance and response time of the user interface by
reference to accepted and well defined standards.
-
Write the actual requirements, including perfomance criteria (see Guideline: Writing Good Requirements for more information).
Reliability
Reliability includes the system's ability to keep running under stress and adverse conditions. In the case of an
application, reliability relates to amount of time available and running versus time unavailable. Specify reliability
acceptance levels, and how they will be measured and evaluated. Describe reliability criteria in measurable terms. This
is usually expressed as the allowable time between failures, or the total allowable failure rate. Other important
reliability considerations include:
-
Accuracy: Specify requirements on the precision (resolution) and the accuracy (by some known
standard) that is required in any calculation performed or system output.
-
Availability: Specify requirements on the percentage of time the system is available for use,
hours of use, maintenance access, and degraded mode operations. Availability is typically specified in
terms of the Mean Time Between Failures (MTBF).
-
Recoverability: Specify requirements on recovery from failure. This is typically specified
in terms of the Mean Time To Repair (MTTR).
-
Frequency/Severity of Failures: Specify the maximum defect rate (typically expressed as
defects/KSLOC or defects/function-point) and severity of failures. Severity may be categorized in terms
of minor, significant, and critical defects. The requirements must define each of these terms
un-ambiguously. For example, a "critical" defect could be defined as one that results in loss of data of
complete inability to use certain functionality of the system.
Performance
-
Response times: Specify the amount of time available for the system to complete specified tasks/
transactions (average, maximum). Use unit of measurement, Examples: “Any interface between a user and the system
shall have a maximum response time of 2 seconds”, “The product shall download the new status parameters within 5
minutes of a change”
-
Throughput: Specify the capacity of the system to support a given flow of information (for
example, transactions per second).
-
Capacity: Specify on the volumes that the product must be able to deal with and the numbers of
data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
(memory, disk, ...) or degradation modes (what is the acceptable mode of operation when the system has been
degraded in some manner) Examples: “The product shall cater for 300 simultaneous users within the period from
9:00am to 11:am. Maximum loading at other periods will be 150.”
-
Start-up: The time for the system to start up.
-
Shut-down: The time for the system to shut down.
Supportability
-
Adaptability: Are there any special requirements regarding adaptation of the software (including
upgrading)? List requirements on the ease with which the system is adapted to new environments.
-
Compatibility: Are there any requirements regarding this system and its compatibility with
previous versions of this system or legacy systems providing the same capability?
-
Configurability: Will the product be configured after it has been deployed? In what way will the
system be configured?
-
Installation: Statement of special requirements regarding system installation
-
Level of Support: What is the level of support that the product requires? This is often done using
a help desk. If there are to be people who provide support for the product, is that considered part of the product
and are there any requirements for that support? You might also build support into the product itself, in which
case this is the place to write those requirements. Consider the anticipated level of support, and what forms it
might take.
-
Maintainability: Are there any special requirements regarding system maintenance? What are the
requirements for the intended release cycle for the product and the form that the release will take?. Quantify the
time necessary to make specified changes to the product. There may also be special requirements for
maintainability, such as this product must be able to be maintained by its end-users, or developers who are not the
original developers. This has an effect on the way that the product is developed, and there may be additional
requirements for documentation or training. Describe the type of maintenance and the amount of effort required.
Examples: “A new weather station must be able to be added to the system overnight”, “The maintenance releases will
be offered to end-users once a year.“
-
Scalability: What volumes of users and data will the system support? This specifies the expected
increases in size that the product must be able to handle. As business grow (or are expected to grow) the software
products must increase their capacities to cope with the new volumes. This may be expressed as a profile over
time.]
-
Testability: Are there any special requirements regarding the testability of the system?
+ Constraints
-
Design Constraints: Are there any design decisions that have been mandated and must be adhered to?
-
Third-party components: Specify any mandated legacy, COTS, or open-source components to be used
with the system.
-
Implementation languages: Specify requirements on the implementation languages to be used
-
Platform support: Specify requirements on the platforms that the system will support
-
Resource limits: Specify requirements on the use of resources such as memory and hard disk space
-
Physical Constraints: Specify requirements on the shape, size of weight of the resulting hardware
housing the system
+ Interface Requirements
User Interface
Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
section is to state the requirements and not the user interface itself. Interface design may overlap the requirements
gathering process. This particularly true if you are using prototyping as part of your requirements process. As
prototypes develop it is important to capture the requirements that relate to the look and feel. In other words, be
sure that you understand your client’s intentions for the product’s look and feel. Record these as requirements instead
of merely having a prototype for approval.
-
Look & Feel: A description of the spirit of the interface. Your client may have given you
particular demands such as style, colors to be used, degree of interaction, and so on. This section captures the
requirements for the interface rather than the design for the interface. The motivation is to capture the
expectations, the constraints and the client’s demands for the interface before designing it. Examples: “The
product shall have the same layout as the district maps from the engineering department.” “The product shall use
the company color.”
-
Layout and Navigation Requirements: Specify requirements on major screen areas and how they should
be grouped together.
-
Consistency: Consistency in the user interface enables users to predict what will happen. This
section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
and shapes, placements for entering / presenting data, terminology
-
User Personalization & Customization Requirements: Requirements on content that should
automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
content displayed or to personalize displayed content.
Interfaces to external systems or devices
-
Software Interfaces: Are there any external systems with which this system must interface? Are
there any constraints on the nature of the interface between this system and any external system, such as the
format of data passed between these systems, and any particular protocol used? Describe software interfaces to
other components. These may be purchased components, components reused from another application or components being
developed for subsystems outside of the scope of the system under consideration, but with which this it must
interact. For each system consider both provided and required interfaces.
-
Hardware Interfaces: Define any hardware interfaces that are to be supported by the software,
including logical structure, physical addresses, expected behavior, and so on.
-
Communications Interfaces: Describe any communications interfaces to other systems or devices such
as local area networks, remote serial devices, and so on.
+ Business Rules
Besides technical requirements, consider as well the particular business domain where the system should fit.
Business rules or policies that the system must conform to may constrain system functionality. Business rules are
referred to by system use cases, and can be in the form of decision tables, computation rules, decision trees,
algorithms, and so on. Describing the rules in the flows of the use cases usually clutters the use-case specifications.
Hence, they are normally captured in separate artifacts or as annexes to the use-case specifications. In many cases a
business rules applies to more then one use case so these shared business rules should be stored in a single
repository, such as a supporting requirements document.
|