CS 1212 SOFTWARE ENGINEERING

Lecture 5 – Requirements Engineering

Yahya Hamad Sheikh, PhD

yahya.sheikh@suza.ac.tz

The State University of Zanzibar,

Department of Computer Science and Information Technology
www.suza.ac.tz
 DEFINING REQUIREMENTS ENGINEERING

• Requirements engineering is the rigorous application of scientific principles and

techniques for requirement development, communication, and management.
• It is the process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed.
• It is a four-step process, which includes:
• Feasibility Study: Determine if the user needs can be satisfied with the available technology
and budget.
• Requirements Gathering: Gather information to find out what system stakeholders require from
the system.
• Requirements Specification: Define the requirements in detail. Requirements are written as a
contract between client and contractor.
• Requirements Validation: Checking whether the requirements define the system which the
customer wants.
 FEASIBILITY STUDY

• When the client approaches the organization for getting the desired product
developed, they comes up with only rough idea about what functions the software
must perform, and a set of features expected from the software.
• The analysts does a detailed study about whether the desired system and its
functionality are feasible to develop.
• The focus is to analyze whether the software product can be practically materialized
in terms of implementation, contribution of project to organization, cost constraints
and as per values and objectives of the organization, as well as technical aspects of
the project and product such as usability, maintainability, productivity and
integration ability.
• The output is a feasibility study report that should contains adequate comments and
recommendations for management about whether the project should be undertaken.
 FEASIBILITY STUDY

• When performing feasibility study, the following questions are

addressed:
• Does the system contribute to the overall objectives of the organisation?
• Can the system be implemented using current technology and within
given cost and schedule constraints?
• Can the system be integrated with other systems which are already in
place?
• Information sources include managers where the system is going
to be used, engineers familiar with the type of system, technology
experts, end-users, etc.
 FEASIBILITY STUDY

• Typical questions asked during this stage are:

• What are the problems with current processes and how would the new
system help?
• How would the organisation cope if the system is not implemented?
• What direct contribution will the system has to business objectives?
• Can information be transferred to and from other systems?
• Does the system require technology that has not been implemented
before in the organization?
• What must be supported by the system and what need to be supported?
 REQUIREMENTS GATHERING

• Here, requirements are identified with the help of customers and existing systems processes, if
available.
• Analysts work with customers to determine the application domain, the services that the system
should provide and the system’s operational constraints.
• Stakeholders involved include end-users, managers, engineers involved in maintenance, domain
experts, trade unions, etc.
• The process has five steps, including:
• Domain understanding: Understanding application domain. For example, for supermarket, analyst need
to understand how supermarkets work.
• Requirement collection: Interact with the stakeholders to discover their requirements.
• Requirements Classification: Organise the collected requirements into coherent clusters.
• Conflict resolution: Finding and resolving conflicting requirements from different stakeholders
• Requirements prioritization: Interact with stakeholders to discover the most important requirements
 REQUIREMENTS GATHERING

• Requirements gathering is associated with a number of problems,

of which the analyst need to address. These include:
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.
 IMPEDANCE MISMATCH IN REQUIREMENTS
GATHERING

• Impedance mismatch in requirements gathering refers to a

situation where there is a difference between what stakeholders
want and what developers understand they want.
• This can happen when stakeholders use different terminology than
developers or when stakeholders have different expectations than
developers.
• It can also happen when there is a lack of communication between
stakeholders and developers.
• Impedance mismatch can lead to project delays, cost overruns, and
poor-quality software.
IMPEDANCE MISMATCH IN REQUIREMENTS
GATHERING

As As the Project As System analyst

Management Leader defined it designed it
requested it

As As systems What the

Programmer administrator User wanted
developed it installed it
 TECHNIQUES FOR REQUIREMENTS GATHERING

• Several techniques can be used for requirements gathering/ elicitation, including

interviews, surveys, questionnaires, task analysis, domain analysis, brainstorming,
observation, prototyping, etc.
• A systems analyst can use one or more of these techniques to optimize the
elicitation process.
• Interviews: Interviews are strong medium to collect requirements. Organization
may conduct several types of interviews such as:
• Structured (closed) interviews, where every single information to gather is decided in
advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
• Group interviews which are held between groups of participants. They help to uncover any
missing requirement as numerous people are involved.
 TECHNIQUES FOR REQUIREMENTS GATHERING

• Surveys: Organization may conduct surveys among various stakeholders by

querying about their expectation and requirements from the upcoming system.
• Questionnaires: A document with pre-defined set of objective questions and
respective options is handed over to all stakeholders to answer, which are
collected and compiled.
• A shortcoming of this technique is, if an option for some issue is not mentioned
in the questionnaire, the issue might be left unattended.
• Task Analysis: Team of engineers and developers may analyze the operation
for which the new system is required.
• If the client already has some software to perform certain operation, it is
studied, and requirements of proposed system are collected.
 TECHNIQUES FOR REQUIREMENTS GATHERING

• Domain Analysis: Every software falls into some domain category. The analysts
work with the domain expert to analyze general and specific requirements.
• Brainstorming: An informal debate is held among various stakeholders and all
their inputs are recorded for further requirements analysis.
• Observation: Team of experts visit the client’s organization or workplace to
observe the actual working of the existing installed systems. They observe the
workflow at client’s end and how execution problems are dealt. The team itself
draws some conclusions which aid to form requirements expected from the
software.
• Prototyping: A user interface is built without adding detailed functionality for user
to interpret the features of intended software product. The prototype is shown to the
client and the feedback is noted. The client feedback serves as an input for
requirement gathering.
 REQUIREMENTS SPECIFICATION

• After the analysts collected requirements and write them in the customer ordinary language, the
analysts write the requirement in technical language so that they can be understood and beneficial by
the development team.
• The document produced is called requirements specification document which comprises of different
modeling of the proposed system.
• Among the modelling used are data flow diagrams, entity relationship diagrams, and data dictionaries.
• Data Flow Diagrams (DFDs): DFDs are used widely for modeling the requirements. DFD shows the
flow of data through a system. The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of the preceding.
• Entity-Relationship Diagrams (ERD): These are detailed logical representation of the data for the
organization. They use three main constructs, i.e., data entities, relationships, and their associated
attributes.
• Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items
defined in DFDs. At the requirements stage, the data dictionary should at least define customer data
items, to ensure that the customer and developers use the same definition and terminologies.
 REQUIREMENTS VALIDATION

• Requirements validation is concerned with demonstrating that the requirements

define the system that the customer really wants.
• Requirements error costs are high, so validation is very important. It is
established that, fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
• Prototyping is an important technique of requirements validation.
• During the validation, requirements need to be checked for four main
characteristics:
• Validity: Does the system provide the functions which best support the customer’s needs?
• Consistency: Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism: Can the requirements be implemented given available budget and technology?
 REQUIREMENTS EVOLUTION

• Requirements always evolve as a better understanding of user needs is

developed and as the organisation’s objectives change.
• It is essential to plan for change in the requirements as the system is being
developed and used. Organised and controlled requirements will always lead
to consistency between requirements and a system. Requirements
change

Requirements Requirements Requirements Requirements

document V1 change document V1 document V2

System System System System

implementation V1 implementation V2 implementation V1 implementation V2

Requirements and system Requirements and system

inconsistent consistent
 THE REQUIREMENTS DOCUMENT

• The requirements document is the official statement of what is required of the system.
• It should include both a definition and a specification of requirements
• A Requirement definition is a statement of one thing a product must do or a quality it
must have. A Requirement Specification is a collection of the set of all requirements
that are to be imposed on the design and verification of the product. The specification
also contains other related information necessary for the design, verification, and
maintenance of the product.
• Requirements help to describe what the software should do, while the specification
helps to get a clear understanding of the product to develop it and to minimise
software failures.
• Requirement document is NOT a design document. As far as possible, it should set of
WHAT the system should do rather than HOW it should do it.
 REQUIREMENTS DEFINITION VS SPECIFICATION

• Example of requirement definition:

• 1. The software must provide a means of representing and accessing external files created
by other tools.
• Specifications for this requirement:
• 1.1 The user should be provided with facilities to define the type of external files.
• 1.2 Each external file type should have an associated tool which may be applied to the file.
• 1.3 Each external file type should be represented as a specific icon on the user’s display.
• 1.4 Facilities should be provided for the icon representing an external file type to be
defined by the user.
• 1.5 When a user selects an icon representing an external file, the effect of that selection is
to apply the tool associated with the type of external file to the file represented by the
selected icon.
END OF LECTURE
