Mizan Tepi University

 Department: Software Engineering

 Chapter Three and Four
 Course: Requirement Engineering
 Group members
 Name ID
 kalkidan yihun 3987
 Brihanu kassa 3989
 Efrata Mikiyas 1175
 Tesfalegn Petros 3055
 Zelalem Grima 3772
 Nyok biliue 3678
 Content
 Requirement elicitation and analysis
 Elicitation and analysis process
 Elicitation Technique
 Prototyping
 Requirement analysis and negotiation
 Requirement specification
 Modeling
 Writing requirement document
 Chapter three
Requirement Elicitation and analysis

 Requirements elicitation is the process of gathering

and defining the requirements for a software system.
 Analysis is the process of examining, organizing, and
prioritizing the requirements gathered during the
elicitation phase.
 Requirements elicitation practices include interviews,
questionnaires, user observation, workshops ,
brainstorming, use case, role playing and prototyping.
 Elicitation & Analysis process

 It’s a process of interacting with customers and end-users to

find out about the domain requirements, what services the
system should provide, and the other constraints.
 The requirements elicitation and analysis has 4 main
process
 1. Requirements Discovery

 It’s the process of interacting with, and

gathering the requirements from, the
stakeholders about the required system and
the existing system (if exists).
 It can be done using some techniques, like
interviews, scenarios, prototypes, etc, which
help the stockholders to understand what the
system will be like.
2. Requirements Classification & Organization

 It’s very important to organize the overall structure

of the system.
 Putting related requirements together, and
decomposing the system into sub-components of
related requirements. Then, we define the
relationship between these components.
 What we do here will help us in the decision of
identifying the most suitable architectural design
patterns.
 3. Requirements Prioritization & Negotiation
 This activity is concerned with prioritizing
requirements and finding and resolving
requirements conflicts through negotiations until
you reach a situation where some of the
stakeholders can compromise.
 Prioritizing your requirements will help you later to
focus on the essentials and core features of the
system, so you can meet the user expectations. It
can be achieved by giving every piece of function a
priority level. So, functions with higher priorities
need higher attention and focus.
 4. Requirements Specification
 It’s the process of writing down the user and
system requirements into a document. The
requirements should be clear, easy to understand,
complete, and consistent.
 In practice, this is difficult to achieve as
stakeholders interpret the requirements in different
ways and there are often inherent conflicts and
inconsistencies in the requirements.
 Requirements Elicitation technques:
 Some common requirement elicitation techniques include:
 1. Interviews
 Objective of conducting an interview is to understand the
customer’s expectations from the software.
It is impossible to interview every stakeholder hence
representatives from groups are selected based on their
expertise and credibility. Interviews maybe be open-ended or
structured.
 In open-ended interviews there is no pre-set agenda. Context
free questions may be asked to understand the problem.
 In a structured interview, an agenda of fairly open questions is
prepared. Sometimes a proper questionnaire is designed for
the interview
 Cont…

 2. Brainstorming Sessions
 It is a group technique
 It is intended to generate lots of new ideas hence
providing a platform to share views
 A highly trained facilitator is required to handle group
bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the
list of requirements and their priority if possible.
 Cont…
 3.Use Case Approach
 This technique combines text and pictures to provide a better
understanding of the requirements.
 The use cases describe the ‘what’, of a system and not ‘how’.
 The components of the use case design include three major
things – Actor, use cases, use case diagram.
 Actor: It is the external agent that lies outside the system but interacts with
it in some way. An actor maybe a person, machine etc. It is represented as a
stick figure. Actors can be primary actors or secondary actors.

 Primary actors: It requires assistance from the system to achieve a goal.

 Secondary actor: It is an actor from which the system needs assistance.
 .
 Cont…

 Use cases: They describe the sequence of interactions between actors and the
system. They capture who(actors) do what(interaction) with the system. A
complete set of use cases specifies all possible ways to use the system.
 Use case diagram: A use case diagram graphically represents what happens when
an actor interacts with a system. It captures the functional aspect of the system.

 A stick figure is used to represent an actor.

 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
 The success of an elicitation technique used depends on the maturity of the
analyst, developers, users, and the customer involved
 4. Quality Function Deployment

 In this technique customer satisfaction is of prime concern, hence it

emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed software
are discussed with the customer. Example – normal requirements for a result
management system may be entry of marks, calculation of results, etc.
 Expected requirements: These requirements are so obvious that the customer
need not explicitly state them. Example – protection from unauthorized
access.
 Exciting requirements: It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. Example – when
unauthorized access is detected, it should backup and shutdown all processes.
 5.Prototyping
 Prototyping is the process of creating a preliminary version of
a system or product to gather feedback, demonstrate
functionality, and validate requirements.
 It involves building a simplified version of the final product,
typically using rapid development tools or simple coding
techniques.
 Creating prototypes or mockups of the system to
demonstrate functionality and gather feedback from
stakeholders.
 Cont..
 Prototypes can vary in their level of detail,
functionality, and fidelity, depending on the purpose
and scope of the project. Prototypes can be classified
into two main types:
* low-fidelity and
* high-fidelity.

 Low-fidelity prototypes are simple and rough

representations of the system or product, such as
sketches, wireframes, or mockups.
 High-fidelity prototypes are more realistic and
interactive, such as software applications, websites,
or physical devices.
 How to use prototyping for requirements
elicitation?
 Prototyping can be an effective requirement elicitation tool, but you
must follow some basic steps to ensure success.
 First, define the purpose and scope of the prototype, such as the
goals, features, functions, target users and stakeholders.
 Then, decide whether a low-fidelity or high-fidelity prototype is most
appropriate.
 Create the prototype using available tools and techniques such as
paper, pencil, software, hardware or online platforms. Involve users
and stakeholders in the creation process to get their input and
feedback.
 Test and evaluate the prototype by presenting it to users and
stakeholders, observing their reactions and behaviors, and collecting
their feedback.
 Finally, refine and iterate the prototype based on the feedback and
evaluation results until you reach a satisfactory level of requirements
elicitation and validation
 REQUIREMENTS ANALYSIS and Negotiation

 REQUIREMENTS ANALYSIS
 The goal of analysis is to discover problems,
incompleteness and inconsistencies in the elicited
requirements
 Input - A draft system requirements document
 Output - A set of problematic requirements
 A problem checklist may be used to support analysis
 Cont…

 REQUIREMENTS NEGOTIATION
 Requirements negotiation stage involves the different
stakeholders to solve the conflicts and overlaps and agree
on a set of requirements
 Conflicts are not „failures‟ but reflect different
stakeholder needs and priorities
 Input –a set of conflicting or overlapped requirements
 Output –a compromised set of requirements
 Negotiation is interleaved with elicitation and analysis as
problems are discovered and possible solutions are agreed
when the requirements are elicited
 Finding an acceptable compromise can be time consuming
 Chapter four
Requirement Specification
 The production of the requirements stage of the software
development process is Software Requirements
Specifications (SRS) (also called a requirements
document).
 This report lays a foundation for software engineering
activities and is constructing when entire requirements are
elicited and analyzed.
 SRS is a formal report, which acts as a representation of
software that enables the customers to review whether it
(SRS) is according to their requirements. Also, it comprises
user requirements for a system as well as detailed
specifications of the system requirements.
 The features of a good SRS document
 Correctness
 Completeness
 Consistency
 Unambiguousness
 Ranking for importance and stability:
 Modifiability
 Verifiability
 Traceability
 Design Independence
 Testability
 Understandable by the customer:
 Requirements modeling

 Requirements modeling is the process used in

software development projects where requirements
and solutions constantly evolve through collaborative
efforts and teamwork.
 By using this method of cross-functional and self-
organizing teams, you can ensure that your team
meets the exact needs of the stakeholders.
  Cont…
 The main aim of requirements modeling is to support the
end goals of software development. It also aims to
achieve these objectives:
 Identify and establish the best practices required to
create an effective model
 Outline the ways you intend to put said practices into
action
 Always have alternatives to improve the overall
modeling approach
 Elements of the Requirements Model

 Requirements for a computer-based system can be seen in

many different ways. Some software people argue that it’s
worth using a number of different modes of representation
while others believe that it’s best to select one mode of
representation. The specific elements of the requirements
model elements of the requirements model
 Scenario-based elements : Using a scenario-based
approach, system is described from user’s point of
view. For example, basic use cases and their
corresponding use-case diagrams evolve into more
elaborate template-based use cases.
• Class-based elements : A collection of things
that have similar attributes and common
behaviors i.e., objects are categorized into
classes. For example, a UML case diagram
can be used to depict a Sensor class for the
Safe Home security function.
• Behavioral elements : Effect of behavior of
computer-based system can be seen on
design that is chosen and implementation
approach that is applied. Modeling elements
that depict behavior must be provided by
requirements model.
 Writing requirement document
 A software requirement specifications (SRS) document lists
the requirements, expectations, design, and standards for a
future project. These include the high-level business
requirements dictating the goal of the project, end-user
requirements and needs, and the product’s functionality in
technical terms.
 A basic SRS document outline has four parts: an
introduction, system and functional requirements, external
interface requirements, and non-functional requirements.
 1. Introduction
 An SRS introduction is exactly what you expect—it’s a
10,000-foot view of the overall project. When writing your
introduction, describe the purpose of the product, the intended
audience, and how the audience will use it.
 Make sure your introduction is clear and concise. Remember
that your introduction will be your guide to the rest of the SRS
outline, and you want it to be interpreted the same by everyone
using the doc.
 2. System requirements and functional
requirements
 Once you have your introduction, it’s time to get more
specific . Functional requirements break down system
features and functions that allow your system to perform as
intended.
 Use your overview as a reference to check that your
requirements meet the user’s basic needs as you fill in the
details. There are thousands of functional requirements to
include depending on your product.
 3. External interface requirements
 External interface requirements are types of
functional requirements that ensure the system will
communicate properly with external components,
such as User interfaces, Hardware interfaces,
Software interfaces and Communication interfaces.
 Embedded systems rely on external interface requirements.
You should include things like screen layouts, button
functions, and a description of how your product depends
on other systems.
 4. Non-functional requirements (NRFs)

 The final section of your SRS details non-functional

requirements. While functional requirements tell a system
what to do, non-functional requirements (NFRs) determine
how your system will implement these features.
 For example, a functional requirement might tell your
system to print a packing slip when a customer orders your
product. An NFR will ensure that the packing slip prints on
4”x6” white paper, the standard size for packing slips
Here are five steps you can follow to
write an effective SRS document.

1. Define the Purpose With an Outline (Or Use an SRS

Template)
2. Define your Product’s Purpose
3. Describe What You Will Build
4. Detail Your Specific Requirements( functional
requirements, interface requirements, system
features, and various types of nonfunctional
requirements)
5. Deliver for Approval
 en d
Th e