UNIT-2 (SE)

TOPIC:Domain Analysis

Domain Analysis is a crucial aspect of software engineering, focusing on

understanding and analyzing the specific knowledge domain within which the
software system will operate. It involves identifying and documenting the
commonalities, variations, and interrelationships among the entities in a particular
domain. Domain analysis sets the foundation for developing reusable software
components and allows for more efficient and consistent software development across
projects within a similar domain.

What is Domain Analysis?

Domain Analysis is the process of studying and defining the requirements, structures,
and features of a particular domain (such as finance, healthcare, e-commerce, etc.) to
build reusable and robust software solutions. By identifying common concepts,
terminology, and processes, domain analysis enables software engineers to capture the
essential characteristics of a domain, providing a clear and consistent framework for
developing applications that operate in that domain.

In essence, domain analysis addresses the question: What are the standard
requirements, functionalities, and data models required across similar applications
within a particular domain?

Goals of Domain Analysis

1. Standardization: Define a standardized terminology and set of concepts for the domain to
avoid misinterpretation or redundancy.
2. Reusability: Identify reusable components, patterns, and modules that can be used across
multiple applications within the same domain.
3. Efficiency: Streamline the development process by leveraging existing domain knowledge,
reducing redundant efforts.
4. Consistency: Ensure a cohesive understanding and design of the domain, making it easier to
maintain, extend, or integrate future applications.

Process of Domain Analysis

Domain Analysis involves several key steps, each of which plays a role in creating a
detailed model of the domain:

1. Domain Scoping

 Define the boundaries and limitations of the domain to focus on relevant aspects.
  Determine the scope by identifying which subdomains, processes, and features are essential
to the applications in that domain.

2. Domain Modeling

 Construct a domain model that captures the domain’s key concepts, relationships, and
behaviors.
 Create class diagrams, entity-relationship diagrams (ERDs), and other UML diagrams to
represent the relationships and structure of domain entities.
 The domain model acts as a blueprint for how objects interact within the software.

3. Identifying Commonalities and Variabilities

 Determine the shared characteristics (commonalities) that are consistent across all
applications in the domain.
 Identify the aspects of the domain that can vary (variabilities) across different
implementations, such as optional features or customization points.

4. Developing a Feature Model

 A feature model represents the features in a domain, organized hierarchically with

dependencies and relationships.
 Define mandatory features (common to all applications), optional features (features used in
some applications), and alternative features (mutually exclusive features).
 This model helps guide customization, modularization, and configuration of applications
within the domain.

5. Creating Reusable Components

 Based on the domain analysis, design reusable software components such as classes,
modules, and libraries.
 These components encapsulate the commonalities identified in the domain, enabling
developers to reuse them across multiple projects.

6. Documentation and Knowledge Sharing

 Document the findings, models, and reusable components generated during domain analysis
to facilitate consistent understanding and usage.
 Effective documentation ensures that other teams or future projects can leverage the
domain analysis without repeating the research phase.

Outputs of Domain Analysis

The outputs of domain analysis include various artifacts that capture the domain’s
characteristics, which can be reused in future projects. Key outputs include:

 Domain Model: Represents entities, relationships, and behaviors in the domain.

 Feature Model: Shows the common and variable features in the domain.
 Reusable Components: Classes, libraries, and modules that can be shared across projects.
 Domain-Specific Terminology: A glossary of terms specific to the domain for clarity.
 

 Use Cases and Scenarios: Typical interactions and workflows within the domain that guide
software design.

Domain Analysis Techniques

Several techniques are used in domain analysis to ensure that the domain’s nuances
are accurately captured:

1. Knowledge Elicitation: Gather knowledge from domain experts, stakeholders, and end-users
through interviews, workshops, and brainstorming sessions.
2. Document Analysis: Review existing documentation, guidelines, standards, and system
requirements to understand the domain’s foundational elements.
3. Scenario Analysis: Develop real-world scenarios to understand how different components
within the domain interact and evolve over time.
4. Data Modeling: Use ERDs, class diagrams, and other UML tools to capture the domain’s data
structure and relationships.

Advantages of Domain Analysis

1. Reduces Development Time: By reusing previously defined components, software

development becomes faster and more efficient.
2. Improves Consistency: Ensures consistency across applications, as reusable components
follow a standardized model and functionality.
3. Enhances Software Quality: Domain-specific analysis improves accuracy, reducing errors due
to a lack of domain knowledge.
4. Increases Flexibility and Scalability: Well-defined domain models and reusable components
make it easier to adapt applications to changing requirements.

Case Study Example: Domain Analysis in Healthcare

In the healthcare domain, domain analysis plays a critical role in designing software
systems for hospitals, clinics, and insurance providers. Here’s how domain analysis
might unfold:

Domain Scoping: Define the healthcare domain scope to include patient management,
billing, scheduling, and medical records, while excluding pharmacy inventory.

Domain Modeling: Develop a domain model capturing key entities like Patient,
Doctor, Appointment, and MedicalRecord. Use UML class diagrams to represent
these relationships and interactions.

Identifying Commonalities and Variabilities:

Commonalities: All healthcare systems require a Patient record, Doctor information, and
Appointment scheduling.
Variabilities: Some systems may require specialized modules, such as radiology or pharmacy
integration, depending on the organization’s specific needs.

1.

Feature Modeling: Develop a feature model to differentiate between mandatory

features (like patient records and billing) and optional features (like telemedicine and
in-house laboratory support).

Reusable Components: Create reusable classes such as PatientRecord,

DoctorInfo, and AppointmentScheduler. These components are standardized and
can be used in various healthcare applications without modification.

Documentation: Document each component’s specifications, usage scenarios, and

interaction patterns to provide a knowledge base for developers working on healthcare
projects.Through domain analysis, healthcare software development becomes more
efficient, consistent, and adaptable, ensuring that the applications can meet the
dynamic needs of the healthcare industry.

Conclusion

Domain Analysis is essential for creating software that aligns with the specific needs
and characteristics of a particular industry. By identifying reusable components,
standardizing terminology, and capturing domain knowledge, software engineers can
build applications that are consistent, flexible, and maintainable across similar
projects. This process also enhances collaboration among developers, as the shared
domain knowledge facilitates a common understanding and approach to software
development within that domain.

TOPIC:Problem Definition and Scope

In software engineering, the Problem Definition and Scope are two crucial
components in the early phases of requirement gathering. They help to define what
the system is meant to achieve and the boundaries within which it will operate. Let's
break each one down with clear explanations and examples.

1. Problem Definition

The Problem Definition involves understanding and articulating the problem that the
software is intended to solve. It answers the question: "What is the issue or need that
requires a solution?" The purpose is to identify the underlying issues, challenges, or
opportunities that the system must address.

Key Components of Problem Definition:

 Understanding the Problem Domain: This involves analyzing the context in which the
software will be used, understanding the stakeholders' needs, and determining what the
system should accomplish.
 Identifying Stakeholders: Who is impacted by the problem? Stakeholders can be customers,
end users, businesses, or even regulatory authorities.
  Analyzing Current Systems (if any): If there’s an existing system, the problem definition
often includes identifying what’s wrong with it or what improvements are necessary.

Example of Problem Definition:

Imagine a hospital wants to implement an Electronic Health Record (EHR) system.

 Problem: Currently, patient information is stored in paper records, leading to inefficiencies,

errors, and slow access to data. This results in poor patient care and delays in decision-
making.
 Need: A digital system is needed to store, manage, and retrieve patient data quickly and
accurately.

2. Scope

The Scope defines the boundaries of the project. It outlines what the system will and
will not do, specifying the functional and non-functional requirements, as well as
constraints. The scope helps to prevent scope creep (uncontrolled changes or
continuous growth in a project’s scope).

Key Components of Scope:

 Functional Scope: This defines what the system should do—its features, capabilities, and
behaviors.
 Non-functional Scope: This outlines the system's quality attributes such as performance,
security, usability, and reliability.
 Exclusions: It’s just as important to specify what the system will not do to avoid confusion
later.
 Constraints: These include limitations such as budget, technology, time, or regulatory
requirements.

Example of Scope:

For the hospital’s EHR system, the scope might look like this:

Functional Scope:

Store patient medical history.

Allow authorized medical staff to access patient records.

Provide secure login for users.

Support reporting for insurance claims.

Non-functional Scope:

System should load patient records within 3 seconds.

Ensure that the system complies with HIPAA (Health Insurance Portability and Accountability Act) for
data privacy.

Exclusions:

The system will not handle scheduling of patient appointments (this could be handled by a different
system).

The system will not manage financial billing (again, handled by another system).

Constraints:

The system must be compatible with existing hospital hardware (e.g., computers and tablets used by
medical staff).

The project must be completed within 12 months with a budget of $1 million.

Relationship Between Problem Definition and Scope

 Problem Definition helps to understand why the system is needed and what high-level
problems it will solve.
 Scope describes what the system will do (and not do) to solve the defined problem, setting
clear boundaries and expectations.

Importance of Problem Definition and Scope in Requirements

Engineering

 Clear Understanding: Helps stakeholders and developers understand the problem and avoid
miscommunication.
 Focus: Ensures the system addresses the core issues and avoids unnecessary features or
functions that could lead to delays and cost overruns.
 Success Criteria: Provides a baseline against which the system’s progress and success can be
measured.

Example to Illustrate the Difference:

Let’s consider a Mobile Banking App for a bank:

Problem Definition:

Customers are finding it difficult to access their bank accounts while on the go.

Customers need a secure, easy-to-use app for checking balances, making transfers, and paying bills
from their smartphones.

Scope:
Functional Scope:

 Customers can view account balances and transaction history.

 Customers can transfer money between accounts or to other people.
 Customers can pay bills through the app.

Non-functional Scope:

 The app should respond within 2 seconds.

 The app must be available 99.9% of the time.

Exclusions:

 The app will not offer investment advice or stock trading (this would be
part of a separate service).

Constraints:

 The app must support both Android and iOS devices.

Summary

 Problem Definition defines the issue or need that requires a software solution.
 Scope establishes the boundaries of the project, detailing what the system will and won’t do,
along with any limitations. Both are essential for ensuring that the system meets the
stakeholders' needs without exceeding time, budget, and resource constraints.

TOPIC: Requirements and their types

In software engineering, Requirements are the conditions or capabilities that the

software must fulfill to meet the needs of stakeholders. The Requirements Definition
process involves gathering, analyzing, and documenting these needs so that
developers can build the correct system.

Requirements are classified into different types, based on the nature of what they
describe and their level of detail. Below, we explain the types of requirements in
detail, providing examples and clear explanations.

1. Functional Requirements

Functional requirements specify what the system should do. They describe the
expected behavior or functions that the system must support. These requirements are
usually described in terms of inputs, processes, and outputs.

Key Characteristics:

 Define specific behavior or functions.

  Often derived from the problem definition or use cases.
 Represent features that users interact with directly.

Examples of Functional Requirements:

 Login system: "The system must allow users to log in using their username and password."

 Order processing: "The system must allow users to place an order for products, add items to
a shopping cart, and proceed to checkout."
 Reporting: "The system must generate monthly sales reports that can be exported in PDF
format."

Example Scenario:

For an Online Shopping System, functional requirements might include:

 Users must be able to create an account, log in, and recover passwords.
 Customers can search for products by category or keyword.
 Users should be able to add items to their shopping cart and check out using credit card
payments.

2. Non-Functional Requirements

Non-functional requirements describe the quality attributes of the system. They do

not specify specific behaviors, but rather how well the system should perform its tasks.
These requirements often include performance, security, scalability, reliability,
usability, etc.

Key Characteristics:

 Define system attributes and constraints.

 Are related to the system’s performance, usability, and reliability.
 Sometimes described in terms of “quality attributes” or "ilities" (e.g., availability, scalability,
maintainability).

Examples of Non-Functional Requirements:

 Performance: "The system should handle 1000 simultaneous users without degradation in
performance."
 Security: "All user data must be encrypted using AES-256 encryption."
 Usability: "The system should be intuitive enough for a novice user to complete a transaction
in under 5 minutes."
 Availability: "The system must be available 99.9% of the time."

Example Scenario:

For the Online Shopping System, non-functional requirements might include:

 The website must load within 3 seconds.

  The system must support at least 10,000 simultaneous users during peak sales periods.
 The system must ensure all credit card transactions are secure and comply with PCI-DSS
(Payment Card Industry Data Security Standard).

3. User Requirements

User requirements describe the needs and expectations of the system’s users. These
requirements are typically high-level and focus on what the users expect to
accomplish with the system.

Key Characteristics:

 Written in a user-centric language.

 Often described in terms of use cases, user stories, or personas.
 Address what the system should help the user do.

Examples of User Requirements:

 Login: "As a user, I should be able to log in to the system using my email and password."
 Product Search: "As a user, I should be able to search for products by entering keywords or
categories."

Example Scenario:

For the Online Banking System, a user requirement might be:

 "As a customer, I want to view my transaction history so that I can keep track of my
spending."

4. System Requirements

System requirements are detailed specifications that describe the functionality,

performance, and constraints of the system from a technical perspective. They are
often derived from both functional and non-functional requirements.

Key Characteristics:

 Can be divided into both hardware and software requirements.

 Include technical details such as database design, architecture, and third-party integration.
 More detailed and technical than user requirements.

Examples of System Requirements:

 Hardware: "The system must run on a server with at least 8 GB of RAM and a 2.5 GHz
processor."
 Software: "The system should be developed using Java 11 and Spring Framework."
Example Scenario:

For the EHR (Electronic Health Record) System, a system requirement could be:


 "The system must be built on a multi-tier architecture with separate layers for presentation,
business logic, and database."

5. Interface Requirements

Interface requirements describe how the system will interact with other systems or
components. They specify data formats, protocols, and the flow of information
between systems.

Key Characteristics:

 Focus on communication and interaction between components or systems.

 Can define APIs, user interfaces, and external system integrations.

Examples of Interface Requirements:

 API Integration: "The system must provide a RESTful API to retrieve customer order data."
 User Interface: "The system must provide a web-based interface with a navigation menu on
the left side of the page."

Example Scenario:

For the Online Banking System, interface requirements might include:

 "The system must integrate with the bank’s existing ATM system using an ISO 8583
standard."
 "The mobile app should use OAuth 2.0 to authenticate users with the bank's server."

6. Business Requirements

Business requirements describe the high-level goals and objectives that the system
must meet to support the business needs or strategic objectives. These requirements
often align with the business goals of the organization.

Key Characteristics:

 Typically high-level and strategic.

 Represent the "why" behind the system's development.
 Provide justification for the system's development and guide decisions.

Examples of Business Requirements:

 Revenue Generation: "The system should increase online sales by 25% within the first year
of deployment."
  Cost Efficiency: "The new system should reduce the time taken to process customer orders
by 30%, lowering operational costs."

Example Scenario:

For a Retail E-commerce System, a business requirement might be:

 "The system must improve the customer conversion rate by 10% through a streamlined
checkout process."

7. Regulatory Requirements

Regulatory requirements refer to the standards and legal requirements that the
system must adhere to. These requirements are often mandatory and non-negotiable,
ensuring compliance with industry regulations or laws.

Key Characteristics:

 Concern legal, regulatory, or compliance standards.

 Must be followed strictly, often in areas like data privacy, security, and accessibility.

Examples of Regulatory Requirements:

 Data Privacy: "The system must comply with GDPR (General Data Protection Regulation) in
the handling of user data."
 Accessibility: "The system must meet WCAG 2.1 accessibility standards to ensure it is usable
by people with disabilities."

Example Scenario:

For the EHR System, regulatory requirements might include:

 "The system must comply with HIPAA (Health Insurance Portability and Accountability Act) to
ensure patient data is secure and confidential."

Summary of the Types of Requirements:

Type Description Example

Functional Define what the system "User should be able to
Requirements should do (behavior, tasks). search for products."
Define how well the system
Non-Functional "System should respond
should perform (quality
Requirements within 2 seconds."
attributes).
"User should be able to
User High-level user goals and
track their order
Requirements expectations.
status."
 Type Description Example
Detailed technical "System should support
System
specifications for the 10,000 simultaneous
Requirements
system. users."
Describe system interactions "System must expose a
Interface
with other systems or REST API for data
Requirements
components. exchange."
"Increase online sales
Business Strategic business goals and
by 20% in the first
Requirements objectives to be met.
year."
Legal and regulatory
Regulatory "Must comply with GDPR
constraints the system must
Requirements for user data privacy."
comply with.

Conclusion:

A Requirements Definition is a critical phase in the software development lifecycle.

By categorizing requirements into these types—functional, non-functional, user,
system, interface, business, and regulatory—you can ensure that the system meets
both the technical specifications and the stakeholders' needs. Each type addresses a
different aspect of the system and its environment, ensuring that all necessary features,
qualities, and constraints are considered.

TOPIC:

Gathering and analyzing requirements is a critical phase in software engineering. It

involves understanding stakeholders' needs, defining what the system should do, and
ensuring that all the requirements are clear, feasible, and aligned with the project’s
goals. Several techniques are used to gather and analyze requirements effectively,
depending on the project type, stakeholder needs, and available resources.

Techniques for Gathering and Analyzing Requirements

1. Interviews

Interviews involve direct interaction with stakeholders to gather their input. These can
be structured (with a predefined set of questions), unstructured (open-ended), or semi-
structured (a combination of both).

 Structured Interviews: Predefined questions, often with fixed answers.

 Unstructured Interviews: Open-ended questions to allow free-flowing discussions.
 Semi-structured Interviews: A mix of structured and unstructured questions.

Advantages:

 Allows for deep understanding of the stakeholders' needs.

 Direct communication can clarify ambiguities immediately.
Disadvantages:

 Time-consuming.
 May lead to biased or incomplete information if not managed well.

Example:

For an Online Banking System, a project manager might conduct interviews with:

 Customers to understand their needs, such as mobile banking access, security features, and
transaction speed.
 Bank employees to gather functional requirements like account management or transaction
processing.

2. Surveys and Questionnaires

Surveys and questionnaires are useful for collecting data from a large group of people
in a short time. These are typically closed-ended (e.g., multiple-choice) or scaled (e.g.,
Likert scale: strongly agree to strongly disagree) to allow easy data analysis.

Advantages:

 Efficient way to collect feedback from a large audience.

 Cost-effective for projects with limited time and resources.

Disadvantages:

 Limited in terms of depth and detail.

 Response rates may vary, and interpretation of responses may be challenging.

Example:

For the Online Shopping System, a survey might be sent to users asking questions
such as:

 "How satisfied are you with the checkout process?"

 "What features would you like to see improved in the product search?"

3. Use Cases and User Stories

Use cases and user stories are tools used to describe system functionality from the
perspective of end users.

 Use Cases: Provide detailed descriptions of how users will interact with the system. Each use
case describes a specific interaction between a user and the system, along with the steps
involved.
 User Stories: Short, informal descriptions of a feature told from the perspective of an end
user, typically in the form: "As a [user], I want [goal] so that [reason]."

Advantages:
  Helps stakeholders visualize system behavior.
 Supports collaboration between technical and non-technical stakeholders.

Disadvantages:

 User stories can be too simplistic and may need further elaboration.
 Use cases can become overly detailed and complex.

Example:

For a Social Media App, a user story could be:

 "As a user, I want to like and comment on posts so that I can engage with my friends."

A use case for the same scenario might describe the steps for a user liking a post, such
as:

1. User opens a post.

2. User clicks the "Like" button.
3. The system updates the post’s like count.

4. Brainstorming

Brainstorming sessions involve gathering stakeholders in a group to generate ideas

and solutions in a collaborative environment. The goal is to encourage creative
thinking and explore multiple potential solutions to a problem.

Advantages:

 Encourages creativity and innovation.

 Can surface a wide range of ideas in a short time.

Disadvantages:

 Can lead to unstructured or unrealistic ideas if not guided well.

 Some voices might dominate the discussion, leaving out other perspectives.

Example:

For a Mobile Game, a team of game designers and users might brainstorm to come
up with features like levels, player progression, in-app purchases, and game themes.

5. Prototyping

Prototyping involves building a preliminary version (prototype) of the software to

visualize and test its functionality. Users interact with the prototype to provide
feedback on its features and usability.

 Throwaway Prototyping: Quickly built and discarded after feedback.

 Evolutionary Prototyping: Continuously refined based on user feedback until the final
product is reached.
Advantages:

 Helps clarify ambiguous requirements.

 Allows for early user feedback and iteration.

Disadvantages:

 Can lead to a focus on immediate, short-term solutions rather than long-term architecture.
 Users may expect the prototype to be the final product.

Example:

For a Customer Relationship Management (CRM) System, a prototype might be

built with basic functionalities like contact management and lead tracking. Users
could then interact with the prototype to refine features such as reporting or email
automation.

6. Observation (Ethnographic Studies)

Observation involves watching users in their natural environment to understand how

they interact with a system or perform tasks. This technique is particularly useful
when users may not be able to articulate their needs or when tasks are complex.

Advantages:

 Provides deep insights into real-world user behavior.

 Can reveal hidden needs that users may not articulate.

Disadvantages:

 Can be time-consuming and resource-intensive.

 Observers may influence user behavior.

Example:

For a Hospital Management System, observing nurses and doctors during their daily
routines might reveal inefficiencies in patient record management, helping to refine
the system’s design.

7. Document Analysis

Document analysis involves reviewing existing documentation (e.g., manuals, reports,

previous system specifications) to understand the system’s current functionality and
identify gaps or areas for improvement.

Advantages:

 Helps identify existing workflows and systems.

 Can reveal requirements not covered in interviews or surveys.

Disadvantages:
  Historical documents may be outdated or incomplete.
 The context may have changed since the document was created.

Example:

For a Government Portal project, document analysis of existing forms, reports, and
user feedback might help identify requirements such as simplifying data submission
processes or improving the accessibility of public services.

8. JAD (Joint Application Development)

JAD is a facilitated workshop technique in which key stakeholders (e.g., users,

managers, developers) come together to gather and define requirements in a
collaborative setting. It aims to reach a consensus quickly and efficiently.

Advantages:

 Involves all relevant stakeholders in the decision-making process.

 Promotes collaboration and faster decision-making.

Disadvantages:

 Requires a facilitator, which can increase costs.

 Can be time-consuming if the group is large or stakeholders are not aligned.

Example:

For a Payroll System, a JAD session might involve payroll officers, HR staff, IT
developers, and end-users discussing requirements such as salary calculation, tax
deduction rules, and integration with other systems.

9. Storyboarding

Storyboarding is a visual technique used to describe the sequence of events or steps

involved in a user interaction. It is often used in systems with a significant user
interface component, such as web and mobile applications.

Advantages:

 Provides a visual representation of user interactions.

 Helps identify UI/UX issues early in the process.

Disadvantages:

 Not suitable for complex systems with little user interaction.

 May require design tools and expertise.

Example:
For a Movie Streaming App, a storyboard might depict the user journey from
browsing through the app to selecting and watching a movie, helping the team design
a smoother interface.

10. Focus Groups

A focus group involves gathering a small group of stakeholders or users to discuss

their needs and preferences. The group is guided by a facilitator who asks open-ended
questions and encourages discussion.

Advantages:

 Encourages interaction and generates diverse ideas.

 Provides insights into user preferences and expectations.

Disadvantages:

 Group dynamics can lead to bias if dominant participants overshadow others.

 Can be time-consuming and may require skilled facilitation.

Example:

For a Healthcare Mobile App, a focus group might involve patients, doctors, and
nurses discussing features like appointment scheduling, medication reminders, and
secure messaging.

Conclusion

In software engineering, there are numerous techniques for gathering and analyzing
requirements, each with its own strengths and weaknesses. Often, a combination of
techniques is used to ensure that the requirements are well understood, complete, and
aligned with stakeholders' needs.

The choice of technique depends on factors like the type of project, the stakeholders
involved, and available resources. It's crucial to choose the right methods and actively
engage stakeholders throughout the process to ensure a successful software project.

TOPIC: Requirement document,reviewing document and managing documentsin

requirements

In software engineering, requirement documents are essential tools that capture and
communicate the needs, expectations, and constraints of the stakeholders for a given
project. These documents serve as the foundation for designing, developing, and
validating the system. However, over time, requirements may evolve due to changing
business needs, market conditions, or unforeseen challenges. Hence, reviewing and
managing changes to these requirements is a critical aspect of the software
development lifecycle.

Let’s break down each of these topics—requirement documents, reviewing

requirements, and managing changes—with clear explanations and examples.
1. Requirement Documents

A requirement document is a formal written record that specifies the functional and
non-functional requirements for a software system. The document serves as a
communication tool between stakeholders (customers, developers, testers, etc.) and
ensures that everyone has a clear understanding of the system's objectives and
constraints.

Types of Requirement Documents:

Business Requirements Document (BRD)

Describes high-level business objectives and goals the system must achieve.

Focuses on the "why" of the project—why the system is being developed and how it aligns with
business needs.

Example: A bank may produce a BRD stating, "The new online banking platform
should increase customer satisfaction by offering a more intuitive user interface and
reducing transaction time by 30%."

Software Requirements Specification (SRS)

A detailed document that includes both functional and non-functional requirements.

Provides a comprehensive description of the system’s features, interactions, and constraints.

Example:

"The system must allow users to log in with their username and password and must support two-
factor authentication for enhanced security."

Functional Requirements Document (FRD)

Focuses specifically on the system's functions or features—what the system should do from a user
perspective.

Often includes use cases or user stories to describe specific user interactions.

Example: "The system must allow users to reset their password by sending a one-
time link to their registered email address."

Non-Functional Requirements Document (NFRD)

Specifies the quality attributes of the system, such as performance, security, scalability, and usability.

Example: "The system should be able to process at least 1000 transactions per
second."

Interface Requirements Document (IRD)

Specifies how the system will interact with external systems, APIs, or other components.

Example:

1. "The system must provide a RESTful API to allow third-party systems to retrieve user
transaction data."

2. Reviewing Requirements

Reviewing requirements is the process of evaluating the documented requirements

to ensure they are complete, accurate, unambiguous, and feasible. Requirements
reviews are typically done in collaboration with stakeholders, including developers,
testers, business analysts, and customers.

Purpose of Reviewing Requirements:

 Verify Completeness: Ensure that all necessary requirements are included.

 Check Consistency: Ensure that requirements do not conflict with one another.
 Assess Feasibility: Evaluate if the requirements are technically and financially achievable.
 Clarify Ambiguities: Resolve any unclear or vague statements in the requirements.
 Validate Alignment: Ensure the requirements align with business goals and stakeholder
needs.

Types of Requirement Reviews:

Peer Reviews

Involves team members (developers, analysts, testers) reviewing the requirements for technical
accuracy and completeness.

Aimed at identifying errors, inconsistencies, or gaps early in the process.

Example:A developer might point out that the "upload document" requirement is unclear—does it
support multiple file formats or just PDFs?

Walkthroughs

In a walkthrough, the author of the requirements document (usually a business analyst or system
architect) presents the document to stakeholders and walks them through the requirements.

The goal is to get feedback on the document's clarity, completeness, and alignment with business
goals.

Example:

In an E-commerce System, the business analyst might walk through the shopping cart functionalities
with the product owners to ensure all use cases are addressed.

Inspections
 1.

A formal review process where a specific team (including an independent moderator) systematically
checks the requirements document for defects, ambiguities, or inconsistencies.Often includes a
checklist of items to review.

Example:In a Healthcare System project, an inspection might focus on whether all

regulatory requirements (such as HIPAA compliance) are addressed properly.

Prototyping

Creating prototypes (mockups or wireframes) to visualize and simulate the requirements in action.

This helps in identifying potential usability issues or misalignments with user needs.

Example: For a Mobile Banking App, a prototype of the mobile app's user interface
might be developed and reviewed by users to confirm whether the app layout meets
their expectations.

Importance of Reviewing Requirements:

 Ensures that the software will meet the needs of the users and stakeholders.
 Helps catch potential issues early, saving time and resources in later stages.
 Promotes alignment between business objectives and technical implementation.

3. Managing Changes in Requirements

Requirements are often subject to change during the software development lifecycle.
These changes could arise from new business needs, regulatory changes, market
dynamics, or feedback from users. Therefore, it's essential to have a formal process
for managing these changes to prevent scope creep and ensure that all stakeholders
are aligned.

Process for Managing Requirement Changes:

Change Control Process

Establish a formal process for handling changes in requirements, often called change control or
change management.

Changes should be documented, reviewed, and approved before being implemented in the system.

Steps in the Change Control Process:

1. Request for Change: A formal request is made by stakeholders (e.g., product

managers, users).
2. Impact Analysis: The impact of the change on the project timeline, budget, and
existing requirements is analyzed.
3. Review and Approval: The proposed change is reviewed by the project team and
stakeholders, and approval is given before any changes are made.
 4. Implementation: Once approved, the change is implemented and updated in the
requirement documents.
5. Communication: The change is communicated to all relevant stakeholders, and the
updated documents are distributed.

Example: A Payment Gateway system might initially not require multi-currency

support. However, after feedback from international customers, the requirement is
changed to include the ability to process payments in multiple currencies. The change
would follow the steps outlined above for approval and implementation.

Version Control

Maintain different versions of the requirement documents to track changes over time and ensure that
everyone is working with the latest version.

Each version should be clearly labeled, and the changes should be logged (who requested the change,
the reason, and the impact on the project).

Example: A software development project might use a version control system like
Git to track updates to the SRS document and ensure that team members are working
with the most current version.

Requirements Traceability Matrix (RTM)

An RTM is a tool used to track and manage the relationship between requirements and other project
artifacts (designs, code, tests).

When requirements change, the RTM helps ensure that the changes are reflected throughout the
lifecycle—from design to testing.

Example: If a requirement for adding a new "payment method" to the E-commerce

System is changed, the RTM helps trace which parts of the system (design, code, tests)
will be affected by this change.

Impact Analysis :For each change request, an impact analysis is conducted to assess
how the change will affect the project's scope, timeline, resources, and budget.

This helps to prevent unnecessary changes that could derail the project.

Example: A change in the requirement to support "voice recognition" for login in a

banking app could affect the development timeline significantly and would require a
detailed impact analysis to determine if the change is feasible within the existing
constraints.

Best Practices for Managing Requirement Changes:

1. Clear Documentation: Always document changes formally with reasons, impact analysis, and
approvals to ensure transparency.
2. Stakeholder Communication: Keep stakeholders informed about changes and their
implications for the project.
 3. Change Prioritization: Not all changes are equally important. Prioritize changes based on
business value, technical feasibility, and urgency.
4. Scope Control: Regularly review the scope to prevent scope creep. Ensure that changes align
with the project’s overall goals.
5. Traceability: Use tools like RTM to ensure that all requirements are tracked and that changes
are linked to their impact on design, testing, and development.

Conclusion

Requirement documents provide a foundation for building and validating software

systems. They must be clear, complete, and accurately reflect the needs of the
stakeholders. Reviewing requirements helps ensure the documents meet these
standards, identifying issues early in the development process.

Since requirements often change due to evolving needs or unforeseen circumstances,

managing changes effectively is crucial. A formal change control process,
supported by tools like version control and requirements traceability matrices,
helps ensure that changes are carefully evaluated, documented, and communicated.
This disciplined approach ensures that the software development process stays on
track and delivers a system that meets stakeholder expectations.