Domain Requirements:

Definition: Domain requirements are specific to the application domain or industry in which the
software system will be used. They reflect the unique characteristics, constraints, and regulations of the
domain.

Example:

In the domain of healthcare, a requirement could be:

- "The system must comply with HIPAA regulations for patient data privacy and security."

Functional and Non-Functional Requirements:

Functional Requirements:

Definition: Functional requirements describe the specific behaviors or functions that the software
system must perform to meet user needs.

Example:

For a banking application, a functional requirement could be:

- "The system must allow users to transfer funds between accounts."

Non-Functional Requirements:

Definition: Non-functional requirements specify the quality attributes or constraints of the system, such
as performance, usability, reliability, or security.

Example:

For the same banking application, a non-functional requirement could be:

- "The system must process fund transfers within 5 seconds, with a maximum downtime of 99.9%."

User Requirements:

Definition: User requirements represent the needs, expectations, and preferences of system users. They
focus on the features and functionalities that users want from the software.

Example:

For a social media platform, a user requirement could be:

- "The system must provide a 'like' button for users to express approval of posts."

Software Requirements Engineering:

Definition: Software Requirements Engineering (SRE) is the process of eliciting, analyzing, documenting,
validating, and managing software requirements throughout the software development lifecycle.

Example: In the development of a new e-commerce website, SRE involves gathering requirements from
stakeholders (e.g., customers, marketing team), analyzing these requirements to determine system
functionality and constraints, documenting them in a requirements specification document, validating
them to ensure they meet stakeholder needs, and managing changes to requirements as the project
progresses.

Business Requirements Engineering and BRD:

Definition: Business Requirements Engineering (BRE) focuses on understanding and documenting the
high-level business objectives, goals, and processes that the software system is intended to support.

Example:

In the development of an inventory management system for a retail company, business requirements
could include:

- "The system must accurately track inventory levels across multiple warehouses."

- "The system must generate automated reorder notifications when inventory levels fall below a certain
threshold."

BRD (Business Requirements Document):

A BRD is a formal document that outlines the business requirements for a software project. It serves as a
reference for stakeholders and provides a basis for software development activities.

Characteristics of Good Requirements:

1. Clear and Unambiguous: Requirements should be easy to understand and leave no room for
interpretation.

2. Complete: Requirements should capture all necessary functionalities and constraints of the system.

3. Consistent: Requirements should not contradict each other and should align with project objectives.

4. Feasible: Requirements should be achievable within project constraints (e.g., budget, schedule,
technology).

5. Testable: Requirements should be verifiable through testing to ensure that they are implemented
correctly.

6. Traceable: Requirements should be traceable to their source and to other project artifacts (e.g.,
design, test cases).

7. Prioritized: Requirements should be prioritized based on their importance and impact on project
success.

8. Modifiable: Requirements should be flexible and able to accommodate changes as project

requirements evolve.

Problems in Requirements Elicitation:

1. Incomplete Requirements: Stakeholders may fail to express all their needs, leading to missing or
overlooked requirements
2. Ambiguity: Requirements may be unclear, vague, or open to interpretation, causing confusion and
misunderstandings among stakeholders and development teams.

3. Inconsistent Requirements: Conflicting or contradictory requirements from different stakeholders

can make it challenging to determine the correct course of action.

4. Changing Requirements: Requirements may evolve over time due to changing business needs,
market conditions, or stakeholder priorities, leading to scope creep and project delays.

5. Unrealistic Expectations: Stakeholders may have unrealistic expectations regarding the capabilities,
cost, or timeline of the project, leading to dissatisfaction and disappointment.

6. Lack of Stakeholder Engagement: Insufficient involvement or participation from key stakeholders can
result in requirements that do not fully address their needs or priorities.

7. Technological Constraints: Limited understanding of technology constraints or capabilities may result

in requirements that are not feasible or practical to implement.

8. Scope Creep: Continuous addition of new requirements without proper prioritization or impact
analysis can lead to scope creep, causing delays and budget overruns.

9. Dependency Issues: Dependencies between requirements or external factors may not be adequately
identified, leading to delays or conflicts during implementation.

10. Poor Communication: Communication breakdowns between stakeholders, development teams, and
other project stakeholders can hinder the elicitation and validation of requirements.

Roles and Duties of Business Analysts:

1. Requirement Elicitation: Gather and analyze business requirements through techniques such as
interviews, workshops, and document analysis.

2. Stakeholder Management: Identify and engage with stakeholders to understand their needs,
expectations, and priorities.

3. Requirement Analysis: Analyze and document requirements to ensure clarity, completeness, and
feasibility.

4. Requirement Prioritization: Prioritize requirements based on business value, urgency, and feasibility
to guide project planning and execution.

5. Facilitation: Facilitate meetings, workshops, and discussions to gather requirements, resolve conflicts,
and achieve consensus among stakeholders.

6. Documentation: Document requirements in clear, concise, and unambiguous language using

appropriate formats and tools.

7. Change Management: Manage changes to requirements throughout the project lifecycle, ensuring
that changes are properly evaluated, approved, and implemented.

8. Communication: Serve as a liaison between business stakeholders and development teams, ensuring
clear and effective communication of requirements and project expectations.
9. Risk Management: Identify and assess risks related to requirements, dependencies, and project
constraints, and develop mitigation strategies to address them.

10. Quality Assurance: Ensure that requirements meet quality standards and align with business
objectives, facilitating user acceptance testing and validation.

Interface Analysis:

- Description: Examines interactions between components, subsystems, or external systems.

- Purpose: Identifies interface requirements and compatibility issues.

- Process: Identifies interfaces, analyzes data flow, assesses compatibility, resolves conflicts, and
documents requirements.

Joint Application Design (JAD):

- Description: Collaborative workshops to define system requirements.

- Purpose: Accelerates requirements gathering and promotes stakeholder consensus.

- Process: Prepares, facilitates workshops, defines requirements, validates, and documents results.

Quality Function Deployment (QFD):

- Description: Translates customer requirements into product features.

- Purpose: Ensures customer needs drive product design.

- Process: Analyzes voice of the customer, identifies needs, creates matrices, prioritizes requirements,
and plans implementation.