Unit II

Requirements engineering and estimation

Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering design process.
Requirement engineering provides the appropriate mechanism to understand
what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the
specifications and managing the requirements as they are transformed into a
working system. Thus, requirement engineering is the disciplined application of
proven principles, methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
Functional Requirements
These are the requirements that the end user specifically
demands as basic facilities that the system should offer. All
these functionalities need to be necessarily incorporated into the
system as a part of the contract.
These are represented or stated in the form of input to be given
to the system, the operation performed and the output expected.
They are the requirements stated by the user which one can see
directly in the final product, unlike the non-functional
requirements.
Example:
 What are the features that we need to design for this
system?
 What are the edge cases we need to consider, if any, in
our design?
Non-Functional Requirements
These are the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which
these factors are implemented varies from one project to
another. They are also called non-behavioral requirements. They
deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
Example:
 Each request should be processed with the minimum
latency?
 System should be highly valuable.

Difference between Functional

Requirements and Non-Functional
Requirements:
 Non Functional
Functional Requirements Requirements

A non-functional requirement
A functional requirement defines
defines the quality attribute of a
a system or its component.
software system.

It places constraints on “How

It specifies “What should the
should the software system fulfill
software system do?”
the functional requirements?”

Non-functional requirement is
Functional requirement is specified by technical peoples
specified by User. e.g. Architect, Technical leaders
and software developers.

It is mandatory. It is not mandatory.

It is captured as a quality
It is captured in use case.
attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the Helps you to verify the

functionality of the software. performance of the software.

Functional Testing like System, Non-Functional Testing like

Integration, End to End, API Performance, Stress, Usability,
testing, etc are done. Security testing, etc are done.

Usually easy to define. Usually more difficult to define.

Example Example
1) Authentication of user 1) Emails should be sent with a
whenever he/she logs into the latency of no greater than 12
system. hours from such an activity.
2) System shutdown in case of a 2) The processing of each
cyber attack. request should be done within
3) A Verification email is sent to 10 seconds
user whenever he/she registers 3) The site should load in 3
for the first time on some seconds when the number of
software system. simultaneous users are > 10000
Requirements elicitation:
It is the process of gathering and defining the
requirements for a software system. The goal of requirements
elicitation is to ensure that the software development process is
based on a clear and comprehensive understanding of the
customer’s needs and requirements.
What is Requirement Elicitation?
The process of investigating and learning about a system’s requirements from
users, clients, and other stakeholders is known as requirements elicitation.
Requirements elicitation in software engineering is perhaps the most difficult,
most error-prone, and most communication-intensive software development.
1. Requirement Elicitation can be successful only through an effective
customer-developer partnership. It is needed to know what the users
require.
2. Requirements elicitation involves the identification, collection, analysis,
and refinement of the requirements for a software system.
3. Requirement Elicitation is a critical part of the software development life
cycle and is typically performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear,
concise, and well-defined requirements that serve as the basis for the
design and development of the software system.
6. Requirements elicitation is difficult because just questioning users and
customers about system needs may not collect all relevant requirements,
particularly for safety and dependability.
7. Interviews, surveys, user observation, workshops, brainstorming, use
cases, role-playing, and prototyping are all methods for eliciting
requirements.
Importance of Requirements Elicitation
1. Compliance with Business Objectives: The process of elicitation
guarantees that the software development endeavors are in harmony with
the wider company aims and objectives. Comprehending the business
 context facilitates the development of a solution that adds value for the
company.
2. User Satisfaction: It is easier to create software that fulfills end
users’ needs and expectations when they are involved in the requirements
elicitation process. Higher user pleasure and acceptance of the finished
product are the results of this.
3. Time and Money Savings: Having precise and well-defined
specifications aids in preventing miscommunication and rework during
the development phase. As a result, there will be cost savings and the
project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is
crucial for projects in regulated industries to guarantee that the software
conforms with applicable laws and norms. In industries like healthcare,
finance, and aerospace, this is crucial.
5. Traceability and Documentation: Throughout the software
development process, traceability is based on well-documented
requirements. Traceability helps with testing, validation, and maintenance
by ensuring that every part of the software can be linked to a particular
requirement.
Requirements Elicitation Activities
Requirements elicitation includes the subsequent activities. A few of them are
listed below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to
be applied must be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.
Requirements Elicitation Methods
There are several requirements elicitation methods. A few of them are listed
below:
Requirement Elicitation Techniques
1. Interviews
The objective of conducting an interview is to understand the customer’s
expectations of the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility. Interviews may be
open-ended or structured.
1. In open-ended interviews, there is no pre-set agenda. Context-free
questions may be asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions
 Brainstorming Sessions 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 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.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the
developers think they are supposed to build and what customers think they are
going to get. A team-oriented approach is developed for requirements
gathering. Each attendee is asked to make a list of objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, the team is divided into smaller sub-teams to
develop mini-specifications and finally, a draft of specifications is written down
using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes
the requirements that 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. For 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. For example –
when unauthorized access is detected, it should back up and shut down all
processes.
5. Use Case Approach
Use Case 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’. Hence, they only
give a functional view of the system.
The components of the use case design include three major things – Actor, use
cases, and use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts
with it in some way. An actor may be 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.
2. 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.
3. 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.
Steps of Requirements Elicitation
Following are the Steps of Requirement Elicitation

Steps of Requirement Elicitation

1. Identify all the stakeholders, e.g., Users, developers, customers, etc.
2. List out all requirements from the customer.
3. A value indicating the degree of importance is assigned to each
requirement.
4. In the end, the final list of requirements is categorized as:
 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.
Features of Requirements Elicitation
1. Stakeholder engagement: Requirements elicitation involves engaging
with stakeholders such as customers, end-users, project sponsors, and
subject-matter experts to understand their needs and requirements.
2. Gathering information: Requirements elicitation involves gathering
information about the system to be developed, the business processes it
will support, and the end-users who will be using it.
 3. Requirement prioritization: Requirements elicitation involves
prioritizing requirements based on their importance to the project’s
success.
4. Requirements documentation: Requirements elicitation involves
documenting the requirements clearly and concisely so that they can be
easily understood and communicated to the development team.
5. Validation and verification: Requirements elicitation involves
validating and verifying the requirements with the stakeholders to ensure
they accurately represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process that
involves continuously refining and updating the requirements based on
feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation involves
effective communication and collaboration with stakeholders, project
team members, and other relevant parties to ensure that the requirements
are clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to
changing requirements, stakeholder needs, and project constraints.
Advantages of Requirements Elicitation
1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration
between stakeholders.
3. Results in good quality software: Increases the chances of developing a
software system that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to
manage expectations.
5. Supports the identification of potential risks: Supports the
identification of potential risks and problems early in the development
cycle.
6. Facilitates development of accurate plan: Facilitates the development
of a comprehensive and accurate project plan.
7. Increases user confidence: Increases user and stakeholder confidence in
the software development process.
 8. Supports identification of new business opportunities: Supports the
identification of new business opportunities and revenue streams.
Disadvantages of Requirements Elicitation
1. Time-consuming: It can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: This may be impacted by
changing business needs and requirements.
4. Impacted by other factors: Can be impacted by political and
organizational factors.
5. Lack of commitment from stakeholders: This can result in a lack of
buy-in and commitment from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting
priorities and competing interests.
7. Sometimes inaccurate requirements: This may result in incomplete or
inaccurate requirements if not properly managed.
8. Increased development cost: This can lead to increased development
costs and decreased efficiency if requirements are not well-defined.

Requirements Analysis:
Requirement analysis is significant and essential activity after elicitation. We
analyze, refine, and scrutinize the gathered requirements to make consistent and
unambiguous requirements. This activity reviews all requirements and may
provide a graphical view of the entire system. After the completion of the
analysis, it is expected that the understandability of the project may improve
significantly. Here, we may also use the interaction with the customer to clarify
points of confusion and to understand which requirements are more important
than others.
The various steps of requirement analysis are shown in fig:
(i) Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the external
world. It identifies the entities outside the proposed system that interact with the
system. The context diagram of student result management system is given
below:

(ii) Development of a Prototype (optional): One effective way to find out

what the customer wants is to construct a prototype, something that looks and
preferably acts as part of the system they say they want.
We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed
system and increase the understanding of the requirements. When developers
and users are not sure about some of the elements, a prototype may help both
the parties to take a final decision.
Some projects are developed for the general market. In such cases, the prototype
should be shown to some representative sample of the population of potential
purchasers. Even though a person who tries out a prototype may not buy the
final system, but their feedback may allow us to make the product more
attractive to others.
The prototype should be built quickly and at a relatively low cost. Hence it will
always have limitations and would not be acceptable in the final system. This is
an optional activity.
(iii) Model the requirements: This process usually consists of various
graphical representations of the functions, data entities, external entities, and the
relationships between them. The graphical view may help to find incorrect,
inconsistent, missing, and superfluous requirements. Such models include the
Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-
transition diagrams, etc.
(iv) Finalise the requirements: After modeling the requirements, we will have
a better understanding of the system behavior. The inconsistencies and
ambiguities have been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a
prescribed format.
Requirements negotiation:

Negotiation is a conversation between two parties about solving disagreements

or problems such that both sides are satisfied with the outcome. Usually, it
involves giving and taking to reach a compromise. Negotiation is when both
parties make concessions to end the conflict respectfully.
Negotiations between coworkers, managers, departments, or a team member
and a manager may occur at work. Before starting work, you may negotiate the
job opportunity with the interviewer or HR manager.
Here we will define negotiating skills, their advantages, applications in
everyday life, and valuable tips.
Process of Negotiation
In negotiations, two or more parties work together to achieve a good result.
The opposing party will either accept the terms set out or respond with its
position once the first party has offered its own. The process continues until a
compromise is reached by both sides or until negotiations come to an end
without one.
Before a negotiation starts, seasoned negotiators frequently strive to understand
as much as they can about the opposing party's position, including its
advantages and disadvantages, how to get ready to defend their views, and the
possibility of counterarguments.
Depending on the situation, it may take a while for discussions to be finished.
The duration of the negotiation might range from a few minutes to many hours
in more complicated situations.
For instance, the sale of a car may include minutes or hours of negotiation
between the buyer and seller. However, negotiating the details of a significant
trade agreement may take months or even years between the governments of
two or more nations.
Negotiating Skills

Two or more parties can agree on a rational solution using their innate
negotiation abilities. You could have used your negotiations abilities in the
following scenarios at work.
o Negotiating a raise with the HR manager after the promotion
o Negotiating a project period with your team's leader or boss
o negotiating a few days off with your management for a family vacation
o Negotiating agreement conditions with a prospective customer
The business's financial line is impacted, and poor negotiation abilities may
damage client relationships. Soft skills like negotiation are crucial for becoming
a negotiator and resolving issues at work.
This skill set, however, is determined by the work environment, the persons
engaged, and the final objective. When one side is ready to agree, the opposing
party may be resistant. Negotiation becomes challenging in this circumstance,
and you may run across it at work. It would be best if you thus became an
expert negotiator.
Advantages Of Negotiation Skills
Negotiation is a desirable leadership talent that assists firms in reaching their
goals. Here are a few factors that make negotiations abilities crucial in the
workplace
o Relationship-Building:Despite differences of opinion, negotiating skills
may be used to find a compromise and emphasize building trust and
value. A lasting bond is created in this way.
o Provides Superior Solutions: Effective negotiating skills guarantee
long-term resolutions to problems. Because both sides only compromise
when the solution is agreeable, it focuses on developing long-lasting
solutions.
o Prevents Future Disputes: As long as both sides are willing to reach a
consensus, there is far less possibility of disagreements in the future.
o Create a Business-Friendly Atmosphere: Good negotiating skills
guarantee company objectives are met, resulting in a business-friendly
environment. Additionally, it raises the likelihood of future commercial
deals.
Some Negotiation Stages
Following a planned strategy to negotiate may help get the desired result. For
instance, scheduling a meeting that all parties concerned can attend
professionally could be necessary. The following stages make up the negotiating
process.
o Preparation
o Discussion
o Information Exchange
o Bargaining
o Goal clarification
o Negotiate for a win-win result
o Agreement
o Closing the Deal