UNIT-II

Requirements Engineering Tasks

 Requirements Engineering Tasks
Requirements engineering provides the appropriate mechanism for:

• Understanding what the customer wants: We need to know what the

person who wants the software (the customer) needs or expects from it.
• Analyzing need: We have to examine and think about what is required
carefully.
• Assessing feasibility: We need to check if it's possible to make what
the customer wants. Sometimes, what the customer wants might not be
possible or practical.
• Negotiating a reasonable solution: If there are disagreements or
different ideas about what the software should be, we need to talk and
find a fair solution that works for everyone.
• Specifying the solution unambiguously: We need to clearly describe
in detail what the software should do. This description must be easy to
understand and not confusing.
 Requirements Engineering Tasks

• Validating the specification: We check to make sure that the

description of what the software should do is correct, complete, and
makes sense. This helps prevent misunderstandings.

• Managing the requirements as they are transformed into an

operational system: As the software is being built, we need to keep
track of any changes or updates to what is needed and make sure
everything is on track.
• The requirements engineering process is accomplished
through the execution of seven distinct functions.
 Requirements Engineering Tasks

• The requirements Engineering Tasks are:

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Requirement management
 Requirements Engineering Tasks
• inception: This is the initial phase where the project is conceptualized, and
high-level goals and objectives are defined. It's the starting point for
understanding the customer's needs and the purpose of the software
system.
• Getting Started: Some projects might start with a simple conversation,
while others might evolve over time.
• Business Need or Opportunity: In most cases, software projects begin
when a business identifies a need or an opportunity. This could be because
they want to solve a problem, tap into a new market, or offer a new service.
Key people from the business side, such as managers, marketers, and
product managers, work on defining the business case for the idea.
• Feasibility Analysis: Before developing into the project, they usually do a
rough analysis to see if it's possible to turn the idea into a working software
system. This involves considering factors like technology, resources, and
budget.
 Requirements Engineering Tasks
• Project Scope: They also identify the initial scope of the project. In other
words, they try to figure out what the software should do and how it should
help the business or its customers. This initial understanding can change as
the project progresses.

• Communication with Software Engineers: After these initial steps, the

project idea is usually discussed with the software engineering team. This
marks the inception of the project in the software development process.

• Asking Questions: During this inception phase, software engineers ask a

set of questions to understand the problem, the people who need a solution,
the desired nature of the solution, and how well the customer and
developer have communicated and collaborated.
 Requirements Engineering Tasks
• Elicitation: In this phase, the goal is to gather and extract requirements
from various stakeholders, including customers, end-users, and other
relevant parties. Techniques such as interviews, surveys, and workshops
are often used to capture these requirements.
• Objectives and Usage: The goal of requirements elicitation is to
understand what the system or product is supposed to achieve, how it fits
into the business's needs, and how it will be used on a daily basis. In other
words, it's about getting a clear picture of what the software needs to do.
• Challenges in Elicitation: The several difficulties in this process:
– Problems of Scope: Sometimes, the boundaries of the system are not
clearly defined, or customers/users provide unnecessary technical
details that can make things more confusing instead of clarifying the
objectives.
 Requirements Engineering Tasks
– Problems of Understanding: Customers and users might not be
entirely sure of what they need. They may not fully understand the
capabilities and limitations of their computer systems, lack a complete
understanding of the problem domain, have trouble communicating
their needs, or leave out information they assume is obvious. They
might also specify requirements that conflict with each other or are
unclear and hard to test.
– Problems of Volatility: Requirements can change over time. What was
initially requested may no longer be relevant due to changing
circumstances or evolving business needs.
• Organized Approach: To address these challenges, it's essential for
requirements engineers to approach the requirements gathering activity in
an organized manner. This means having a structured and systematic
approach to gathering, documenting, and managing requirements.
Techniques like interviews, surveys, prototypes, and use cases are often
used to help ensure that the requirements are clearly defined and aligned
with the stakeholders' needs.
 Requirements Engineering Tasks
• Elaboration: Once the requirements are gathered, they need to be refined
and detailed. This phase involves expanding on the initial requirements,
adding more specific information, and clarifying any ambiguities.
• Elaboration in software engineering is a phase that comes after the initial
inception and elicitation stages. During this phase, the information
gathered from the customer and users is further detailed and refined to
create a technical model of the software's functions, features, and
constraints.
• Refinement of Information: Elaboration is about taking the initial
information obtained from customers and users and making it more
detailed and precise. Inception and elicitation provide the basic
understanding, and elaboration refines that understanding.
• Analysis Modeling: Elaboration involves creating a technical model of the
software. This model helps in specifying how the software will work and
what it will do. This is done through various modeling and refinement
tasks.
 Requirements Engineering Tasks
• User Scenarios: User scenarios describe how the end-users and other
actors will interact with the software. These scenarios are used to
understand how the software will be used in real-world situations.
• Analysis Classes: Each user scenario is carefully examined to identify
specific elements, known as analysis classes. These are essentially
business domain entities that the end-user interacts with.
• Attributes and Services: For each analysis class, attributes (characteristics
or properties) are defined. Additionally, the services or functions that each
class will provide are identified. This helps in understanding what the
software needs to do and what data it needs to manage.
• Relationships and Collaboration: During elaboration, the connections and
interactions between different classes are identified. This is essential for
understanding how different parts of the software work together.
• UML Diagrams: Elaboration often involves creating various UML (Unified
Modeling Language) diagrams to visualize and represent the software's
structure and behavior.
 Requirements Engineering Tasks
• End-Result: The outcome of the elaboration phase is an analysis model.
This model defines the informational (what data is involved), functional
(what the software does), and behavioral (how it behaves) aspects of the
software. It provides a detailed and structured understanding of the
software system, which serves as a blueprint for the development team.
 Requirements Engineering Tasks
• Negotiation: Different stakeholders may have conflicting or competing
requirements. Negotiation is the process of resolving these conflicts and
reaching a consensus on the requirements. It's essential to find a balance
between various needs and constraints.
• In software engineering, the negotiation phase is about resolving conflicts
and disagreements that may arise when defining the requirements for a
software project.
• Managing Conflicting Requests: It's common for customers and users to
request more features or capabilities than what can be realistically achieved
given the available resources, like time and budget. Additionally, different
stakeholders may propose conflicting requirements, each arguing that their
version is vital for their specific needs.
• Ranking and Priority: In the negotiation phase, stakeholders are asked to
prioritize their requirements. They need to decide which features or
capabilities are most important and which ones can be deferred or
eliminated if necessary.
 Requirements Engineering Tasks
• Risk Assessment: The risks associated with each requirement are assessed.
This involves identifying potential challenges, complexities, or
uncertainties related to implementing each requirement.
• Estimating Impact: An estimate of the development effort required for
each requirement is made. This estimate is used to understand how each
requirement can affect the project's cost and delivery time.
• Iterative Approach: Negotiation is often an iterative process. It involves
ongoing discussions and compromises. Requirements might be eliminated,
combined, or modified to find a balance that satisfies all parties involved.

• Specification: After the requirements are clear and agreed upon, they need
to be documented in a formal and unambiguous way. Specifications can
take various forms, including written documents, diagrams, or models. The
goal is to ensure that everyone understands what the software is supposed
to do.
• A specification is a description or representation of what the system should
do and how it should perform
 Requirements Engineering Tasks
• Different Forms: Specifications can be presented in different ways,
depending on the project and its needs. They can be:
– A written document: This is a textual description of what the software
should do.
– Graphical models: Diagrams, charts, or visual representations that
illustrate the system's structure or behavior.
– A formal mathematical model: A mathematical description of the
system's behavior and functions.
– Usage scenarios: Descriptions of how the system will be used in
various situations.
– A prototype: A working model of the software that demonstrates its
functionality.
– A combination of these: Sometimes, a combination of these forms may
be used for a more comprehensive understanding.
 Requirements Engineering Tasks
• Flexibility in Specification: The choice of specification format can vary
based on the project's size, complexity, and technical environment. For
larger systems, a detailed written document with natural language
descriptions and graphical models might be appropriate. Smaller and well-
understood projects may only need usage scenarios.
• Foundation for Software Engineering: The specification is a crucial
output of the requirements engineering process. It serves as the starting
point for all subsequent software engineering activities. It defines what the
computer-based system is supposed to do, how it should perform, and the
constraints that need to be considered during its development.
 Requirements Engineering Tasks
• Validation: Validation is the process of ensuring that the specified
requirements accurately represent what the customer and stakeholders
need. It involves reviewing the requirements for correctness, consistency,
and completeness. This step helps avoid misunderstandings and costly
changes later in the development process.
• Requirements Validation: After the requirements for a software project
are gathered and specified, it's crucial to validate them. This means
carefully examining the specification to ensure that it meets certain quality
standards.
• Key Objectives of Validation: Requirements validation serves several
purposes:
– Ensuring unambiguous statements: The requirements should be written
in a clear and precise way so that there is no room for
misinterpretation.
– Detecting and correcting issues: Validation helps identify and fix
problems such as inconsistencies, omissions, and errors in the
requirements.
 Requirements Engineering Tasks
– Conformance to standards: The work products, including the
requirements, should adhere to the established standards for the
software development process, the project itself, and the final product.

• Formal Technical Review: The primary method for requirements

validation is the formal technical review, which is a structured process for
examining the requirements. This review involves a team of individuals,
including software engineers, customers, users, and other stakeholders.
They analyze the specification looking for various issues such as content
errors, misunderstandings, areas where further clarification is needed,
missing information, inconsistencies, conflicting requirements, or
requirements that are not realistic or achievable.
 Requirements Engineering Tasks
Requirements Management: Requirements management is a crucial set of
activities in software engineering that helps project teams identify, control,
and track requirements and changes to those requirements throughout the
project's life. It is essential because requirements for computer-based
systems tend to change, and the desire to change them persists as the
project progresses. Identification: Each requirement is given a unique
identifier to distinguish it from others. This step ensures that every
requirement is clear, distinct, and can be easily referenced.
• Traceability Tables: To manage requirements effectively, various
traceability tables are created. These tables help establish relationships and
dependencies between different aspects of the project:
– Features Traceability Table: This table shows how requirements are
related to the important features that users will observe in the system or
product. It links requirements to customer-visible functionalities.
– Source Traceability Table: This table identifies the source of each
requirement. It helps in understanding where each requirement
originated.
 Requirements Engineering Tasks
– Dependency Traceability Table: This table indicates how
requirements are interconnected and depend on each other. It helps in
understanding the relationships between different requirements.
– Subsystem Traceability Table: Requirements are categorized by the
subsystems they apply to, helping to organize and manage
requirements at the subsystem level.
– Interface Traceability Table: This table reveals how requirements
relate to both internal (within the system) and external (interfacing with
other systems or components) interfaces.
• Requirements Database: Often, these traceability tables are maintained
within a requirements database. This database allows for quick and
efficient searches to understand how a change in one requirement can
impact various aspects of the system. It aids in keeping track of changes,
managing dependencies, and ensuring that the project stays aligned with
the evolving requirements.
Requirements Engineering Tasks