CH-1

Introduction to
Requirement
Engineering
 1. What is requirement?
 A condition or capability needed by a user to solve a problem or achieve an
objective
 A condition or capability that must be met by a system or system component
to satisfy a contract, standard, specification, or other formally imposed
document.
 Requirement describes what a system must do, how it should behave, or the
constraints it must operate within.
 Requirements are essential for guiding the development of software or
systems and ensuring they meet user needs and business goals.
 2. What is requirement Engineering
 What is engineering?
 In software development, engineering refers to the systematic application
of engineering principles to the design, development, testing, deployment,
and maintenance of software systems.
 What is requirement Engineering?
 The systematic process of identifying, documenting, analysing, validating,
and managing requirements for a software or system development project.
 Requirement Engineering is the process of defining, documenting, and
maintaining software or system requirements.
 It covers all activities associated with understanding stakeholder needs,
determining the feasibility of meeting those needs, and managing the
requirements throughout the system's lifecycle.
 2.1. How much RE cost
 The cost of Requirement Engineering can vary significantly depending on
multiple factors, such as the complexity of the project, the size of the team,
and the methods used for eliciting, analysing, and validating requirements.
However, there are some key aspects to consider when estimating the cost:
 Project Complexity
 Team Size and Expertise
 Stakeholder Involvement
 Elicitation Techniques Used
 Tools and Software like JIRA, IBM Rational DOORS, or Microsoft
Team Foundation Server may involve licensing fees or subscription costs.
 Validation and Testing
 2.2. What will happen when requirement are
 When wrong
requirements are wrong or poorly defined in the early stages of a
project, it can have serious negative consequences that ripple through the
entire software development lifecycle.
 Here are some of the potential outcomes when requirements are incorrect:
 Misalignment with Stakeholder Needs
 Increased Costs
 Delays and Extended Timelines
 Poor Quality and Performance
 Scope Creep
 Project Failure
 Legal and Contractual Issues
 2.3. How to Minimize the Impact of Incorrect
 Thorough Elicitation: Requirements
 Ensure detailed and clear communication with stakeholders to gather precise and
complete requirements.
 Regular Review and Validation:
 Frequently validate the requirements with stakeholders to ensure they align with user
needs and business goals.
 Clear Documentation:
 Document the requirements clearly and make sure all stakeholders understand them.
 Traceability:
 Maintain traceability between requirements, design, development, and testing.
 Change Management:
 Establish a structured process for handling changes to requirements, especially as the
project progresses.
 2.4. RE Process
 Requirements Engineering Process(REP) is a systematic process in systems
and software development that focuses on identifying, documenting, and
managing the needs and expectations of stakeholders.
 This process ensures that the final product aligns with stakeholder
requirements and serves as a foundation for subsequent development
activities and future change.
 While there isn't a universally "ideal" requirements engineering (RE) process
applicable to all projects, certain best practices can significantly enhance the
effectiveness of RE activities.
 These practices are adaptable to various methodologies, including traditional
and agile approaches.
 Conti..,
 Best Practices for Requirements Engineering:
 Engage Stakeholders Early and Continuously
 Employ Diverse Elicitation Techniques
 Ensure Requirements Are Clear and Unambiguous
 Prioritize Requirements
 Maintain Traceability
 Validate Requirements Regularly
 Manage Changes Effectively
 2.5.What is Requirement Documents
 Requirements documents are formal written records that detail the conditions,
capabilities, and constraints a system or product must meet to satisfy the needs of its
stakeholders.
 These documents serve as a foundation for system design, development, and testing,
ensuring that all parties have a clear and shared understanding of the project's
objectives and specifications.
 Parts of Requirements Documents:
 Business Requirements Document (BRD)
 This document outlines the high-level goals, objectives, and needs of an
organization for a specific project or business solution.
 Functional Requirements Document (FRD)
 The FRD defines the specific functionalities that the system or product must
perform.
 It translates business requirements into detailed functional specifications, serving
as a guide for developers and testers.
 Conti..,
 Product Requirements Document (PRD):
 A PRD describes the features, functionalities, and behaviour of a product to be
developed.
 It outlines the product's purpose and serves as a blueprint for the development
team.
 Software Requirements Specification (SRS)
 An SRS provides a detailed description of the software system to be developed,
including both functional and non-functional requirements.
 It serves as a contract between stakeholders and developers, ensuring that the
software meets the specified needs.
 2.6.What is Stackholders
 Stakeholders are individuals, groups, or organizations that have an interest
and influence in the outcome of a project or system.
 They can affect or be affected by the project's objectives, decisions, and
deliverables.
 Identifying and understanding stakeholders is crucial for gathering accurate
requirements and ensuring the system meets their needs and expectations.
 Types of Stakeholders in Requirements Engineering:
1. Primary Stakeholders:
 These are individuals or groups within the organization who are
directly involved in its activities.
 End Users: Individuals who will directly interact with the system.
 Employees: Entities that use the product or service as service officer.
 Conti..,
2. Secondary Stakeholders:
 These are individuals or groups which have indirect impact on the
system and who are affected by its actions.
 Managers: Oversee the project and make strategic decisions.
 Support Staff: Provide maintenance and support for the system.
3. External Stakeholders:
 These are individuals or groups outside the organization who can
affect the flow of the system by its actions.
 Regulatory Bodies: Ensure the system complies with laws and
regulations.
 Suppliers: Provide necessary resources or components like third
party APIs.
2.7.what is the R/Ship b/w requirement and design
 Requirements:
 This phase focuses on understanding and documenting what stakeholders
need from the system.
 It involves gathering, analysing, and specifying the conditions or
capabilities that the system must fulfil.
 Requirements serve as the foundation for all subsequent development
activities.
 Design:
 Once requirements are established, the design phase determines how to implement
them.
 This involves creating detailed plans, models, and specifications that outline the
system's architecture, components, interfaces, and data flow.
 The design phase translates the "what" from the requirements into the "how" of the
system's construction.
 3. Software Requirements Engineering
 Software Requirements Engineering is a critical phase in software
development that focuses on identifying, documenting, and managing the
needs and expectations of stakeholders for a software system.
 This process ensures that the final product aligns with user needs and
organizational goals.
 Without a well-defined requirements engineering process, projects are more
susceptible to delays, errors, increased costs, and user dissatisfaction.
 3.1.Why is it Important?
 Effective requirements engineering is crucial because it:
 Ensures Alignment: Aligns the software product with user needs and
business objectives.
 Reduces Risks: Identifies potential issues early, minimizing costly
changes during later stages.
 Improves Quality: Provides a clear basis for design and testing, leading to
higher-quality software.
 Facilitates Communication: Establishes a common understanding among
stakeholders, reducing misunderstandings.
 3.2.Who is Involved?
 Key participants in requirements engineering include:
 Stakeholders: Individuals or groups with an interest in the software, such
as end-users, customers, managers, and regulatory bodies.

 Requirements Engineers: Professionals who facilitate the requirements

process, ensuring thorough documentation and validation.

 Project Managers: Oversee the requirements process, ensuring it aligns

with project goals and timelines.

 Developers and Testers: Utilize the requirements to guide design,

implementation, and testing phases.
 3.3.When is it Conducted?
 Requirements engineering is performed at the beginning of the software
development lifecycle and continues iteratively throughout the project.
 It is revisited during:
 Initial Planning: To define the scope and objectives of the software.

 Design Phases: To refine requirements based on design considerations.

 Change Management: To accommodate new or modified requirements

during development.
 3.4.How is it Performed?
 The process typically involves several stages:

 Elicitation: Gathering requirements from stakeholders through

interviews, surveys, workshops, and document analysis.
 Analysis: Examining and refining the gathered information to identify
conflicts, ambiguities, and priorities.
 Specification: Documenting the requirements in a clear, concise, and
unambiguous manner, often using models and diagrams.
 Validation: Ensuring the documented requirements accurately reflect
stakeholder needs and are feasible.
 Management: Tracking and controlling changes to requirements
throughout the project lifecycle.
 4. Types of Requirements
 A software requirement is a description of what a software system should do
or how it should perform under certain conditions.
 It represents the expectations and needs of stakeholders, including end-users,
business owners, and developers, and serves as the foundation for designing,
building, testing, and maintaining the software.
 Type of requirements;
1. Functional Requirements:
 Describe the specific functionality or behaviour of the system.
 What actions should the software perform?
 Examples:"The user should be able to log in using a username and
password."“
 ‘’The system should calculate total order costs, including taxes and shipping
fees."
 Conti..,
2. Non-Functional Requirements:
 Define the performance, security, and other quality attributes the system
must meet.
 These describe how the system should perform its tasks rather than what it
should do.
 Examples:
 "The system should handle up to 1000 concurrent users.“
 "The software should respond to user actions within 2 seconds."