Fundamentals of Software Engineering

Instructor: Meti Dejene

tiimeekoo@gmail.com
Haramaya University
Chapter 4 - Requirements Engineering
 Software Requirements
The first phase in SDLC is requirement analysis and specification.

 What is requirement in software engineering?

Requirement is

 the description of what is expected from a system to be developed, in terms of (1) the
services that a system is expected to provide,(2) a property that a system must exhibit
and (3) the constraints on its operation in order to solve some problem of the real
world.
 Cont.
IEEE defines a requirement as

 “(1) A condition of capability needed by a user to solve a problem or achieve an

objective; (2) A condition or a capability that must be met or possessed by a system ...
to satisfy a contract, standard, specification, or other formally imposed document”.

These requirements reflect the needs of customers for a system that serves a certain
purpose and helps to solve their problem.
 Requirements Engineering
The overall process of finding out, analyzing, documenting and checking these
requirements services and constraints is called requirements engineering (RE).

Requirements engineering process encompasses five main activities. These are

 Requirements gathering

 Requirements analysis

 Requirements specification

 Requirements validation and

 Requirements management
 1. Requirements gathering
Also known as requirements elicitation or requirements discovery.

Requirements gathering is

 the activity of collecting requirements about a system to be developed from different

sources.

In this activity, requirement engineers work with customers and system end-users to find
out about the application domain, what services the system should provide, the required
performance of the system, hardware constraints, and so on.

It is concerned with where requirements come from and how they can be collected by the
requirements engineer.
 Cont.

Requirements are collected from stakeholders.

 A stakeholder is usually a person, or a group of people who is either directly or

indirectly concerned with the software (use, influenced or benefited).

The complete set of requirements are almost never available in the form of a single
document or from any single customer representative.
 Cont.
Therefore,
 requirements have to be systematically gathered from several sources in bits and pieces and

 the requirements engineer must strive for completeness by ensuring that all relevant
sources of requirements are identified and consulted.

However, it will usually be infeasible to consult everyone e.g. there may be many users of a
large system.

In such cases, representative examples of each class of system stakeholder should be

identified and consulted.
 Requirements Elicitation Techniques

Requirement engineers can employ several techniques to elicit the requirements from the
stakeholders.

The choice of elicitation technique depends on different factors such as the time and
resource available and the kind of information that is required.
 Cont.
Some of these techniques are:
 Interviews: Q&A answer session with stakeholders.

 Questionnaire: a document with pre-defined set of questions is handed over to all

stakeholders to answer, which are later collected and compiled.

 Observation: visit the client’s organization or workplace and observe the actual workflow

 Ethnography (aka participant observation): gather requirements while participating in the

real work environment.

 Document analysis: study existing base documentations (forms, policies, regulations)

 Prototyping: producing a working model

 2. Requirements Analysis

Requirements analysis is

 the process of analyzing gathered requirements to form a clear understanding of the

exact customer requirements and to weed out several types of problems that frequently
occur in the requirements that have been gathered from different sources.

Ambiguities, incompleteness, and inconsistencies are some of the major problems to look
for during analysis.

 Ambiguities: this is when one requirement has more than one meaning or interpretation.
 Cont.
 Inconsistency: Two requirements are said to be inconsistent, if one requirement
contradicts the other.

 Inevitably, different stakeholders have different views on the importance and priority of
requirements and, sometimes, these views are conflicting.

 This may necessitate helping stakeholders whose requirements conflict (with each other
or with cost or other constraints) to negotiate acceptable trade-offs.

 Incompleteness: An incomplete set of requirements is one in which some requirements

have been overlooked and missed out.
 Cont.
In addition to these, some system requirements can not be satisfied.

 Some may be technically infeasible, others may be too costly to implement and some

will be mutually incompatible.

 The goal is to identify the scope of the system and a ‘baseline’ set of system

requirements that is feasible and acceptable.

 Cont.
Overall, the 2 main tasks in requirements analysis are:

 Requirements classification and organization:

 This activity takes the unstructured collection of requirements, groups related

requirements, and organizes them into coherent clusters.

 Requirements prioritization and negotiation:

 This activity is concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiation.
 3. Requirements Specification

Requirements specification is

 the process of specifically writing down the refined requirements in a coherent

requirements document known as the software requirements specification (SRS)
document.

SRS document is the output of the requirements analysis and specification phase.
 4. Requirements Validation

Requirements validation is

 the process of examining and checking that the requirements document actually defines
the right system that the customer really wants.

This is conducted to ensure that the SRS document itself is of good quality and the SRS
reflects the actual requirements accurately and clearly.
 Cont.
It aims to pick up any problems/errors before resources are committed to addressing the
requirements.

 As the longer an error remains undetected, the greater the cost of correcting it.

 Thus, it is extremely desirable to detect errors in the requirements before the design and
development of the software begin.

Typically, the most common errors that occur in SRS are of four types:

 omission, inconsistency, incorrect fact, and ambiguity.

 Cont.

 Omission: some user requirements are simply not included in the SRS.

 Inconsistency: contradictions within the requirements themselves or with the

environment in which the system will operate.

 Incorrect fact: some of the facts recorded in the SRS are not correct.

 Ambiguity: one requirement has more than one meaning or interpretation.

 Cont.
So, during the requirements validation process, types of checks that should be carried out
on the requirements document are:

 Validity checks: check requirements are indeed needs of the customer.

 Consistency checks: check no contradictory or conflicting requirements.

 Completeness checks: check all requirements are defined and included.

 Realism checks: check to ensure that the requirements can actually be implemented.

 Verifiability checks: check the requirements are written in verifiable terms.

 How is the SRS document validated?

As requirements are generally textual documents that cannot be executed, reviews are
eminently suitable for requirements validation.

 So, requirements review is the most common method of validation.

Requirements review is a review by a group of people to find errors and point out other
matters of concern in the requirements specifications of a system.
 Cont.
Once the SRS document is ready,

 it is first reviewed internally by the project team to ensure that it accurately captures all
the user requirements, and that it is understandable, consistent, unambiguous, and
complete.

 then the SRS document is reviewed by the customer.

After the customer has reviewed the SRS document and agrees to it, it forms the basis for
all future development activities and also serves as a contract document between the
customer and the development organization.
 5. Requirements Management
Requirements management is

 the process of understanding and controlling changes to system requirements.

It incorporates a set of activities that help the project team identify, control, and track
requirements and changes to requirements at any time as the project proceeds.

We need to keep track of individual requirements and maintain links between dependent
requirements so that you can assess the impact of requirements changes.
 Types of Requirements

Software requirements are often classified into two.

I. Functional requirements and

II. Non-Functional requirements

 I. Functional Requirements
Functional requirements are statements of services a given system should provide.

 It captures the functionalities required by the users from the system.

 They describe the relationship between the input and output of the system.

 Which outputs should be produced from the given inputs.

 The system behavior for all foreseen inputs and all foreseen system states should be
specified.

 the behavior of the system for invalid inputs and invalid outputs

 behavior of the system when the input is valid but the normal operation cannot be
performed
 Cont.

In principle, the functional requirements specification of a system should be both

 Complete - means that all services required by the user should be defined and

 Consistent - means that requirements should not have contradictory definitions.

E.g. In banking system deposit money, withdraw money, check account balance are some
of the functional requirements.
 II. Non-Functional Requirements
Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services (functionalities) delivered by the system to its users.

 Rather they usually specify or constrain characteristics of the system as a whole.

The constraints are on the services or functions offered by the system.

 This may include timing constraints, constraints on the development process, and
constraints imposed by standards.
 Cont.
Non-functional requirements may come from required characteristics of the software
(product requirements), the organization developing the software (organizational
requirements), or from external sources:

A. Product requirements:

 NFR that specify or constrain the behavior of the software product.

 Examples include performance requirements on how fast the system must execute and
how much memory it requires, reliability requirements that set out the acceptable failure
rate, security requirements, and usability requirements.
 Cont.
B. Organizational requirements:

 NFR derived from policies and procedures in the customer’s and developer’s
organization.

 Examples include operational process requirements that define how the system will be
used, development process requirements that specify the programming language, the
development environment or process standards to be used, and environmental
requirements that specify the operating environment of the system.
 Cont.
C. External requirements:

 NFRs derived from factors external to the system and its development process.

 These may include regulatory requirements that set out what must be done for the
system to be approved for use by a regulator.

 For example legislative requirements that must be followed to ensure that the system
operates within the law; and ethical requirements that ensure that the system will be
acceptable to its users and the general public.
Users of requirements document
 Cont.
It is important to avoid vague and unverifiable requirements that depend for their
interpretation on subjective judgement.

 Whenever possible, you should write non-functional requirements quantitatively in

measurable terms so that they can be objectively tested.

Requirements such as “the system shall be reliable” or “response time should be good” or
“the system must be able to process all the transactions quickly” are not desirable because
they are imprecise and not verifiable.

Instead, statements like “the response time of command x should be less than one second
90% of the times” or “a transaction should be processed in less than one second 98% of
the times” should be used to declare performance specifications.
Users of requirements document
 Advantages of a good SRS document
1. It establishes the basis for agreement between the client and the developer on what the
software product will do.

 So, through SRS, the client clearly describes what it expects from the developer, and the
developer clearly understands what capabilities to build in the software.

 This basis for agreement is frequently formalized into a legal contract between the client
and the developer.
 Cont.
2. It provides a reference for validation of the final product.

 That is, the SRS helps the client determine if the software meets the requirements.

 Without a proper SRS, there is no way a client can determine if the software being
delivered is what was ordered, and there is no way the developer can convince the
client that all the requirements have been fulfilled.
 Cont.
3. Provides a basis for estimating costs and schedules:

 Project managers usually estimate the size of the software, the effort required to
develop the software and the total cost of development based on the SRS document.
They also uses the SRS document for work scheduling.

 The SRS document also serves as a basis for price negotiations with the customer.

4. The SRS document can even be used as a legal document to settle disputes between the
customers and the developers in a court of law.
 Cont.
5. A high-quality SRS is a prerequisite to high-quality software and reduces the development
cost.

 The cost of fixing an error increases almost exponentially as time progresses.

 Hence, by improving the quality of requirements, we can have a huge savings in the
future by having fewer expensive defect removals.