PARUL UNIVERSITY

Parul Institute of Technology

Computer Science & Engineering

Presentation
on
Software
Engineering

Presented by-
Prashant Kothari (36174)
Software Engineering
 CHAPTER-3
Requirements Engineering
 Requirement Practices : Loopholes

Not understanding the requirements that we take from the customer.

• Record requirements in a unorganized manner
• Not spending enough time verifying the record
• Do not allow mechanisms to control the change
• Lack of importance given to the software that the user wants
 Problem Recognition

Problem recognition in software engineering is the process of identifying a

problem and understanding its nature before attempting to solve it.
Problem recognition is the initial stage in the software development lifecycle
where a need, challenge, or opportunity is identified, which requires a software
solution.
It involves understanding and defining the issues or requirements that the
software is intended to address. This phase is crucial as it sets the foundation
for all subsequent stages, including requirements gathering, system design,
development, and testing.
 Problem Recognition

Key points for problem recognition-

1. Ask questions: Ask questions to understand the problem, such as - what the
system is supposed to do and what the pain points are.
2. Identify constraints and goals: Consider what limits exist, such as - time,
budget and technology, and what the desired outcome is.
3. Involve stakeholders: Consider the needs and concerns of the people who
will be affected by the problem. These people are known as stakeholders.
 Problem Recognition

4. Consider multiple solutions: Consider multiple solutions to the problem and

weigh the pros and cons of each approach.
5. Prioritizing Requirements: Requirements are prioritized based on their
importance to stakeholders and their impact on achieving project goals.
6. Documenting the Problem Statement: The document outlines the context of
the project, the identified issues or opportunities, the goals and objectives, and
the initial set of requirements to be addressed.
 Problem Recognition

7. Consider multiple solutions: Consider multiple solutions to the problem and

weigh the pros and cons of each approach.

8. Prioritizing Requirements: Requirements are prioritized based on their
importance to stakeholders and their impact on achieving project goals
9. Requirements Analysis- Once requirements are collected, they need to be
analyzed to ensure they are clear, complete, consistent, and feasible.
10. Requirements Validation- Validation involves checking requirements for
correctness, consistency, and completeness through techniques such as
 Problem Recognition

11. Requirements Management: This involves maintaining traceability of

requirements, establishing baselines, controlling changes and ensuring that all

stakeholders are informed about the status and evolution of requirements.

12. Consider multiple solutions: Consider multiple solutions to the problem and
weigh the pros and cons of each approach.
13. Prioritizing Requirements: Requirements are prioritized based on their
importance to stakeholders and their impact on achieving project goals
14. Requirements Analysis- Once requirements are collected, they need to be
 Requirement Engineering tasks

Requirements engineering tasks involve a structured process to identify,

analyze, and manage the needs and constraints of a software project. This
ensures that the final product meets user expectations and functions correctly.
This process uses tools, methods, and principles to describe the system’s
behavior and the constraints that come along with it.
 Requirement Engineering tasks

• Seven distinct tasks

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
 Requirement Engineering tasks

The tasks in requirement engineering are typically divided into several key
activities-
1. Requirement Inception
The initial phase where the idea of the project is explored, and a broad
understanding of the system is established.
Tasks Involved-
 Identify key stakeholders.
 Discuss the overall project goals and objectives.
 Requirement Engineering tasks

 Conduct feasibility studies to determine whether the project is viable.

 Outline the scope of the project at a high level.
 Requirement Engineering tasks

2. Requirement Elicitation-
Requirement elicitation is the process of gathering information from
stakeholders (clients, end-users, and others).
Tasks Involved- Interviews, Workshops, Surveys/Questionnaires,
Observation, Document Analysis
 Requirement Engineering tasks

Eliciting requirements is not easy because of:

1. Problems of scope in identifying the boundaries of the system or specifying an
excessive amount of technical detail instead of overall system objectives
2. Problems of understanding what's wanted, what the matter domain is, and what
the computing environment can handle (Information that's believed to be
"obvious" is usually omitted)
3. Problems of volatility because the wants change over time
 Requirement Engineering tasks

3. Elaboration
Refining and expanding the gathered requirements into detailed and
structured formats.
Tasks Involved-
 Analyze the gathered requirements for completeness and clarity.
 Develop models, such as data flow diagrams or use cases, to represent the
system.
 Requirement Engineering tasks

 Identify relationships between requirements.

 Eliminate redundant or contradictory requirements.
 Requirement Engineering tasks

4. Negotiation
Resolving conflicts and prioritizing requirements while balancing
stakeholder needs and project constraints.
Tasks Involved-
 Identify conflicting requirements among stakeholders.
 Facilitate discussions to reach agreements on critical requirements.
 Requirement Engineering tasks

 Prioritize requirements using techniques like MoSCoW (Must have,

Should have, Could have, Won’t have).
 Document trade-offs and compromises made during the negotiation
process.
 Requirement Engineering tasks

5. Specification
Creating a formal and comprehensive document that outlines the system's
requirements in detail.
Tasks Involved-
 Document functional requirements, describing what the system will do.
 Document non-functional requirements, including performance, security,
and usability.
 Requirement Engineering tasks

 Define system constraints and assumptions.

 Use structured formats like Software Requirements Specification (SRS).
 Requirement Engineering tasks

6. Validation
Ensuring that the specified requirements accurately represent stakeholders'
needs and are feasible to implement.
Tasks Involved-
 Conduct reviews of the requirements with stakeholders.
 Perform prototyping or simulation to validate key requirements.
 Requirement Engineering tasks

 Check for completeness, consistency, and feasibility.

 Define and document acceptance criteria for each requirement.
 Requirement Engineering tasks

7. Requirements Management
The continuous process of tracking and managing changes to the
requirements throughout the project lifecycle.
Tasks Involved-
 Implement a change control process to handle modifications.
 Maintain traceability of requirements to design, implementation, and
testing phases.
 Requirement Engineering tasks

 Update the requirements document as changes occur.

 Monitor the impact of requirement changes on the project scope, cost, and
timeline.
 Requirement Engineering Processes

The Requirements Engineering process is a systematic approach used in

software engineering to ensure that software systems meet the needs and

expectations of stakeholders.
It involves several interconnected activities that are performed iteratively
throughout the software development lifecycle.
 Requirement Engineering Processes

1. Requirements Elicitation-
Goal: Gather and collect requirements from stakeholders.
Activities: Conduct interviews, workshops, surveys, and observations to
understand stakeholders' needs and expectations.
Outputs: Requirements elicitation document, stakeholder requirements, user
stories, use cases, etc.
 Requirement Engineering Processes

2. Requirements Analysis-
Goal: Analyze and refine gathered requirements for clarity, completeness,
consistency and feasibility.
Activities: Review and prioritize requirements, identify dependencies, and
resolve conflicts or ambiguities.
Outputs: Refined requirements document, prioritized requirements list,
requirements models (e.g., use case diagrams, activity diagrams).
 Requirement Engineering Processes

3. Requirements Specification-
Goal: Document requirements in a clear, unambiguous, and structured manner.
Activities: Write detailed descriptions of functional and non-functional
requirements, create system models (if applicable), and validate with
stakeholders.
Outputs: Requirements specification document, system models (e.g., class
diagrams, sequence diagrams), prototype (if used for validation).
 Requirement Engineering Processes

4. Requirements Validation-
Goal: Ensure that the specified requirements are correct, consistent, complete,
and feasible.
Activities: Validate requirements through reviews, walkthroughs, prototyping,
simulations, and demonstrations.
Outputs: Validated requirements document, feedback from stakeholders,
identified changes or refinements.
 Requirement Engineering Processes

5. Requirements Management-
Goal: Manage changes to requirements throughout the software development
lifecycle.
Activities: Establish baselines for requirements, manage version control, track
changes, and ensure traceability between requirements and other project artifacts.
Outputs: Baseline requirements document, traceability matrix, change requests
and impact analysis.
 Requirement Engineering Processes

6. Requirements Communication-
Goal: Ensure that requirements are clearly communicated to all stakeholders.
Activities: Present requirements in formats understandable to different
stakeholders (e.g., technical specifications for developers, user stories for users),
conduct meetings and status updates.
Outputs: Updated project documentation, meeting minutes, communication
plans.
 Requirement Engineering Processes

7. Requirements Traceability-
Goal: Maintain traceability links between requirements and other project.
Activities: Establish and manage traceability matrices, ensuring that every
requirement is traced to design elements, test cases, and implemented code.
Outputs: Traceability matrix, reports on traceability coverage, updated
documentation.
 Requirement Engineering Processes

8. Requirements Evolution-
Goal: Manage changes in requirements over time.
Activities: Track changes in stakeholder needs, analyze impacts on existing
requirements and project scope, prioritize and implement changes.
Outputs: Updated requirements documentation, change requests, revised project
plans.
 Software Requirement Specifications
A Software requirement specification (SRS) is a document that mentioned
complete description about how the system is expected to perform, behavior
of system, functional and non-functional requirements of the system.
SRS is a formal report, that enables the customers to review whether it (SRS) is
according to their requirements.
User of SRS
1. Client
2. Development team
3. Maintenance team
4. Technical writers
 Need of SRS Document
It structures and formalizes all project requirements.
It helps the development team build a product that exactly meets customer and
target audience needs.
It provides all team members with the necessary information while working on the
project.
It minimize the possible misunderstanding between the members of the development
team and the customer.
It clearly define the scope of work and that allows developers to plan particular
iterations and release dates.
It allows estimating the required development budget.
 Characteristics of good SRS
1. Correctness: provide accurate functional and non-functional requirements as
discussed with client.
2. Completeness: Should complete all essential features like functionality,
performance, features, design, constraints & external interfaces.
3. consistency: Same abbreviation, tabular format, diagram format, naming format
follow.
4. Unambiguousness: Should not be any confusion regarding understanding of the
requirements. Everything mentioned uniquely and clearly.
5. Ranking for importance and stability: Every requirement is important. But some
are urgent and must be fulfilled before other requirements and some could be delayed.
 Characteristics of good SRS
6. Modifiability: It is capable of quickly obtain changes to the system without affecting
other.
7. Verifiability: the requirements are verified with the help of reviewers & stakeholders.
8. Traceability : Every requirements having unique number that is easy to use in future
development.
9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. SRS should not contain any implementation details.
10. Design Independence: An SRS should be written in such a method that it is
simple to generate test cases and test plans from the report.
 Requirements validation
The process of checking that the requirements accurately reflect the needs of
the stakeholders.
Ensures the software meets user expectations, prevents costly rework, and improves
overall project success.
Objectives of Requirements Validation
1. Ensure requirements are complete, consistent, unambiguous, and verifiable.
2. Identify and resolve errors, inconsistencies and omissions early in the
development process.
3. Improve stakeholder confidence in the project.
 Requirements validation
Requirements Validation Techniques
1. Reviews and Inspections
2. Prototyping
3. Test Case Generation
4. Modeling and Simulation

Challenges in Requirements Validation

5. Difficulty in defining complete and accurate requirements.
6. Stakeholder involvement and collaboration.
7. Balancing cost and quality.
8. Evolving requirements
 Requirements validation
Best Practices for Requirements Validation
1. Involve stakeholders early and continuously.
2. Use multiple validation techniques.
3. Document validation activities.
4. Iterative and incremental approach.
5. Prioritize requirements for validation
 Requirements Analysis
Requirement analysis is a crucial stage in software development where the needs
and expectations of stakeholders are identified and documented.
The requirements are typically categorized into two types:
1. functional requirements
2. non-functional requirements
 Requirements Analysis
1. Functional requirements-
Functional requirements focus on the core features and operations that the
system needs to support.
Example: For an online banking application- a functional requirement might
be:
“The system must allow users to transfer funds between accounts.”
 Requirements Analysis
2. Non- functional requirements-
Non-functional requirements address the quality and performance of the
system. They include criteria such as speed, security, scalability, and user
experience, and describe how the system should perform under various
conditions.
Example: A non-functional requirement for the same banking system might be:
“The application should be able to handle 1,000 transactions per minute without
performance issues.”
 Requirements Analysis
Importance of Requirement Analysis in Software Development
 Clear Understanding of Stakeholder Needs
 Avoiding Scope Creep
 Improved Communication and Collaboration
 Reduced Development Costs
 Minimized Risks and Errors
 Better Project Planning
 Improved Quality and User Satisfaction
 Requirements Analysis
Steps involved in the Requirement Analysis Process
1. Identifying Stakeholders and Communicating Needs
2. Gathering Requirements
3. Analyzing and Prioritizing Requirements
4. Documenting Requirements
5. Validating Requirements
6. Creating Use Cases
7. Managing Changes
 Requirements Analysis
Requirement Analysis Techniques
 Data Flow Diagrams (DFD)
 Entity-Relationship Diagrams (ERD)
 Unified Modeling Language (UML)
 State Diagrams
 Flowcharts
 Traceability Matrix
 Use case
A use case diagram is used to represent the interaction between actors (users or
external systems) and a system under consideration to accomplish specific goals.
 Use case
Following are the purposes of a use case diagram given below:
 It gathers the system's needs.
 It shows the external view of the system.
 It recognizes the internal as well as external factors that influence the system.
 It represents the interaction between the actors.
Use case
www.paruluniversity.ac.in