Programming Engineering Lecture 6 Alaa.pptx

Lecture 6: Requirements Engineering
 Requirements Engineering
 Phases of Requirements Engineering
1. Requirements Elicitation
2. Requirements Analysis
3. Requirements Specification
4. Requirements Validation
5. Requirements Management
 Types of Requirements
 Benefits in Requirements Engineering
 Challenges in Requirements Engineering

Requirements Engineering is a crucial discipline in
software development that sets the foundation for a
successful project.
By systematically eliciting, analyzing, specifying,
validating, and managing requirements, development
teams can ensure that the final product aligns with
stakeholder expectations, is of high quality, and is
delivered on time and within budget.
Implementing best practices in requirements engineering
helps mitigate common challenges, leading to more
predictable and successful project outcomes.
Overview

Definition: Requirements Engineering (RE) is a systematic
process of defining, documenting, and maintaining the
requirements of a software system.
It is an essential part of software development that focuses
on understanding what the stakeholders need and ensuring
that the developed system meets these needs.
Requirements engineering systematic process involves
gathering, analyzing, specifying, validating, and managing
requirements throughout the software development
lifecycle.

Phases of Requirements Engineering
1.Requirements Elicitation ‫استنباط‬
2.Requirements Analysis
3.Requirements Specification
4.Requirements Validation
5.Requirements Management

1.Requirements Elicitation
o Definition: The process of gathering requirements
from stakeholders ‫المالكون‬, users, customers, and other
sources.
o Purpose: To understand what the stakeholders need,
want expect from the system.
o Challenges:
 Difficulty in extracting clear requirements due to
vague or conflicting stakeholder needs.
 Communication barriers between technical teams
and non-technical stakeholders.

oTechniques:
 Interviews: One-on-one discussions with stakeholders
to gather detailed insights.
 Surveys and Questionnaires: Collecting structured data
from a large group of stakeholders.
 Workshops: Collaborative sessions that bring
stakeholders together to discuss requirements.
 Observation: Watching how users interact with existing
systems to identify needs.
 Prototyping: Creating preliminary models of the system
to gather feedback on requirements.
‫حول‬ ‫الفعل‬ ‫ردود‬ ‫لجمع‬ ‫للنظام‬ ‫أولية‬ ‫نماذج‬ ‫إنشاء‬
‫المتطلبات‬.

2. Requirements Analysis
o Definition: Analyzing gathered requirements to ensure they are complete,
consistent, and feasible. ‫وقابلة‬ ‫ومتسقة‬ ‫كاملة‬ ‫أنها‬ ‫من‬ ‫للتأكد‬ ‫المجمعة‬ ‫المتطلبات‬ ‫تحليل‬
‫للتنفيذ‬.
o Purpose: To refine and prioritize requirements, resolving any conflicts or
ambiguities. :‫غموض‬ ‫أو‬ ‫تعارضات‬ ‫أي‬ ‫وحل‬ ،‫األولوية‬ ‫وإعطائها‬ ‫المتطلبات‬ ‫لتحسين‬.
o Techniques:
 Modeling: Creating visual representations of requirements, such as data
flow diagrams, use cases, and entity-relationship diagrams.
 Prioritization: Ranking requirements based on factors like importance,
risk, and feasibility.
 Feasibility Analysis: Assessing whether requirements are realistic
given the project’s technical, financial, and time constraints.
o Challenges:
 Managing conflicting requirements from different stakeholders.
 Ensuring that all requirements are technically feasible and align with

‫النمذجة‬
: ‫تدفق‬ ‫مخططات‬ ‫مثل‬ ،‫للمتطلبات‬ ‫مرئية‬ ‫تمثيالت‬ ‫إنشاء‬
‫بين‬ ‫العالقة‬ ‫ومخططات‬ ‫االستخدام‬ ‫وحاالت‬ ‫البيانات‬
‫الكيانات‬.
‫األولويات‬ ‫تحديد‬
: ‫والمخاطر‬ ‫األهمية‬ ‫مثل‬ ‫عوامل‬ ‫على‬ ً‫ء‬‫بنا‬ ‫المتطلبات‬ ‫ترتيب‬
‫والجدوى‬.
‫الجدوى‬ ‫تحليل‬
: ‫القيود‬ ‫إلى‬ ‫بالنظر‬ ‫واقعية‬ ‫المتطلبات‬ ‫كانت‬ ‫إذا‬ ‫ما‬ ‫تقييم‬
‫للمشروع‬ ‫والزمنية‬ ‫والمالية‬ ‫الفنية‬.

3. Requirements Specification
o Definition: Documenting the requirements in a clear, detailed, and structured
format.
o Purpose: To provide a formal and agreed-upon description of the system’s
requirements that can serve as a reference for developers, testers, and stakeholders.
o Techniques:
 Software Requirements Specification (SRS) Document: A detailed document
outlining all functional and non-functional requirements, use cases, and
constraints.
 User Stories and Use Cases: Descriptions of how the system will be used,
often written from the perspective of the end-user.
 Requirements Modeling Languages: Using formal languages like UML
(Unified Modeling Language) or BPMN (Business Process Model and
Notation) for visual representation.
o Challenges:
 Writing specifications that are unambiguous and understandable by both technical
and non-technical stakeholders.
 Ensuring the documentation remains up-to-date as requirements evolve.

4. Requirements Validation
o Definition: Ensuring that the documented requirements accurately reflect
the stakeholders’ needs and that they are complete, consistent, and
achievable.
o Purpose: To verify that the requirements will lead to a successful system
that meets stakeholder expectations.
o Techniques:
 Reviews and Inspections: Formal evaluation of requirements
documents by stakeholders, developers, and quality assurance teams.
 Prototyping and Simulations: Developing prototypes or simulations
to validate the requirements through hands-on feedback.
 Testing Requirements: Developing test cases based on requirements
to check their validity and completeness.
o Challenges:
 Gaining consensus from all stakeholders on the validated
requirements.
 Identifying requirements that are vague or open to interpretation.

5. Requirements Management
o Definition: The ongoing process of managing changes to requirements as the
project evolves.
o Purpose: To keep track of requirement changes, maintain consistency, and
ensure that all changes are communicated to the relevant stakeholders.
o Techniques:
 Version Control: Using tools like Git or SVN to manage changes in
requirement documents.
 Traceability Matrices: Mapping requirements to design elements, test
cases, and code to ensure alignment.
 Change Control Boards (CCB): Committees that evaluate and approve
changes to requirements.
o Challenges:
 Managing frequent changes in requirements, especially in agile or rapidly
evolving projects.
 Ensuring all stakeholders are informed of changes and their implications.

Types of Requirements
1. Functional Requirements:
o Describe what the system should do, such as specific
functionalities, features, and operations.
o Examples: User authentication, data processing,
report generation.
2. Non-Functional Requirements:
o Define the quality attributes, performance, and
constraints of the system, such as usability,
reliability, security, and performance.
o Examples: System response time should be under 2
seconds; the system must be operational 99.9% of the
time.

Cont…… Types of Requirements
3. Business Requirements:
o High-level needs of the organization or stakeholders, often related
to achieving strategic goals.
o Examples: The system should reduce processing time by 30%, or
improve customer satisfaction.
1. User Requirements:
o Describe the needs and expectations of the end-users.
o Examples: The system should be accessible via mobile devices, or
users should be able to customize their dashboard.
2. System Requirements:
o Detailed specifications about the system’s environment, technical
requirements, and interaction with other systems.
o Examples: The software must run on Windows, Linux, and macOS;
integration with existing CRM systems.

Benefits of Requirements Engineering
1. Clarity and Focus: Clearly defined requirements help
the development team focus on what needs to be built.
2. Reduced Costs: Identifying requirements early reduces
the cost of changes later in the development process.
3. Improved Quality: Well-defined requirements lead to
better system design, implementation, and testing,
resulting in higher quality software.
4. Stakeholder Alignment: Ensures all stakeholders are
aligned on what the system will do, reducing conflicts
and misunderstandings.

Challenges in Requirements Engineering
1. Changing Requirements: Requirements can change
frequently, making it difficult to maintain consistency.
2. Incomplete or Ambiguous Requirements: Poorly
defined requirements can lead to misinterpretations and
errors in the final product.
3. Stakeholder Conflicts: Different stakeholders may have
conflicting needs, making it challenging to develop a
unified set of requirements.
4. Complexity Management: Large projects can have
thousands of requirements, making management and
tracking difficult.

Programming Engineering Lecture 6 Alaa.pptx

More Related Content

Similar to Programming Engineering Lecture 6 Alaa.pptx

More from ssuser8bddb2

Recently uploaded

Programming Engineering Lecture 6 Alaa.pptx