Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the appropriate
mechanism to understand what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and notation to describe a
proposed system's intended behavior and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the required software performs
a series of levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial
profits for an organization.
2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with the help of
customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify
inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also
resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a software analyst after the
requirements collected from the various sources - the requirement received by the customer written in
ordinary language. It is the job of the analyst to write the requirement in technical language so that they
can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition
diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD
shows the flow of data through a system. The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or any combination of the preceding. The DFD
is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items
defined in DFDs. At the requirements stage, the data dictionary should at least define customer data items, to
ensure that the customer and developers use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship
diagram, often called an "E-R diagram." It is a detailed logical representation of the data for the organization
and uses three main constructs i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are validated.
The user might demand illegal, impossible solution or experts may misinterpret the needs. Requirements
can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the requirements
engineering process and system development.

New requirements emerge during the process as business needs a change, and a better understanding of
the system is developed.

The priority of requirements from different viewpoints changes during development process.

The business and technical environment of the system changes during the development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development project. Hence they
should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
 o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into two categories:

1. Functional Requirements: Functional requirements define a function that a system or system element
must be qualified to perform and must be documented in different forms. The functional requirements are
describing the behavior of the system as it correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the criteria that can be used to
decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run time.
o Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the
static structure of the software system.
Requirements Elicitation – Software Engineering

What is Requirement Elicitation?

Requirements elicitation is perhaps the most difficult, most error-prone, and most communication-
intensive software development.
1. It can be successful only through an effective customer-developer partnership. It is needed to
know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and refinement of the
requirements for a software system.
3. It is a critical part of the software development life cycle and is typically performed at the
beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the organization,
including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and well-defined
requirements that serve as the basis for the design and development of the software system.
Importance of Requirements Elicitation
1. Compliance with Business Objectives: The process of elicitation guarantees that the
software development endeavours(to try hard) are in harmony(agreement of ideas) with the
wider company aims and objectives. Comprehending the business context facilitates the
development of a solution that adds value for the company.
2. User Satisfaction: It is easier to create software that fulfils end users needs and expectations
when they are involved in the requirements elicitation process. Higher user pleasure and
acceptance of the finished product are the results of this.
3. Time and Money Savings: Having precise and well-defined specifications aids in preventing
miscommunication and rework during the development phase. As a result, there will be cost
savings and the project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is crucial for projects
in regulated industries to guarantee that the software conforms with applicable laws and norms.
In industries like healthcare, finance, and aerospace, this is crucial.
5. Traceability and Documentation: Throughout the software development process,
traceability is based on requirements that are well-documented. Traceability helps with testing,
validation, and maintenance by ensuring that every part of the software can be linked to a
particular requirement.
Requirements Elicitation Activities:
Requirements elicitation includes the subsequent activities. A few of them are listed below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to be applied must be
understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.
Requirements Elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed below:
1. Interviews
Objective of conducting an interview is to understand the customer’s expectations from the
software.
It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility. Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.
2. Brainstorming Sessions
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their priority if
possible.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the developers think
they are supposed to build and what customers think they are going to get. A team-oriented
approach is developed for requirements gathering. Each attendee is asked to make a list of
objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a
draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed software are discussed
with the customer. Example – normal requirements for a result management system may be
entry of marks, calculation of results, etc.
 Expected requirements: These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.
 Exciting requirements: It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. Example – when unauthorized access is detected, it
should backup and shutdown all processes.
5. Use Case Approach
This technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional
view of the system.
The components of the use case design include three major things – Actor, use cases, use case
diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in some way. An
actor maybe a person, machine etc. It is represented as a stick figure. Actors can be primary
actors or secondary actors.
 Primary actors: It requires assistance from the system to achieve a goal.
 Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use cases specifies
all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents what happens when an actor
interacts with a system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
The success of an elicitation technique used depends on the maturity of the analyst, developers,
users, and the customer involved.
Steps Of Requirements Elicitation:
1. Identify all the stakeholders, e.g., Users, developers, customers etc.
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as:
 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.
Features of Requirements Elicitation:
1. Stakeholder engagement: Requirements elicitation involves engaging with stakeholders
such as customers, end-users, project sponsors, and subject-matter experts to understand their
needs and requirements.
2. Gathering information: Requirements elicitation involves gathering information about the
system to be developed, the business processes it will support, and the end-users who will be
using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing requirements
based on their importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves documenting the
requirements in a clear and concise manner so that they can be easily understood and
communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating and verifying the
requirements with the stakeholders to ensure that they accurately represent their needs and
requirements.
6. Iterative process: Requirements elicitation is an iterative process that involves continuously
refining and updating the requirements based on feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation involves effective
communication and collaboration with stakeholders, project team members, and other relevant
parties to ensure that the requirements are clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing requirements,
stakeholder needs, and project constraints.

Advantages of Requirements Elicitation:

1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration between stakeholders.
3. Results in good quality software: Increases the chances of developing a software system
that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to manage expectations.
5. Supports the identification of potential risks: Supports the identification of potential risks
and problems early in the development cycle.
6. Facilitates development of accurate plan: Facilitates the development of a comprehensive
and accurate project plan.
7. Increases user confidence: Increases user and stakeholder confidence in the software
development process.
8. Supports identification of new business opportunities: Supports the identification of new
business opportunities and revenue streams.
Disadvantages of Requirements Elicitation:
1. Time consuming: Can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: May be impacted by changing business needs and
requirements.
4. Impacted by other factors: Can be impacted by political and organizational factors.
5. Lack of commitment from stakeholders: Can result in a lack of buy-in and commitment
from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting priorities and competing
interests.
7. Sometimes inaccurate requirements: May result in incomplete or inaccurate requirements
if not properly managed.
8. Increased development cost: Can lead to increased development costs and decreased
efficiency if requirements are not well-defined.

What Is Requirements Elicitation?

It is all about obtaining information from stakeholders. In other words, once the business analysis has communicated
with stakeholders for understanding their requirements, it can be described as elicitation. It can also be described as a
requirement gathering.

Requirement elicitation can be done by communicating with stakeholders directly or by doing some research,
experiments. The activities can be planned, unplanned, or both.

 Planned activities include workshops, experiments.

  Unplanned activities happen randomly. Prior notice is not required for such activities. For example, you
directly go to the client site and start discussing the requirements however there was no specific agenda
published in advance.
Following tasks are the part of elicitation:
 Prepare for Elicitation: The purpose here is to understand the elicitation activity scope, select the right
techniques, and plan for appropriate resources.
 Conduct Elicitation: The purpose here is to explore and identify information related to change.
 Confirm Elicitation Results: In this step, the information gathered in the elicitation session is checked for
accuracy.
We hope, you have got an idea about requirement elicitation by now. Let’s move on to the requirements elicitation
techniques.

Requirements Elicitation Techniques

There are several techniques available for elicitation, however, the commonly used techniques are explained
below:
#1) Stakeholder Analysis
Stakeholders can include team members, customers, any individual who is impacted by the project or it can be a
supplier. Stakeholder analysis is done to identify the stakeholders who will be impacted by the system.

#2) Brainstorming
This technique is used to generate new ideas and find a solution for a specific issue. The members included for
brainstorming can be domain experts, subject matter experts. Multiple ideas and information give you a repository of
knowledge and you can choose from different ideas.

This session is generally conducted around the table discussion. All participants should be given an equal amount of
time to express their ideas.
Brainstorming technique is used to answer the below questions:
 What is the expectation of a system?
 What are the risk factors that affect the proposed system development and what to do to avoid that?
 What are the business and organization rules required to follow?
 What are the options available to resolve the current issues?
 What should we do so that this particular issue does not happen in the future?
Brainstorming can be described in the following phases:

There are some basic rules for this technique which should be followed to make it a success:
 The time limit for the session should be predefined.
 Identify the participants in advance. One should include 6-8 members for the session.
 The agenda should be clear enough for all the participants.
 Clear expectations should be set with the participants.
 Once you get all the information, combine the ideas, and remove the duplicate ideas.
 Once the final list is ready, distribute it among other parties.
Benefits:
 Creative thinking is the result of the brainstorming session.
 Plenty of ideas in a short time.
 Promotes equal participation.
Drawbacks:
  Participants can be involved in debating ideas.
 There can be multiple duplicate ideas.
#3) Interview

This is the most common technique used for requirement elicitation. Interview techniques should be used for building
strong relationships between business analysts and stakeholders. In this technique, the interviewer directs the question
to stakeholders to obtain information. One to one interview is the most commonly used technique.

If the interviewer has a predefined set of questions then it’s called a structured interview.
If the interviewer is not having any particular format or any specific questions then it’s called an unstructured
interview.
For an effective interview, you can consider the 5 Why technique. When you get an answer to all your Whys then you
are done with your interview process. Open-ended questions are used to provide detailed information. In this
interviewee cannot say Yes or No only.

Closed questions can be answered in Yes or No form and also for areas used to get confirmation on answers.
Basic Rules:
 The overall purpose of performing the interviews should be clear.
 Identify the interviewees in advance.
 Interview goals should be communicated to the interviewee.
 Interview questions should be prepared before the interview.
 The location of the interview should be predefined.
 The time limit should be described.
 The interviewer should organize the information and confirm the results with the interviewees as soon as
possible after the interview.
Benefits:
 Interactive discussion with stakeholders.
 The immediate follow-up to ensure the interviewer’s understanding.
 Encourage participation and build relationships by establishing rapport with the stakeholder.
Drawbacks:
 Time is required to plan and conduct interviews.
 Commitment is required from all the participants.
 Sometimes training is required to conduct effective interviews.
#4) Document Analysis/Review
This technique is used to gather business information by reviewing/examining the available materials that describe the
business environment. This analysis is helpful to validate the implementation of current solutions and is also helpful in
understanding the business need.

Document analysis includes reviewing the business plans, technical documents, problem reports, existing requirement
documents, etc. This is useful when the plan is to update an existing system. This technique is useful for migration
projects.
This technique is important in identifying the gaps in the system i.e. to compare the AS-IS process with the TO-BE
process. This analysis also helps when the person who has prepared the existing documentation is no longer present in
the system.

Benefits:
 Existing documents can be used to compare current and future processes.
 Existing documents can be used as a base for future analysis.
Drawbacks:
 Existing documents might not be updated.
 Existing documents might be completely outdated.
 Resources worked on the existing documents might not be available to provide information.
 This process is time-consuming.
#5) Focus Group
By using a focus group, you can get information about a product, service from a group. The Focus group includes
subject matter experts. The objective of this group is to discuss the topic and provide information. A moderator
manages this session.

The moderator should work with business analysts to analyze the results and provide findings to the stakeholders.

If a product is under development and the discussion is required on that product then the result will be to update the
existing requirement or you might get new requirements. If a product is ready to ship then the discussion will be on
releasing the product.

How Focus groups are different than group interviews?

A Focus group is not an interview session conducted as a group; rather it is a discussion during which feedback is
collected on a specific subject. The session results are usually analyzed and reported. A focus group typically consists
of 6 to 12 members. If you want more participants then create more than one focus group.

Benefits:
 You can get information in a single session rather than conducting one to one interview.
 Active discussion with the participants creates a healthy environment.
 One can learn from other’s experiences.
Drawbacks:
 It might be difficult to gather the group on the same date and time.
 If you are doing this using the online method then the participant’s interaction will be limited.
 A Skilled Moderator is required to manage focus group discussions.
#6) Interface Analysis
Interface analysis is used to review the system, people, and processes. This analysis is used to identify how the
information is exchanged between the components. An Interface can be described as a connection between two
components. This is described in the below image:
The interface analysis focus on the below questions:
1. Who will be using the interface?
2. What kind of data will be exchanged?
3. When will the data be exchanged?
4. How to implement the interface?
5. Why we need the interface? Can’t the task be completed without using the interface?
Benefits:
 Provide missed requirements.
 Determine regulations or interface standards.
 Uncover areas where it could be a risk for the project.
Drawbacks:
 The analysis is difficult if internal components are not available.
 It cannot be used as a standalone elicitation activity.
#7) Observation
The main objective of the observation session is to understand the activity, task, tools used, and events performed by
others.

The plan for observation ensures that all stakeholders are aware of the purpose of the observation session, they agree on
the expected outcomes, and that the session meets their expectations. You need to inform the participants that their
performance is not judged.
During the session, the observer should record all the activities and the time taken to perform the work by others so that
he/she can simulate the same. After the session, the BA will review the results and will follow up with the participants.
Observation can be either active or passive.

Active observation is to ask questions and try to attempt the work that other persons are doing.
Passive observation is silent observation i.e. you sit with others and just observe how they are doing their work
without interpreting them.
Benefits:
 The observer will get a practical insight into the work.
 Improvement areas can be easily identified.
Drawbacks:
 Participants might get disturbed.
 Participants might change their way of working during observation and the observer might not get a clear
picture.
 Knowledge-based activities cannot be observed.
#8) Prototyping
Prototyping is used to identify missing or unspecified requirements. In this technique, frequent demos are given to the
client by creating the prototypes so that client can get an idea of how the product will look like. Prototypes can be used
to create a mock-up of sites, and describe the process using diagrams.

Benefits:
 Gives a visual representation of the product.
 Stakeholders can provide feedback early.
Drawbacks:
 If the system or process is highly complex, the prototyping process may become time-consuming.
 Stakeholders may focus on the design specifications of the solution rather than the requirements that any
solution must address.
#9) Joint Application Development (JAD)/ Requirement Workshops
This technique is more process-oriented and formal as compared to other techniques. These are structured meetings
involving end-users, PMs, SMEs. This is used to define, clarify, and complete requirements.

This technique can be divided into the following categories:

 Formal Workshops: These workshops are highly structured and are usually conducted with the selected group
of stakeholders. The main focus of this workshop is to define, create, refine, and reach closure on business
requirements.
 Business Process Improvement Workshops: These are less formal as compared to the above one. Here,
existing business processes are analyzed and process improvements are identified.
Benefits:
 Documentation is completed within hours and is provided quickly back to participants for review.
 You can get on the spot confirmation on requirements.
 Successfully gathered requirements from a large group in a short period.
 Consensus can be achieved as issues and questions are asked in the presence of all the stakeholders.
Drawbacks:
 Stakeholder’s availability might ruin the session.
 The success rate depends on the expertise of the facilitator.
 A workshop motive cannot be achieved if there are too many participants.
#10) Survey/Questionnaire
For Survey/Questionnaire, a set of questions is given to stakeholders to quantify their thoughts. After collecting the
responses from stakeholders, data is analyzed to identify the area of interest of stakeholders.

Questions should be based on high priority risks. Questions should be direct and unambiguous. Once the survey is
ready, notify the participants and remind them to participate.

Two types of questions can be used here:

  Open-Ended: Respondent is given the freedom to provide answers in their own words rather than selecting
from predefined responses. This is useful but at the same time, this is time- consuming as interpreting the
responses is difficult.
 Close Ended: It includes a predefined set of answers for all the questions and the respondent has to choose
from those answers. Questions can be multiple choice or can be ranked from not important to very important.
Benefits:
 Easy to get data from a large audience.
 Less time is required for the participants to respond.
 You can get more accurate information as compared to interviews.
Drawback:
 All the Stakeholders might not participate in the surveys.
 Questions may not be clear to all the participants.
 Open-ended questions require more analysis.
 Follow up surveys might be required based on the responses provided by participants.
Amongst the all above techniques, the top five techniques that are commonly used for elicitation are shown in the
below image.
Conclusion
In this tutorial, we have seen various requirements elicitation techniques. Now, it’s time to look at different kinds of
interview questions that can be asked about elicitation techniques.
Requirements elicitation Methods
There are many requirements elicitation methods. A few of them are listed below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
1. Interviews:
The main objective of an interview is to understand customers' expectations from the software.
It is not possible to interview every stakeholder; hence representatives from groups are selected based on their expertise
and credibility.
Interviews may be structured or open-ended.
1. In a structured interview, agenda of reasonably open questions are prepared. Sometimes a good questionnaire is
designed for the interview.
2. Open-ended interviews do not have any pre-set agenda. Context-free questions may be asked to understand the
problem.
2. Brainstorming Sessions:
 It is a group discussion.
 Its objective is to generate a lot of new ideas and provide a platform to share the view of every member.
 A highly trained facilitator handles group bias and group conflicts.
 Ideas are documented so that everyone can see them.
 Finally, a document is prepared consisting of the list of requirements and their priority if possible.
3. Facilitated Application Specification Technique:
Its objective is to bridge the expectation gap – the difference between what the developers think they have to build and
what customers think they will get.
A team-oriented approach is evolved to get a better understanding of requirements.
Each attendee in the team should make a list of objects such that-
1. They are part of the environment that surrounds the system.
2. The system produces them.
3. The system uses them.
Every participant prepares their list, different lists are then combined, redundant entries are eliminated, the team is divided
into smaller sub-groups to develop mini-specifications, and a draft of specifications is written using all the inputs from the
meeting.
4. Quality Function Deployment:
In this technique, customer satisfaction is the prime concern; hence it emphasizes the valuable requirements to the
customer.
Three types of requirements are identified –
 Normal requirements – It covers the objective and goals of the proposed software are discussed with the customer.
For example – normal requirements for a result management system may be the entry of marks, calculation of
results, etc.
 Expected requirements – These requirements are so apparent that the customer need not explicitly state them: for
example – protection from unauthorized access.
 Exciting requirements – It includes features beyond customers' expectations and proves to be very satisfying when
present. For example – when unauthorized access is detected, it should back up and shut down all processes.
The significant steps involved in this procedure are –
1. Identify all the stakeholders, e.g., Users, developers, customers, etc
2. List out all requirements from the customer.
3. The degree of importance is given to every requirement.
4. In the end, the final list of requirements is divided as –
 It is possible to attain.
 It should be deferred, and the reason for it.
 It is not possible to achieve and should be dropped off.
5. Use Case Approach:
In this technique, text and pictures are combined to understand the requirements better.
The use cases describe the 'what' of a system and not 'how .' Therefore, they only give a functional view of the system.
The components of the use case design include three major things – Actor, Use cases, use case diagram.
1. Actor – It is an external agent that lies outside the system but interacts with it somehow. An actor, maybe a person, a
machine, etc. It is shown as a stick figure. Actors may be primary actors or secondary actors.
 Primary actors – They require assistance from the system to accomplish a goal.
 Secondary actor – The system demands assistance from secondary actors.
1. Use cases – It describes the sequence of interactions between the system and actors. It captures who(actors) do
what(interaction) with the system. A set of Use cases specifies all possible ways to use the system.
2. Use case diagram – A use case diagram represents what happens when an actor graphically interacts with a
system. It has the functional side of the system.
 A Stick figure is used to show an actor.
 Oval is used to show the use case.
  A line represents a relationship between an actor and a use case.
We have discussed methods of requirement elicitation. Now let’s move to FAQ Section to clear your doubts.

FAQs
1. What is the need for requirement analysis?
Determining the needs or conditions to meet for a new or altered product or project, taking account of the possibility.
Conflicting requirements of the stakeholders, analyzing, documenting, validating, and managing software or system
requirements.
We need the requirement analysis for all the activities that have been mentioned before.

2. Why is requirements elicitation essential?

Elicitation is essential as many stakeholders cannot articulate the business problem accurately. Therefore, analysts
performing the elicitation need to ensure that the requirements are understandable, helpful, and relevant.

3. Why is requirement elicitation difficult?

Sometimes, Stakeholders or users cannot specify or mention what they want or their requirements. They sometimes
expect or demand unrealistic requirements that cannot be fulfilled. Therefore, it becomes challenging to meet the
expectations of the users.

4. What are the common problems encountered during requirements elicitation?

Conflicting requirements, unspoken or assumed requirements, difficulty in meeting with relevant stakeholders,
stakeholder resistance to change, and not enough time set for meeting with all stakeholders are general challenges
during requirements elicitation.

5. What are the types of requirements?

The main types of requirements are Functional Requirements, Performance Requirements, System Technical
Requirements, Specifications.
Requirements Analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity
reviews all requirements and may provide a graphical view of the entire system. After the completion of
the analysis, it is expected that the understandability of the project may improve significantly. Here, we
may also use the interaction with the customer to clarify points of confusion and to understand which
requirements are more important than others.

The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries and
interfaces of the proposed systems with the external world. It identifies the entities outside the proposed
system that interact with the system. The context diagram of student result management system is given
below:
(ii) Development of a Prototype (optional): One effective way to find out what the customer wants is
to construct a prototype, something that looks and preferably acts as part of the system they say they
want.

We can use their feedback to modify the prototype until the customer is satisfied continuously. Hence, the
prototype helps the client to visualize the proposed system and increase the understanding of the
requirements. When developers and users are not sure about some of the elements, a prototype may help
both the parties to take a final decision.

Some projects are developed for the general market. In such cases, the prototype should be shown to
some representative sample of the population of potential purchasers. Even though a person who tries out
a prototype may not buy the final system, but their feedback may allow us to make the product more
attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have limitations and
would not be acceptable in the final system. This is an optional activity.
(iii) Model the requirements: This process usually consists of various graphical representations of the
functions, data entities, external entities, and the relationships between them. The graphical view may
help to find incorrect, inconsistent, missing, and superfluous requirements. Such models include the Data
Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better understanding of
the system behavior. The inconsistencies and ambiguities have been identified and corrected. The flow of
data amongst various modules has been analyzed. Elicitation and analyze activities have provided better
insight into the system. Now we finalize the analyzed requirements, and the next step is to document
these requirements in a prescribed format.
Data Flow Diagrams
A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where
data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a
part in the order that acts as a starting point for redesigning a system. The DFD is also
called as a data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of
events; arrows in DFD represents flowing data. A DFD does not involve any order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD,
suppress that urge! A diamond-shaped box is used in flow charts to represents decision
points with multiple exists paths of which the only one is taken. This implies an ordering of
events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling until the
end of the analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data
store indicates that the data is stored which can be used at a later stage or by the other
processes in a different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs
or sink of system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily
three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.

0-level DFDM

It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by incoming
and outgoing arrows. Then the system is decomposed and described as a DFD with
multiple bubbles. Parts of the system represented by each of these bubbles are then
decomposed and documented as more and more detailed DFDs. This process may be
repeated at as many levels as necessary until the program at hand is well understood. It is
essential to preserve the number of inputs and outputs between levels, this concept is
called leveling by DeMacro. Thus, if bubble "A" has two inputs x 1 and x2 and one output y,
then the expanded DFD, that represents "A" should have exactly two external inputs and
one external output as shown in fig:
The Level-0 DFD, also called context diagram of the result management system is shown in
fig. As the bubbles are decomposed into less and less abstract bubbles, the corresponding
data flow may also be needed to be decomposed.
1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this

level, we highlight the main objectives of the system and breakdown the high-level process
of 0-level DFD into subprocesses.

2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or
record the specific/necessary detail about the system's functioning.
What is requirements analysis (requirements engineering)?
Requirements analysis (requirements engineering) is the process of determining user expectations for a new or
modified product. It is usually a team effort and demands a variety of human soft skills, such as critical thinking,
communication and judgment.
Requirements analysis is a common and essential concept in software development and software project management.
At the start of every software project, the project team must understand, finalize and document the features and
functionalities required of the end product. These required features and functionalities are often called functional
specifications, and the process of determining and understanding them is called requirements gathering and analysis.

Requirements must be quantifiable, as detailed as possible and relevant to the end product. In addition, they should be
clearly documented so the development team has clear expectations and understands required specifications from the
beginning.

Requirements analysis in software engineering does the following:

 Clarifies the required features and overall vision of a new product.

 Clarifies stakeholder expectations for that product.

 Prevents conflict and communication gaps during development and testing.

 Ensures that the final product conforms to requirements, i.e., prevents scope creep.
 Requirements analysis is an important concept in
software development.
The importance of communication during requirements analysis
During requirements analysis, project team members come together to understand the project goals, clarify expectations
and document the product's required specifications and features. All of this requires clear and unambiguous
communication between team members.

When gathering requirements, the project team should also communicate with other stakeholders, such as the project
owner and end users, to determine their expectations regarding specific features. Early and frequent discussions
between these parties help to prevent ambiguity. It ensures that the final product conforms to the end user's or client's
needs and avoids forcing users to adjust their expectations.
Requirements analysis and feature creep
Requirements analysis and clear communication help to prevent feature creep in software projects. Also known
as scope creep, feature creep refers to the addition of excessive features to a product, which often makes it overly
complex and difficult to use.

Feature creep is usually the result of poor planning, insufficient communication, inadequate requirements analysis and
poor understanding of requirements by the team. It complicates product design, undermines its value and can
eventually make it unusable for end users. To avoid such problems, project teams must gather, understand and analyze
the product's requirements before development begins.

Requirements analysis process

Requirements analysis is a multistage process that involves the following steps.

1. Understand the key stakeholders and end users

In any project, the key stakeholders, including end users, generally have final say on the project scope. Project teams
should identify them early and involve them in the requirements gathering process from the beginning.

2. Understand the project goal

To capture all necessary requirements, project teams must first understand the project's objective. What business need
drives the project? What problem is the product meant to solve? By understanding the desired end, the project team can
define the problem statement and have more productive discussions when gathering requirements.
3. Capture requirements

At this stage, all relevant stakeholders provide requirements. This can be done through one-on-one interviews, focus
groups or consideration of use cases. Project teams gather stakeholder feedback and incorporate it into requirements.

4. Categorize requirements

Categorization of requirements can help with prioritization, impact analysis, feasibility analysis and conflict resolution.
Four common requirements categories are the following:

1. Functional requirements.

2. Technical requirements.

3. Transitional requirements.

4. Operational requirements.

5. Interpret and document requirements

Post-categorization, the project team should analyze its set of requirements to determine which ones are feasible.
Interpretation and analysis are easier when requirements are well defined and clearly worded. Each requirement should
have a clear and understood impact on the end product and the project plan. After all the requirements have been
identified, prioritized and analyzed, project teams should document them in the software requirements specification
(SRS).
6. Finalize SRS and get sign-off on requirements

The SRS should be shared with key stakeholders for sign-off to ensure that they agree with the requirements. This helps
prevent conflicts or disagreements later. Feedback, if any, should be incorporated. The SRS can then be finalized and
made available to the entire development team. This document provides the foundation for the project's scope and
guides other steps during the software development lifecycle (SDLC), including development and testing.
 The software development lifecycle (SDLC)

Context diagram and prototypes in requirements engineering

A context diagram is a visual model that shows the various interfaces and boundaries of the end product with the
external world. In other words, the diagram shows how the external world and product elements should interact with
and impact one another.

A prototype can help teams to convert intangible requirements into a tangible form. By developing a prototype and
showing it to end users -- or, more practically, a selection of end users -- the team can gather user feedback and
understand what requirements it lacks. Then, it can incorporate feedback to improve the prototype and use it to create
an end product that appropriately reflects user requirements and expectations.

Popular tools used in requirements engineering

Modern development teams can choose from a number of tools to help them analyze and finalize requirements. These
include the following:

 Business Process Model and Notation (BPMN). BPMN enables project teams to create a standardized graphical
representation of processes and coordinate communications between participants in that process.

 Flowcharts. Whether simple or complex, flowcharts can show the relationships between activities in an intuitive
way, which can provide clarity of understanding and simplify communication as the project progresses.

 Gantt charts. Gantt charts help with project planning and -- to some extent -- with requirements analysis. A Gannt
chart visually represents various tasks and scheduled timelines, complete with start and end dates.

 Gap analysis. Gap analysis helps project managers and teams to evaluate a product's performance and compare it
against its requirements.
What is Requirements Analysis?

Requirements analysis or requirements engineering is a process used to determine the needs and expectations of a new product. It
involves frequent communication with the stakeholders and end-users of the product to define expectations, resolve conflicts, and
document all the key requirements.

One of the greatest challenges faced by any organization is to share the vision of the final product with the customers. Hence,
a business requirements analysis involves a team effort of all the key stakeholders, software developers, end-users, and customer
managers to achieve a shared understanding of what the product should do. This is always done in the early phase of any project to
ensure that the final product conforms to all the requirements.

Requirements Analysis Process

A requirements analysis process involves the following steps:

Step 1: Identify Key Stakeholders and End-Users

The first step of the requirements analysis process is to identify key stakeholders who are the main sponsors of the project. They will
have the final say on what should be included in the scope of the project.

Next, identify the end-users of the product. Since the product is intended to satisfy their needs, their inputs are equally important.
Step 2: Capture Requirements

Ask each of the stakeholders and end-users their requirements for the new product. Here are some requirements analysis techniques
that you can use to capture requirements:

1. Hold One-On-One Interviews

Interview each stakeholder and end-user individually. This technique will help you gather specific requirements.

2. Use Focus Groups

Conduct group interviews or group workshops to understand the flow of information between different stakeholders and end-users.
This technique will ensure that there will be no conflict of interest later on during the project.

3. Utilize Use Cases

Use cases provide a walkthrough of the entire product through the eyes of the end-user. This technique will help visualize how the
product will actually work.

4. Build Prototypes

A prototype provides users a sample look and feel of the final product. This technique will help address feasibility issues and identify
problems ahead of time.

Step 3: Categorize Requirements

Since requirements can be of various types, they should be grouped to avoid confusion. Requirements are usually divided into four
categories:

 Functional Requirements: Functions the product is required to perform.

 Technical Requirements: Technical issues to be considered for the successful implementation of the product.

 Transitional Requirements: Steps required to implement a new product smoothly.

 Operational Requirements: Operations to be carried out in the backend for proper functioning of the product.

Step 4: Interpret and Record Requirements

Once the requirements are categorized, determine which requirements are actually achievable and document each one of them. Here
are some techniques to analyze and interpret requirements:

Define Requirements Precisely

Ensure that the requirements are clearly worded, sufficiently detailed, and related to business needs.

Prioritize Requirements

Prioritize requirements and list them out based on which ones are the “most critical” and which ones are just “nice-to-have”.

Carry Out an Impact Analysis

Carry out an impact analysis to make sure that you fully understand the consequences of the requirements.

Resolve Conflicts

Arrange a meeting with key stakeholders and resolve conflicting requirements. You can also perform a scenario analysis to explore
how the requirements would work for different possible scenarios.
Analyze Feasibility

Perform a detailed analysis of the product based on the requirements gathered to determine its reliability and to identify any major
problems.

Once all the requirements are analyzed, create a detailed written document and circulate it among the key stakeholders, end-users and
development teams.

Step 5: Sign off

Once a final decision is made on the requirements, ensure that you get a signed agreement from the key stakeholders. This is done to
ensure that there are no changes or uncontrolled growth in the scope of the project.

Stages of Requirement Analysis

1. Drawing the Context Diagram

The purpose of drawing a context diagram is to find out how to design a new system within an organization or how to modify it.
Context diagram defines how external elements impact the internal system of an organization. They are complex diagrams that draw
the system analysis simply yet crisply. The arrows indicate the date-flow between the external elements and the internal system. For
example, the following diagram shows how different elements move within the hotel reservation system.

2. Developing a Prototype (Optional)

Prototype development is an important part of a product launch as this helps the organization find out the specific requirements of
customers. Based on the customers' response, the prototype is modified until it achieves maximum customer satisfaction. The
prototype allows the client to imagine the system to be built and to understand the customer's requirements. If the developers and end
users still need to catch up on some aspects of the system, the prototype or the replica of the product helps them to finalize those
elements.

Those products that are developed for the general masses should get a glimpse of the prototype. Then, it should be shown to a selected
section of potential buyers. This will help to create a product more attractive than before.

The prototype is usually created faster and at an affordable cost. However, it always comes with some limitations and is not accepted
in the final analysis.

3. Modeling the Requirements

This stage involves creating requirement models that ultimately allow customers and stakeholders to imagine the product in the
making. Various functions, data tables, external elements, and their relation to each other are represented in graphical forms. A
graphical viewing of these things assists in finding flaws in the requirements. It allows the developers to see if there are any
inconsistencies, missing, wrong, or unnecessary elements added to the system. Such requirement models can be divided into the
following categories.

 Data Flow Diagram: A graphical preparation using symbols and notations to show how a business operates through data movement.

 Entity-Relationship diagram: A flowchart describing how things like people, a concept, or an object are related within a system.

 Data Dictionaries: These contain different definitions, names, and other forms of data elements utilized within the project.

 State-transition diagrams: They represent the changes that take place within the system

4. Finalize the Requirements

Requirement models will add to the understanding of the system. All the necessary corrections are done at this stage. All ambiguities
are removed, and the data flow is examined across various models. The elicitation process and subsequent analysis lead to a greater
understanding of the system. So finally, the requirements are approved, and the documentation begins.
 Data Dictionaries in Software Engineering




Data Dictionary is the major component in the structured analysis model of the system. It lists all
the data items appearing in DFD. A data dictionary in Software Engineering means a file or a set of
files that includes a database’s metadata (hold records about other objects in the database), like
data ownership, relationships of the data to another object, and some other data.
Example a data dictionary entry: GrossPay = regular pay + overtime pay
Case Tools is used to maintain data dictionary as it captures the data items appearing in a DFD
automatically to generate the data dictionary.

Components of Data Dictionary:

In Software Engineering, the data dictionary contains the following information:

 Name of the item: It can be your choice.
 Aliases: It represents another name.
 Description: Description of what the actual text is all about.
 Related data items: with other data items.
 Range of values: It will represent all possible answers.

Features of Data Dictionary :

Here, we will discuss some features of the data dictionary as follows.

 It helps in designing test cases and designing the software.
 It is very important for creating an order list from a subset of the items list.
 It is very important for creating an order list from a complete items list.
 The data dictionary is also important to find the specific data item object from the list.

Uses of Data Dictionary :

Here, we will discuss some use cases of the data dictionary as follows.
 Used for creating the ordered list of data items
 Used for creating the ordered list of a subset of the data items
 Used for Designing and testing software in Software Engineering
 Used for finding data items from a description in Software Engineering

Importance of Data Dictionary:

 It provides developers with standard terminology for all data.

 It provides developers to use different terms to refer to the same data.
 It provides definitions for different data
 Query handling is facilitated if a data dictionary is used in RDMS.

Advantages of Data Dictionary:

 Consistency and Standardization: A data dictionary helps to ensure that all data elements
and attributes are consistently defined and named across the organization, promoting
standardization and consistency in data management practices.
 Data Quality: A data dictionary can help improve data quality by providing a single source of
truth for data definitions, allowing users to easily verify the accuracy and completeness of data.
 Data Integration: A data dictionary can facilitate data integration efforts by providing a
common language and framework for understanding data elements and their relationships
across different systems.
 Improved Collaboration: A data dictionary can help promote collaboration between business
and technical teams by providing a shared understanding of data definitions and structures,
reducing misunderstandings and communication gaps.
 Improved Efficiency: A data dictionary can help improve efficiency by reducing the time and
effort required to define, document, and manage data elements and attributes.
Disadvantages of Data Dictionary:
 Implementation and Maintenance Costs: Implementing and maintaining a data dictionary
can be costly, requiring significant resources in terms of time, money, and personnel.
 Complexity: A data dictionary can be complex and difficult to manage, particularly in large
organizations with multiple systems and data sources.
 Resistance to Change: Some stakeholders may be resistant to using a data dictionary, either
due to a lack of understanding or because they prefer to use their own terminology or
definitions.
 Data Security: A data dictionary can contain sensitive information, and therefore, proper
security measures must be in place to ensure that unauthorized users do not access or modify
the data.
 Data Governance: A data dictionary requires strong data governance practices to ensure that
data elements and attributes are managed effectively and consistently across the organization.

Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a conceptual data model
of an information system. Diagrams created using this ER-modeling method are called Entity-Relationship
Diagrams or ER diagrams or ERDs.

Purpose of ERD
 o The database analyst gains a better understanding of the data to be contained in the database through the
step of constructing the ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In particular, the ERD
effectively communicates the logic of the database to users.

Components of an ER Diagrams

1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An entity
is denoted as a rectangle in an ER diagram. For example, in a school database, students, teachers, classes,
and courses offered can be treated as entities. All these entities have some attributes or properties that
give them their identity.

Entity Set

An entity set is a collection of related types of entities. An entity set may include entities with attribute
sharing similar values. For example, a Student set may contain all the students of a school; likewise, a
Teacher set may include all the teachers of a school from all faculties. Entity set need not be disjoint.
2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values. For example,
a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a student's
name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.

There are four types of Attributes:

1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute

1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among
the entity set. For example, the roll_number of a student makes him identifiable among students.

There are mainly three types of keys:

1. Super key: A set of attributes that collectively identifies an entity in the entity set.
 2. Candidate key: A minimal super key is known as a candidate key. An entity set may have more than one
candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by the database designer to uniquely
identify the entity set.

2. Composite attribute: An attribute that is a combination of other attributes is called a composite

attribute. For example, In student entity, the student address is a composite attribute as an address is
composed of other characteristics such as pin code, state, country.

3. Single-valued attribute: Single-valued attribute contain a single value. For example,

Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a multi-valued
attribute. Multi-valued attributes are depicted by the double ellipse. For example, a person can have more
than one phone number, email-address, etc.

5. Derived attribute: Derived attributes are the attribute that does not exist in the physical database,
but their values are derived from other attributes present in the database. For example, age can be
derived from date_of_birth. In the ER diagram, Derived attributes are depicted by the dashed ellipse.
3. Relationships
The association among entities is known as relationship. Relationships are represented by the diamond-
shaped box. For example, an employee works_at a department, a student enrolls in a course. Here,
Works_at and Enrolls are called relationships.

Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a relationship too can
have attributes. These attributes are called descriptive attributes.

Degree of a relationship set

The number of participating entities in a relationship describes the degree of the relationship. The three
most common relationships in E-R models are:

1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)
1. Unary relationship: This is also called recursive relationships. It is a relationship between the
instances of one entity type. For example, one person is married to only one person.

2. Binary relationship: It is a relationship between the instances of two entity types. For example, the
Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the
relationships "may have" provide the association of three entities, i.e., TEACHER, STUDENT, and SUBJECT.
All three entities are many-to-many participants. There may be one or many participants in a ternary
relationship.

In general, "n" entities can be related by the same relationship and is known as n-ary relationship.
Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the number of
entities of other sets via relationship set.

Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity set B and
vice versa. Let us assume that each student has only one student ID, and each student ID is assigned to
only one person. So, the relationship will be one to one.
Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one instances of
another entity then it is called one to many relationships. For example, a client can place many orders; a
order cannot be placed by many customers.
Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated with at most one entity of
entity set B, however an entity from entity set B can be associated with more than one entity from entity
set A. For example - many students can study in a single college, but a student cannot study in many
colleges at the same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one entity from B and vice-versa.
For example, the student can be assigned to many projects, and a project can be assigned to many
students.

Using Sets, it can be represented as:

 Unified Modeling Language (UML) Diagrams


Unified Modeling Language (UML) is a general-purpose modeling language. The main aim of
UML is to define a standard way to visualize the way a system has been designed. It is quite
similar to blueprints used in other fields of engineering. UML is not a programming language, it
is rather a visual language.
 We use UML diagrams to portray the behavior and structure of a system.
 UML helps software engineers, businessmen, and system architects with modeling, design, and
analysis.
 The Object Management Group (OMG) adopted Unified Modelling Language as a standard in
1997. It’s been managed by OMG ever since.
 The International Organization for Standardization (ISO) published UML as an approved
standard in 2005. UML has been revised over the years and is reviewed periodically.

1. Why do we need UML?

 Complex applications need collaboration and planning from multiple teams and hence require a
clear and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to communicate with non-
programmers about essential requirements, functionalities, and processes of the system.
 A lot of time is saved down the line when teams can visualize processes, user interactions, and
the static structure of the system.
2. Different Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:

3. Structural UML Diagrams

3.1. Class Diagram
The most widely use UML diagram is the class diagram. It is the building block of all object
oriented software systems. We use class diagrams to depict the static structure of a system by
showing system’s classes, their methods and attributes. Class diagrams also help us identify
relationship between different classes or objects.
3.2. Composite Structure Diagram
We use composite structure diagrams to represent the internal structure of a class and its
interaction points with other parts of the system.
 A composite structure diagram represents relationship between parts and their configuration
which determine how the classifier (class, a component, or a deployment node) behaves.
 They represent internal structure of a structured classifier making the use of parts, ports, and
connectors.
 We can also model collaborations using composite structure diagrams.
 They are similar to class diagrams except they represent individual parts in detail as compared
to the entire class.
3.3. Object Diagram
An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects have
been instantiated, we are able to study the behaviour of the system at a particular instant.
 An object diagram is similar to a class diagram except it shows the instances of classes in the
system.
 We depict actual classifiers and their relationships making the use of class diagrams.
 On the other hand, an Object Diagram represents specific instances of classes and relationships
between them at a point of time.
3.4. Component Diagram
Component diagrams are used to represent how the physical components in a system have been
organized. We use them for modelling implementation details.
 Component Diagrams depict the structural relationship between software system elements and
help us in understanding if functional requirements have been covered by planned
development.
 Component Diagrams become essential to use when we design and build complex systems.
 Interfaces are used by components of the system to communicate with each other.
3.5. Deployment Diagram
Deployment Diagrams are used to represent system hardware and its software.It tells us what
hardware components exist and what software components run on them.
 We illustrate system architecture as distribution of software artifacts over distributed targets.
 An artifact is the information that is generated by system software.
 They are primarily used when a software is being used, distributed or deployed over multiple
machines with different configurations.
3.6. Package Diagram
We use Package Diagrams to depict how packages and their elements have been organized. A
package diagram simply shows us the dependencies between different packages and internal
composition of packages.
 Packages help us to organise UML diagrams into meaningful groups and make the diagram easy
to understand.
 They are primarily used to organise class and use case diagrams.
4. Behavioral UML Diagrams
4.1. State Machine Diagrams
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions.
 State diagrams are also referred to as State machines and State-chart Diagrams .
 These terms are often used interchangeably. So simply, a state diagram is used to model the
dynamic behavior of a class in response to time and changing external stimuli.
4.2. Activity Diagrams
We use Activity Diagrams to illustrate the flow of control in a system. We can also use an activity
diagram to refer to the steps involved in the execution of a use case.
 We model sequential and concurrent activities using activity diagrams. So, we basically depict
workflows visually using an activity diagram.
 An activity diagram focuses on condition of flow and the sequence in which it happens.
 We describe or depict what causes a particular event using an activity diagram.
4.3. Use Case Diagrams
Use Case Diagrams are used to depict the functionality of a system or a part of a system. They are
widely used to illustrate the functional requirements of the system and its interaction with external
agents(actors).
 A use case is basically a diagram representing different scenarios where the system can be
used.
 A use case diagram gives us a high level view of what the system or a part of the system does
without going into implementation details.
4.4. Sequence Diagram
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order
in which these interactions take place.
 We can also use the terms event diagrams or event scenarios to refer to a sequence diagram.
 Sequence diagrams describe how and in what order the objects in a system function.
 These diagrams are widely used by businessmen and software developers to document and
understand requirements for new and existing systems.
4.5. Communication Diagram
A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used to show
sequenced messages exchanged between objects.
 A communication diagram focuses primarily on objects and their relationships.
 We can represent similar information using Sequence diagrams, however communication
diagrams represent objects and links in a free form.
4.6. Timing Diagram
Timing Diagram are a special form of Sequence diagrams which are used to depict the behavior of
objects over a time frame. We use them to show time and duration constraints which govern
changes in states and behavior of objects.
4.7. Interaction Overview Diagram
An Interaction Overview Diagram models a sequence of actions and helps us simplify complex
interactions into simpler occurrences. It is a mixture of activity and sequence diagrams.
6. Tools for creating UML Diagrams
There are several tools available for creating Unified Modeling Language (UML) diagrams, which
are commonly used in software development to visually represent system architecture, design,
and implementation. Here are some popular UML diagram creating tools:
 Lucidchart:
 Lucidchart is a web-based diagramming tool that supports UML diagrams. It’s user-
friendly and collaborative, allowing multiple users to work on diagrams in real-time.
 Draw.io:
 Draw.io is a free, web-based diagramming tool that supports various diagram types,
including UML. It integrates with various cloud storage services and can be used offline.
 Visual Paradigm:
 Visual Paradigm provides a comprehensive suite of tools for software development,
including UML diagramming. It offers both online and desktop versions and supports a
wide range of UML diagrams.
 StarUML:
 StarUML is an open-source UML modeling tool with a user-friendly interface. It supports
the standard UML 2.x diagrams and allows users to customize and extend its
functionality through plugins.
 Papyrus:
 Papyrus is an open-source UML modeling tool that is part of the Eclipse Modeling
Project. It provides a customizable environment for creating, editing, and visualizing
UML diagrams.
 PlantUML:
  PlantUML is a text-based tool that allows you to create UML diagrams using a simple
and human-readable syntax. It’s often used in conjunction with other tools and
supports a variety of diagram types.
7. Steps to create UML Diagrams

Creating Unified Modeling Language (UML) diagrams involves a systematic process that typically
includes the following steps:
1. Identify the Purpose:
 Determine the purpose of creating the UML diagram. Different types of UML diagrams serve
various purposes, such as capturing requirements, designing system architecture, or
documenting class relationships.
2. Identify Elements and Relationships:
 Identify the key elements (classes, objects, use cases, etc.) and their relationships that need
to be represented in the diagram. This step involves understanding the structure and
behavior of the system you are modeling.
3. Select the Appropriate UML Diagram Type:
 Choose the UML diagram type that best fits your modeling needs. Common types include
Class Diagrams, Use Case Diagrams, Sequence Diagrams, Activity Diagrams, and more.
4. Create a Rough Sketch:
 Before using a UML modeling tool, it can be helpful to create a rough sketch on paper or a
whiteboard. This can help you visualize the layout and connections between elements.
5. Choose a UML Modeling Tool:
 Select a UML modeling tool that suits your preferences and requirements. There are various
tools available, both online and offline, that offer features for creating and editing UML
diagrams.
6. Create the Diagram:
 Open the selected UML modeling tool and create a new project or diagram. Begin adding
elements (e.g., classes, use cases, actors) to the diagram and connect them with appropriate
relationships (e.g., associations, dependencies).
7. Define Element Properties:
 For each element in the diagram, specify relevant properties and attributes. This might
include class attributes and methods, use case details, or any other information specific to
the diagram type.
8. Add Annotations and Comments:
 Enhance the clarity of your diagram by adding annotations, comments, and explanatory
notes. This helps anyone reviewing the diagram to understand the design decisions and logic
behind it.
9. Validate and Review:
 Review the diagram for accuracy and completeness. Ensure that the relationships,
constraints, and elements accurately represent the intended system or process. Validate
your diagram against the requirements and make necessary adjustments.
10. Refine and Iterate:
 Refine the diagram based on feedback and additional insights. UML diagrams are often
created iteratively as the understanding of the system evolves.
11. Generate Documentation:
 Some UML tools allow you to generate documentation directly from your diagrams. This can
include class documentation, use case descriptions, and other relevant information.

10. Common Challenges in UML Modeling:

1. Time-Intensive:
 UML modeling can be perceived as time-consuming, especially in fast-paced .Teams may
struggle to keep up with the need for frequent updates to UML diagrams.
2. Over-Documentation:
 There’s a risk of over-documentation when using UML, as teams may spend too much time
on detailed diagrams that do not directly contribute to delivering value.
3. Changing Requirements:
 UML diagrams may become quickly outdated. Keeping up with these changes and ensuring
that UML models reflect the current system state can be challenging.
4. Collaboration Issues:
 UML diagrams are seen as artifacts that only certain team members understand. Ensuring
that everyone can contribute to and benefit from UML models can be a challenge.
10.1. UML Limitations:
1. Lean Documentation:
 Focus on lean documentation. Instead of creating extensive UML diagrams, consider creating
just enough documentation to support the understanding and maintenance of the code. Use
tools that allow for quick updates.
2. Iterative Modeling:
  Adopt an iterative approach to UML modeling. Instead of trying to create comprehensive
models upfront, update and refine UML diagrams iteratively as the understanding of the
system evolves.
3. Regular Reviews:
 Regularly review and validate UML models with the team. This helps identify discrepancies
between the models and the actual code, ensuring that the UML diagrams remain relevant.
4. Use Collaborative Tools:
 Utilize collaborative UML modeling tools that support real-time updates and encourage team
members to contribute. This promotes collaboration and helps distribute the responsibility of
maintaining UML models.

11. Advantages of Using UML Diagrams

1. Standardization:
 UML provides a standardized way of representing system models, ensuring that developers
and stakeholders can communicate using a common visual language.
2. Communication:
 UML diagrams serve as a powerful communication tool between stakeholders, including
developers, designers, testers, and business users. They help in conveying complex ideas in
a more understandable manner.
3. Visualization:
 UML diagrams facilitate the visualization of system components, relationships, and
processes. This visual representation aids in understanding and designing complex systems.
4. Documentation:
 UML diagrams can be used as effective documentation tools. They provide a structured and
organized way to document various aspects of a system, such as architecture, design, and
behavior.
5. Analysis and Design:
  UML supports both analysis and design phases of software development. It helps in modeling
the requirements of a system and then transforming them into a design that can be
implemented.
12. Disadvantages of using UML Diagrams
1. Complexity:
 UML can be complex, especially for beginners. Learning all the aspects of UML and becoming
proficient in using it may require a significant investment of time and effort.
2. Overhead:
 In some cases, creating and maintaining detailed UML diagrams can be time-consuming. For
small and simple projects, the overhead of creating extensive UML documentation may not
be justified.
3. Ambiguity:
 Interpretation of UML diagrams can be subjective, leading to potential ambiguity. Different
individuals may interpret the same diagram in slightly different ways, causing confusion.
4. Learning Curve:
 Due to its extensive features and diagrams, there is a steep learning curve associated with
UML. Teams may need training and experience to use it effectively.
5. Over-Modeling or Under-Modeling:
 There is a risk of over-modeling (creating too many unnecessary details) or under-modeling
(omitting important details) in UML diagrams. Striking the right balance is crucial for their
effectiveness.

What is a Class Diagram?

The class diagram is a central modeling technique that runs through nearly all object-oriented methods. This
diagram describes the types of objects in the system and various kinds of static relationships which exist between
them.
Relationships
There are three principal kinds of relationships which are important:
1. Association - represent relationships between instances of types (a person works for a company, a company
has a number of offices.
2. Inheritance - the most obvious addition to ER diagrams for use in OO. It has an immediate correspondence
to inheritance in OO design.
3. Aggregation - Aggregation, a form of object composition in object-oriented design.
Class Diagram Example
EXAMPLE: BANKING SYSTEM
What Is a Software Requirements Specification (SRS) Document?
A software requirements specification (SRS) is a document that describes what the software will do and how it will be
expected to perform. It also describes the functionality the product needs to fulfill the needs of all stakeholders (business,
users).

You can think of an SRS as a blueprint or roadmap for the software you're going to build. The elements that comprise an
SRS can be simply summarized into four Ds:

 Define your product's purpose.

 Describe what you're building.
 Detail the requirements.
 Deliver it for approval.

We want to DEFINE the purpose of our product, DESCRIBE what we are building, DETAIL the individual requirements,
and DELIVER it for approval. A good SRS document will define everything from how software will interact when
embedded in hardware to the expectations when connected to other software. An even better SRS document also
accounts for the needs of real-life users and human interaction.

Why Use an SRS Document?

An SRS gives you a complete picture of your entire project. It provides a single source of truth that every team involved in
development will follow. It is your plan of action and keeps all your teams — from development and testing to
maintenance — on the same page.

An SRS not only keeps your teams aligned and working toward a common vision of the product, it also helps ensure that
each requirement is met. It can ultimately help you make vital decisions on your product’s lifecycle, such as when to retire
an obsolete feature.

It takes time and careful consideration to create a proper SRS. But the effort it takes to write an SRS is gained back in the
development phase. It helps your team better understand your product, the business needs it serves, its users, and the
time it will take to complete.
Software Requirements Specification vs. System Requirements Specification

What is the difference between a software requirements specification document and a system requirements specification
document?

“Software” and “system” are sometimes used interchangeably as SRS. But, a software requirements specification
provides greater detail than a system requirements specification.

A system requirements specification (abbreviated as SyRS to differentiate from SRS) presents general information
on the requirements of a system, which may include both hardware and software, based on an analysis of business
needs.

A software requirements specification (SRS) details the specific requirements of the software that is to be developed.

How to Write an SRS Document

Creating a clear and effective SRS document can be difficult and time-consuming. But it is critical to the efficient
development of a high quality product that meets the needs of business users.

Here are five steps you can follow to write an effective SRS document.

1. Define the Purpose With an Outline (Or Use an SRS Template)

Your first step is to create an outline for your software requirements specification. This may be something you create
yourself, or you can use an existing SRS template.

If you’re creating the outline yourself, here’s what it might look like:

1. Introduction

1.1 Purpose
 1.2 Intended Audience

1.3 Intended Use

1.4 Product Scope

1.5 Definitions and Acronyms

2. Overall Description

2.1 User Needs

2.2 Assumptions and Dependencies

3. System Features and Requirements

3.1 Functional Requirements

3.2 External Interface Requirements

3.3 System Features

3.4 Nonfunctional Requirements

2. Define your Product’s Purpose

This introduction is very important as it sets expectations that we will come back to throughout the SRS.

Some items to keep in mind when defining this purpose include:

Intended Audience and Intended Use

Define who in your organization will have access to the SRS and how they should use it. This may include developers,
testers, and project managers. It could also include stakeholders in other departments, including leadership teams, sales,
and marketing. Defining this now will lead to less work in the future.

Product Scope

What are the benefits, objectives, and goals we intend to have for this product? This should relate to overall business
goals, especially if teams outside of development will have access to the SRS.

Definitions and Acronyms

Clearly define all key terms, acronyms, and abbreviations used in the SRS. This will help eliminate any ambiguity and
ensure that all parties can easily understand the document.

If your project contains a large quantity of industry-specific or ambiguous terminology or acronyms, you may want to
consider including a reference to a project glossary, to be appended to the SRS, in this section.

3. Describe What You Will Build

Your next step is to give a description of what you’re going to build. Why is this product needed? Who is it for? Is it a new
product? Is it an add-on to a product you’ve already created? Is this going to integrate with another product?

Understanding and getting your team aligned on the answers to these questions on the front end makes creating the
product much easier and more efficient for everyone involved.

User Needs

Describe who will use the product and how. Understanding the various users of the product and their needs is a critical
part of the SRS writing process.
Who will be using the product? Are they a primary or secondary user? What is their role within their organization? What
need does the product need to fulfill for them?

Do you need to know about the purchaser of the product as well as the end user? For the development of medical devices
and med device software, you may also need to know the needs of the patient.

Assumptions and Dependencies

What are we assuming will be true? Understating and laying out these assumptions ahead of time will help with
headaches later. Are we assuming current technology? Are we basing this on a Windows framework? We need to take
stock of these technical assumptions to better understand where our product might fail or not operate perfectly.

Finally, you should note if your project is dependent on any external factors. Are we reusing a bit of software from a
previous project? This new project would then depend on that operating correctly and should be included.

4. Detail Your Specific Requirements

In order for your development team to meet the requirements properly, we must include as much detail as possible. This
can feel overwhelming but becomes easier as you break down your requirements into categories. Some common
categories are functional requirements, interface requirements, system features, and various types of nonfunctional
requirements:

Functional Requirements

Functional requirements are essential to your product because, as the name implies, they provide some sort of
functionality.
Asking yourself questions such as “does this add to my tool’s functionality?” or “what function does this provide?” can help
with this process. Within medical devices especially, these functional requirements may have a subset of domain-specific
requirements.

You may also have requirements that outline how your software will interact with other tools, which brings us to external
interface requirements.

External Interface Requirements

External interface requirements are specific types of functional requirements. These are especially important when
working with embedded systems. They outline how your product will interface with other components.

There are several types of interfaces you may have requirements for, including:

 User
 Hardware
 Software
 Communications
System Features

System features are a type of functional requirements. These are features that are required in order for a system to
function.

Nonfunctional Requirements

Nonfunctional requirements, which help ensure that a product will work the way users and other stakeholders expect it to,
can be just as important as functional ones.

These may include:

 Performance requirements
 Safety requirements
 Security requirements
 Usability requirements
  Scalability requirements

The importance of each of these types of nonfunctional requirements may vary depending on your industry. In industries
such as medical device, life sciences, and automotive, there are often regulations that require the tracking and accounting
of safety.

5. Deliver for Approval

We made it! After completing the SRS, you’ll need to get it approved by key stakeholders. This will require everyone to
review the latest version of the document.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS is
said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all available
categories of situations.
Note: It is essential to specify the responses to both valid and invalid values.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all terms
and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in its
conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in another as
textual.

(b) One condition may state that all lights shall be green while another states that all lights shall be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For example,

(a) One requirement may determine that the program will add two inputs, and another may determine that
the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms for that
object. For example, a program's request for user input may be called a "prompt" in one requirement's and
a "cue" in another. The use of standard terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation.
This suggests that each element is uniquely interpreted. In case there is a method used with multiple
definitions, the requirements report should determine the implications in the SRS so that it is clear and
simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and stability if each
requirement in it has an identifier to indicate either the significance or stability of that particular
requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential, especially for
life-critical applications, while others may be desirable. Each element should be identified to make these
differences clear and explicit. Another way to rank requirements is to distinguish classes of items as
essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain
changes to the system to some extent. Modifications should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective
system to check whether the final software meets those requirements. The requirements are verified with
the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates
the referencing of each condition in future development or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its source in
earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having a unique name or reference
number.

The forward traceability of the SRS is especially crucial when the software product enters the operation
and maintenance phase. As code and design document is modified, it is necessary to be able to ascertain
the complete set of requirements that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple design alternatives for the
final system. More specifically, the SRS should not contain any implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test cases and
test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain but
might not be trained in computer science. Hence, the purpose of formal notations and symbols should be
avoided too as much extent as possible. The language should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details should
be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used. Hence, the level of
abstraction modifies according to the objective of the SRS.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete. Verbose and irrelevant descriptions decrease readability and also increase error possibilities.

Structured: It should be well-structured. A well-structured document is simple to understand and modify.

In practice, the SRS document undergoes several revisions to cope up with the user requirements. Often,
user requirements evolve over a period of time. Therefore, to make the modifications to the SRS document
easy, it is vital to make the report well-structured.

Black-box view: It should only define what the system should do and refrain from stating how to do
these. This means that the SRS document should define the external behavior of the system and not
discuss the implementation issues. The SRS report should view the system to be developed as a black box
and should define the externally visible behavior of the system. For this reason, the SRS report is also
known as the black-box specification of a system.

Conceptual integrity: It should show conceptual integrity so that the reader can merely understand it.
Response to undesired events: It should characterize acceptable responses to unwanted events. These are
called system response to exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS document, should be correct. This
means that it should be possible to decide whether or not requirements have been met in an
implementation.

Advantages of having a good Software Requirements Specification (SRS) document include:

1. Improved communication and understanding between stakeholders and developers, as the SRS clearly
defines the requirements for the software system
2. Increased efficiency in the software development process, as a well-written SRS can help to reduce the
need for rework and change requests
3. Improved quality of the final software system, as a well-written SRS helps to ensure that all requirements
are met
4. Increased stakeholder satisfaction, as a well-written SRS helps to ensure that the software system meets
the needs of the business and its users
5. Improved traceability and verifiability, as a well-written SRS can be traced to other documents and artifacts
and its requirements can be tested and validated.
6. Clarity and Completeness: A good SRS document provides clear and complete specifications for the
software project, which ensures that all stakeholders have a common understanding of the requirements
and objectives.

7. Traceability: A good SRS document includes detailed requirements and specifications, which enables
traceability throughout the software development process.

8. Testability: A good SRS document can serve as a basis for test cases and verification, which can ensure
that the software meets the requirements and specifications.

9. Improved Communication: A good SRS document can serve as a communication tool between different
stakeholders, such as project managers, developers, testers, and customers.
10. Reduced Rework: A good SRS document can help to identify and resolve issues early in the
development process, which can reduce the need for rework and improve the overall quality of the
software.

Disadvantages of having a poorly written SRS include:

1. Confusion and misunderstandings between stakeholders and developers, as the requirements are not
clearly defined or are vague
Increased rework and change requests, as the SRS does not accurately capture the requirements of the
software system
2. Reduced quality of the final software system, as a poorly written SRS can result in requirements being
missed or not fully met
3. Reduced stakeholder satisfaction, as a poorly written SRS does not accurately capture the needs of the
business and its users
4. Reduced traceability and verifiability, as a poorly written SRS can’t be traced to other documents and
artifacts and its requirements can’t be tested and validated.
5. It is important to note that, regardless of the quality of the SRS, gathering and validating requirements is an
iterative process, that should be continuously reviewed and updated throughout the software development
process.
6. Time-consuming: Creating a good SRS document can be a time-consuming process, especially for complex
software projects, which can delay the development process.

7. Changes and Updates: Changes or updates to the SRS document can cause delays in the software
development process and can be difficult to manage.

8. Lack of Flexibility: A detailed SRS document can restrict the flexibility of the development process, which
can be challenging for projects that require agile development methodologies.
9. Limited Stakeholder Involvement: The process of creating an SRS document can limit the involvement of
stakeholders in the software development process, which can lead to a lack of collaboration and input from
different perspectives.

10. Ambiguity: A poorly written SRS document can lead to ambiguity and misunderstandings, which can
cause issues throughout the software development process.