The document provides an overview of requirements engineering, detailing its systematic process of defining, documenting, and maintaining requirements for software development. It outlines seven main tasks: inception, elicitation, elaboration, negotiation, specification, validation, and requirements management, each involving collaboration with stakeholders and ensuring that the system meets their needs. Additionally, it discusses the importance of analysis models, scenario-based elements, and use cases in capturing and representing user interactions.

1. Understanding Requirements
PRESENTED BY
DR.S.VIJAYASANKARI
DEPT OF MCA,
E.M.G YADAVA WOMEN’S COLLEGE,
MADURAI

2. Requirements Engineering
Requirements engineering is a systematic process for defining,
documenting, and maintaining requirements in the engineering design
process
Requirement engineering consists of seven different tasks as follow:
Inception. Inception is a task where the requirement engineering asks a
set of questions to establish a software process. ...
•Elicitation. ...
•Elaboration. ...
•Negotiation. ...
•Specification. ...
•Validation. ...
•Requirement management.

3. Diagram for Requirements
Engineering

4. Requirements Engineering
Inception is a task where the requirement engineering
asks a set of questions to establish a software process.
In this task, it understands the problem and evaluates
with the proper solution. It collaborates with the
relationship between the customer and the developer.
Inception—ask a set of questions that establish …
◦ basic understanding of the problem
◦ the people who want a solution
◦ the nature of the solution that is desired, and
◦ the effectiveness of preliminary communication and
collaboration between the customer and the developer

5. Inception
Identify stakeholders
◦ “who else do you think I should talk to?”
Recognize multiple points of view
Work toward collaboration
The first questions
◦ Who is behind the request for this work?
◦ Who will use the solution?
◦ What will be the economic benefit of a successful
solution
◦ Is there another source for the solution that you need?

6. Elicitation
Elicitation—elicit requirements from all stakeholders
Elicitation in requirements engineering is the process
of gathering and discovering the requirements of a
system from users, customers, and other
stakeholders.
In requirements engineering, requirements
elicitation is the practice of researching and
discovering the requirements of a system from users,
customers, and other stakeholders.

7. Eliciting Requirements
•meetings are conducted and attended by both software engineers
and customers
•rules for preparation and participation are established
•an agenda is suggested
•a "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
•a "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual forum)
is used
•the goal is
• to identify the problem
• propose elements of the solution
• negotiate different approaches, and
• specify a preliminary set of solution requirements

8. Elaboration and Negotiation
Elaboration—create an analysis model that identifies data,
function and behavioral requirements
In this task, the information taken from user during inception and
elaboration and are expanded and refined in elaboration. Its main
task is developing pure model of software using functions,
feature and constraints of a software.
Negotiation—agree on a deliverable system that is realistic for
developers and customers
Requirement negotiation is a part of the requirements engineering
(RE) process, which is used in software development life-cycle
models. It involves discussing and resolving conflicts between
stakeholders to reach a compromise that satisfies everyone. The
goal is to create a set of requirements that meet predetermined
quality criteria, such as correctness and agreement.

9. Specification
In requirement engineering, a specification is a document that
outlines the requirements for a product or process. It's a critical part
of the requirements engineering process, and is usually created after
requirements capture and analysis.
A requirement specification, which is a set of documented
requirements to be satisfied by a material, design, product, or service.
Specification—can be any one (or more) of the following:
◦ A written document
◦ A set of models
◦ A formal mathematical
◦ A collection of user scenarios (use-cases)
◦ A prototype

10. Validation
In requirement engineering, validation is the process of confirming that the
documented requirements match the needs of the stakeholders. It's a phase in the
software development life cycle that ensures the requirements are suitable for the
product.
Validation—a review mechanism that looks for
◦ errors in content or interpretation
◦ areas where clarification may be required
◦ missing information
◦ inconsistencies (a major problem when large products or systems are engineered)
◦ conflicting or unrealistic (unachievable) requirements.
◦ Requirements management conflicting or unrealistic (unachievable) requirements.
◦ The primary goal of systems engineering (SE) is to develop a solution that meets the
needs and requirements of stakeholders. Validation is the process by which
engineers ensure that the system will meet these needs and requirements.
Requirements management

11. Requirements management
Requirements management is the process of gathering, analyzing,
verifying, and validating the needs and requirements for the given
product or system being developed..
Requirements management process
Collect initial requirements from stakeholders.
Analyze requirements.
Define and record requirements.
Prioritize requirements.
Agree on and approve requirements.
Trace requirements to work items.
Query stakeholders after implementation on needed changes to
requirements.

12. Building the Analysis Model
Elements of the analysis model
◦ Scenario-based elements
◦ Functional—processing narratives for software functions
◦ Use-case—descriptions of the interaction between an
“actor” and the system
◦ Class-based elements
◦ Implied by scenarios
◦ Behavioral elements
◦ State diagram
◦ Flow-oriented elements
◦ Data flow diagram

13. Scenario-based elements
Scenarios are brief narratives of expected or anticipated use of a system
from both development and end-user viewpoints.
Scenario modeling typically considers three primary types of
scenarios: worst-case, best-case and average scenarios. The worst-case
scenario explores the outcomes under the most adverse conditions,
helping businesses prepare for the toughest challenges.
A scenario analysis generally considers at least three types of
scenarios:
Base-case scenario: A baseline scenario based on current, commonly
accepted assumptions.
Worst-case scenario: The most negative set of assumptions.
Best-case scenario: The ideal projected scenario to achieve goals and
objectives.

14. Class – based elements
Class-based elements: Each usage scenario implies a
set of “objects” that are manipulated as an actor
interacts with the system. These objects are
categorized into classes- a collection of things that
have similar attributes and common behaviors.
Class-based elements : A collection of things that
have similar attributes and common behaviors i.e.,
objects are categorized into classes..
The elements of a class-based model include classes
and objects, attributes, operations, class
responsibility- collaborator (CRC) models,
collaboration diagrams, and packages

15. Diagram for Class-based
Elements

16. Behavioral elements
Behavioral elements depict how external events change the state
of the system
Behavior elements are the strategic elements course of action and
capability, and behavioral elements, which can be subdivided
into internal behavior elements, external behavior elements (also
called services), and events. or the classes that reside within it.
Two types of behavioral models
There are two types of behavioral models that are used to
describe the system behavior, one is data processing model and
another is state machine models. Data processing models are also
known as DFD (Data Flow Diagram) which is used to show how
data is processed as it moves through the system.

17. Flow-oriented elements
Flow-oriented elements: Information is transformed as it flows through a
computer-based system. The system accepts input in a variety of forms; applies
functions to transform it; and produces output in a variety of forms.
Flow-oriented modeling represents how data objects are transformed as they
move through a system. A data flow diagram (DFD) is the diagrammatic form
used to depict this approach. DFDs show the flow of data through processes and
external entities of a system using symbols like circles and arrows.
Data Flow Diagram Symbols
External Entity. External entities — which are also known as terminators,
sources, sinks, or actors — are outside systems that send or receive data to and
from the diagrammed system. ...
Process. ...
Data Store. ...
Data Flow.

18. Diagram for Flow-oriented
Elements

19. Diagram for Flow-oriented
Elements

20. Use-Cases
Use cases in software engineering are a user-centric way to
represent how a user interacts with a product or system. They can
be written as documents or created visually using a use case
model. Use cases help with a variety of tasks, including:
A use case defines a goal-oriented set of interactions between
external actors and the system under consideration. A primary
actor triggers the system behavior in order to achieve a certain
goal. A secondary actor interacts with the system but does not
trigger the use case
A collection of user scenarios that describe the thread of usage of
a system
Each scenario is described from the point-of-view of an “actor”—
a person or device that interacts with the software in some way

21. Use Cases
Each scenario answers the following questions:
◦ Who is the primary actor, the secondary actor (s)?
◦ What are the actor’s goals?
◦ What preconditions should exist before the story begins?
◦ What main tasks or functions are performed by the actor?
◦ What extensions might be considered as the story is described?
◦ What variations in the actor’s interaction are possible?
◦ What system information will the actor acquire, produce, or change?
◦ Will the actor have to inform the system about changes in the external
environment?
◦ What information does the actor desire from the system?
◦ Does the actor wish to be informed about unexpected changes?

22. Thank You