CS 1212 SOFTWARE ENGINEERING

Lecture 4 – Software Requirements

Yahya Hamad Sheikh, PhD

[email protected]

The State University of Zanzibar,

Department of Computer Science and Information Technology
www.suza.ac.tz
 INTRODUCTION

• Software engineering deals with the art of building the

right system right

Requirements Software Design and

Engineering Implementation

Building the right Building the system

system right
 DEFINING REQUIREMENTS

• Software requirements are descriptions of what the system should

do, the services that it provides and the constraints on its operation.
• It is important to clearly document software requirements as are
used to:
• Understand precisely what is required of the software
• Communicate this understanding precisely to all development parties
• Control production to ensure that the system meets specifications
(including changes)
 ROLES OF REQUIREMENTS TO DIFFERENT
STAKEHOLDERS

• Customers: show what should be delivered. It is the basis

of the contract.
• Managers: used as a scheduling / progress indicator
• Designers: provide specification to design
• Programmers: list a range of acceptable implementations /
output
• Quality Assurance / testers: provide a basis for testing,
validation, and verification
 CATEGORIES OF REQUIREMENTS

• There are three major categories of requirements:

• Functional requirements
• Non-functional requirements
• Domain requirements
 FUNCTIONAL REQUIREMENTS

• These are statements of services the system should provide,

how the system should react to particular inputs and how the
system should behave in particular situations.
• In general, they describe the functionality or system services.
• Example of functional requirements are:
• The system must be able to capture tax table information.
• The system must provide the ability to track which user
made the tax adjustment and why the adjustment was made.
 PRECISION IN DEFINING FUNCTIONAL REQUIREMENTS

• Functional requirements must always be precisely stated.

• Ambiguous requirements may be interpreted in different ways by developers and
users
• Consider the following requirement: “The system shall provide appropriate
viewers for the user to read documents in the document store”.
• The term ‘appropriate viewers’ may be interpreted differently by different groups.
• User intention may be to have a “special purpose viewer for each document type;
pdf, and word, each opened by relevant application.
• A developer may interpret this as a “to provide a text viewer that shows the
contents of the document”.
 COMPLETENESS AND CONSISTENCY IN DEFINING
FUNCTIONAL REQUIREMENTS

• In principle, functional requirements should be both

complete and consistent.
• Complete means they should include descriptions of all
facilities required.
• Consistent means there should be no conflicts or
contradictions in the descriptions of the system facilities.
• In practice, however, it is very difficult or impossible to
produce a complete and consistent requirements document.
 NON-FUNCTIONAL REQUIREMENTS

• These are the quality constraints that the system must satisfy according to the project
contract.
• Examples of non-functional requirements are:
• Users must change the initially assigned login password immediately after the first
successful login. Moreover, the initial should never be reused.
• The system shall not disclose any personal information about customers apart from their
name and reference number to the operators of the system.
• The process of specifying non-functional requirements requires the knowledge of
the functionality of the system, as well as the knowledge of the context within which
the system will operate.
• Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless.
 CLASSIFICATION OF NON-FUNCTIONAL
REQUIREMENTS

• The most common types of non-functional requirements are

performance, scalability, portability, compatibility, reliability,
availability, maintainability, security, localization, and usability,
though there are quite a few more types to check.
• Performance and Scalability
• Performance: How fast does the system return results?
• Scalability: How much will this performance change with higher
workloads?
 CLASSIFICATION OF NON-FUNCTIONAL
REQUIREMENTS

• Portability and Compatibility

• Portability: Which hardware, operating systems, and
browsers, along with their versions does the software run
on?
• Compatibility. Does it conflict with other applications and
processes within these environments?
 CLASSIFICATION OF NON-FUNCTIONAL
REQUIREMENTS

• Reliability, maintainability, availability.

• Reliability: How often does the system experience critical
failures?
• Maintainability: How much time does it take to fix the
issue when it arises?
• Availability: And how is user availability time compared
to downtime?
 CLASSIFICATION OF NON-FUNCTIONAL
REQUIREMENTS

• Security. How well are the system and its data protected
against attacks?
• Localization. Is the system compatible with local
specifics?
• Usability. How easy is it for a customer to use the
system?
 VERIFIABILITY IN NON-FUNCTIONAL REQUIREMENTS

• Non-functional requirements must always be written so that they can be objectively

verified.
• Consider this requirement: “The system should be easy to use by experienced
controllers and should be organised in such a way that user errors are minimised”.
• Terms like “easy to use” and “errors shall be minimised” are useless because they
cannot be verified.
• Consider this requirement: “Experienced controllers should be able to use all the
system functions after a total of two hours training. After this training, the average
number of errors made by experienced users should not exceed two per day”.
• This is a good example of non-functional requirement as it can be objectively
verified.
 GOALS VS NON-FUNCTIONAL REQUIREMENTS

• Non-functional requirements may be very difficult to state precisely, and imprecise

requirements may be difficult to verify, as they are often stated as goals rather than
requirements.
• A goal is a general intention of the user such as ease of use, while non-functional
requirement is a statement using some measure that can be objectively tested.
• Goals are only helpful to developers as they convey the intentions of the system users,
but cannot be considered as non-functional requirements.
• Example of system goal: “The system should be easy to use by experienced controllers
and should be organised in such a way that user errors are minimised”.
• Example of a verifiable non-functional requirement: “Experienced controllers shall be
able to use all the system functions after a total of two hours training. After this training,
the average number of errors made by experienced users shall not exceed two per day”.
 PRECISE MEASURES IN NON-FUNCTIONAL
REQUIREMENTS

Property Measure
Speed • Processed transactions/second
• User-event response time
Screen refresh time
Size • K Bytes
• Number of RAM chips
Easy of Use • Training time
• Rate of errors made by trained users
• Number of help frames
 CONFLICTS IN NON-FUNCTIONAL REQUIREMENTS

• Conflicts between different non-functional requirements are

common in complex systems.
• For example, in Spacecraft system. To minimise weight, the
number of separate chips in the system should be minimised.
To minimise power consumption, low power chips should be
used. However, using low power chips may mean that more
chips must be used.
• Decisions are usually made on which is the most critical
requirement?
 DOMAIN REQUIREMENTS

• These are requirements that come from the application domain of the system and that
reflect characteristics of that domain.
• May be new functional requirements, constraints on existing requirements or define
specific computations.
• If domain requirements are not satisfied, the system may be unworkable.
• When defining domain requirements, there is always some issues with
understandability and implicitness.
• Understandability: Requirements are expressed in the language of the application
domain, and often not understood by software engineers developing the system.
• Implicitness: Domain specialists understand the area so well that they do not think of
making the domain requirements explicit.
 WRITING GOOD REQUIREMENTS

• To write a good requirement –be it functional, non-functional, or

domain, you must write it as a complete sentence, with a subject
and a predicate.
• A subject is an actor, a stakeholder, the system under
development, or a design entity that is related to the requirement.
• A predicate specifies an action or intended result that is done for,
by, with, or to the subject, often including conditions and
performance criteria.
 WRITING GOOD REQUIREMENTS

• You can analyze a requirement from a grammatical point of

view.
• For example: The order entry clerk shall be able to complete 10
customer orders in less than two hours.
• This requirement has:
• a subject (the order entry clerk, who is an Actor)
• a specific and measurable end state (10 customer orders completed),
• and a performance criterion (in less than two hours).
 GUIDELINE FOR WRITING GOOD REQUIREMENTS

• (1) Define one requirement at a time. Examples:

• The pilot shall be able to control the aircraft's angle of climb with one hand.
• The pilot shall be able to feel the angle of climb from the climb control.
• (2) Avoid conjunctions (and, or) that make multiple requirements. For example:
• The navigator shall be able to view the aircraft's position relative to the route's radio beacons.
• The navigator shall be able to view the aircraft's position as estimated by inertial guidance.
• Instead of:
• The navigator shall be able to view the aircrafts position relative to the route's radio beacons or as estimated by
the inertial guidance.
• The latter form is potentially dangerous because it is not clear whether the "or" indicates
that the navigator can chose which method to use for navigation or that the developers can
decide which to implement.
 GUIDELINE FOR WRITING GOOD REQUIREMENTS

• (3) Avoid clauses or words that imply options or exceptions (unless, except, if necessary, but). For
example, use:
• The system shall provide 100% of rating in normal conditions.
• The system shall be capable of providing up to 125% of rating for the first 15 minutes in an emergency condition.
• The system shall provide a minimum of 90% of rating for not less than 15 minutes following first 15 minutes in an emergency
condition.
• The system shall activate a reduced rating exception if a minimum of 95% of rating is not maintained in an emergency
condition.

• Instead of:
• The system shall perform at the maximum rating at all times except that in emergencies it shall be capable of providing up to
125% of rating unless the emergency condition continues for more than 15 minutes in which case the rating shall be reduced
to 105% but in the event that only 95% can be achieved then the system shall activate a reduced rating exception and shall
maintain the rating within 10% of the stated values for a minimum of 30 minutes.
 GUIDELINE FOR WRITING GOOD REQUIREMENTS

• (4) Use simple, direct sentences. Example:

• The pilot shall be able to see the airspeed indicator.
• (5) Use simple, ordinary words as much as possible, especially if your
audience is international, which makes accurate translation a concern.
Example:
• The airline shall be able to convert the aircraft from business to holiday
charter use in less than 12 hours.
• Note: There is no need to use computer jargons such as reconfigured.
 GUIDELINE FOR WRITING GOOD REQUIREMENTS

• (6) Identify the type of user who needs each requirement.

Example:
• The navigator shall be able to ...
• (7) Focus on stating what result you will provide for that type of
user. Example:
• ...view storm clouds by radar...
• (8) Define verifiable criteria
• ...at least 100 miles ahead.
 GUIDELINE FOR WRITING GOOD REQUIREMENTS

• (9) Use To Be Confirmed (TBC) to flag a requirement is likely to

change or is not yet definite. This helps identify outstanding
work. For example:
• The aircraft shall be able to land safely on airstrips with a minimum length
of 1000 meters (TBC).
• (10) Use To Be Determined (TBD) where it is known that a
specific requirement will be needed, but the details are not yet
known (known-unknowns). This also helps identify outstanding
work. For example,
• The aircraft shall be able to land safely on airstrips with a minimum length
of TBD meters.
END OF LECTURE
