3.

1 Requirement Elicitation,
3.2 Software requirement specification (SRS)
Chapter 3
Requirements Analysis

3.2.1 Developing Use Cases (UML)

3.3 Building the Analysis Model
3.3.1 Elements of the Analysis Model
3.3.2 Analysis Patterns
3.3.3 Agile Requirements Engineering
3.4 Negotiating Requirements
3.5 Validating Requirements
Requirements elicitation
• It is the process of gathering and defining the requirements for a
software system.
• The goal of requirements elicitation is to ensure that the software
development process is based on a clear and comprehensive
understanding of the customer’s needs and requirements.
• The process of investigating and learning about a system’s requirements from
users, clients, and other stakeholders is known as requirements elicitation.
• Requirements elicitation in software engineering is perhaps the most difficult,
most error-prone, and most communication-intensive software development.
• Requirement Elicitation can be successful only through an effective customer-
developer partnership. It is needed to know what the users require.
• Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system.
• Requirement Elicitation is a critical part of the sdlc and is typically performed
at the beginning of the project.
• Requirements elicitation involves stakeholders from different areas of
the organization, including business owners, end-users, and technical
experts.
• 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.
• Requirements elicitation is difficult because just questioning users and
customers about system needs may not collect all relevant
requirements, particularly for safety and dependability.
• Interviews, surveys, user observation, workshops, brainstorming, use
cases, role-playing, and prototyping are all methods for eliciting
requirements.
Software requirement specification
• Software Requirement Specification (SRS) as the name suggests, is a
complete specification and description of requirements of the
software that need to be fulfilled for the successful development of
the software system.
• These requirements can be functional as well as non-functional
depending upon the type of requirement.
• The interaction between different customers and contractors is done
because it is necessary to fully understand the needs of customers.
• Depending upon information gathered after interaction, SRS is
developed which describes requirements of software that may
include changes and modifications that is needed to be done to
increase quality of product and to satisfy customer’s demand.
• Purpose of this Document – At first, main aim of why this document
is necessary and what’s purpose of document is explained and
described.
• Scope of this document – In this, overall working and main objective
of document and what value it will provide to customer is described
and explained. It also includes a description of development cost and
time required.
• Overview – In this, description of product is explained. It’s simply
summary or overall review of product.
 Functional Requirements
• In this, possible outcome of software system which includes effects
due to operation of program is fully explained.
• All functional requirements which may include calculations, data
processing, etc. are placed in a ranked order.
• Functional requirements specify the expected behavior of the system-
which outputs should be produced from the given inputs. They
describe the relationship between the input and output of the system.
• For each functional requirement, detailed description all the data
inputs and their source, the units of measure, and the range of valid
inputs must be specified.
Interface Requirements
• In this, software interfaces which mean how software program communicates
with each other or users either in form of any language, code, or message are
fully described and explained. Examples can be shared memory, data streams,
etc.
Performance Requirements
• In this, how a software system performs desired functions under specific
condition is explained.
• It also explains required time, required memory, maximum error rate, etc. The
performance requirements part of an SRS specifies the performance constraints
on the software system.
• All the requirements relating to the performance characteristics of the system
must be clearly specified. There are two types of performance requirements:
static and dynamic.
• Static requirements are those that do not impose constraint on the execution
characteristics of the system.
• Dynamic requirements specify constraints on the execution behavioure of the
Design Constraints
• In this, constraints which simply means limitation or restriction are
specified and explained for design team.
• Examples may include use of a particular algorithm, hardware and
software limitations, etc.
• There are a number of factors in the client’s environment that may
restrict the choices of a designer leading to design constraints such
factors include standards that must be followed resource limits,
operating environment, reliability and security requirements and
policies that may have an impact on the design of the system.
• An SRS should identify and specify all such constraints.
Non-Functional Attributes
• In this, non-functional attributes are explained that are required by
software system for better performance.
• An example may include Security, Portability, Reliability, Reusability,
Application compatibility, Data integrity, Scalability capacity, etc.
Preliminary Schedule and Budget
• In this, initial version and budget of project plan are explained which
include overall time duration required and overall cost required for
development of project.
Appendices
• In this, additional information like references from where information
is gathered, definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained
 Uses of SRS document
• Development team require it for developing product according to the need.
• Test plans are generated by testing group based on the describe external
behavior.
• Maintenance and support staff need it to understand what the software
product is supposed to do.
• Project manager base their plans and estimates of schedule, effort and
resources on it.
• Customer rely on it to know that product they can expect.
• As a contract between developer and customer.
• As a documentation purpose.
UML Use Case Diagram
• A use case diagram is used to represent the dynamic behavior of a
system.
• It encapsulates the system's functionality by incorporating use cases,
actors, and their relationships.
• It models the tasks, services, and functions required by a
system/subsystem of an application.
• It depicts the high-level functionality of a system and also tells how
the user handles a system
 Purpose of Use Case Diagrams
• The main purpose of a use case diagram is to portray the dynamic aspect
of a system.
• It accumulates the system's requirement, which includes both internal as
well as external influences.
• It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams.
• It represents how an entity from the external environment can interact
with a part of the system.
• It gathers the system's needs.
• It depicts the external view of the system.
• It recognizes the internal as well as external factors that influence the
system.
• It represents the interaction between the actors.
 How to draw a Use Case diagram?
• It is essential to analyze the whole system before starting with drawing a use
case diagram, and then the system's functionalities are found.
• And once every single functionality is identified, they are then transformed into
the use cases to be used in the use case diagram.
A use case diagram depicting the Online Shopping website is given below.
• Here the Web Customer actor makes use of any online shopping website to
purchase online.
• The top-level uses are as follows; View Items, Make Purchase, Checkout, Client
Register.
• The View Items use case is utilized by the customer who searches and view
products.
• The Client Register use case allows the customer to register itself with the
website for availing gift vouchers, coupons, or getting a private sale invitation.
• It is to be noted that the Checkout is an included use case, which is part
of Making Purchase, and it is not available by itself.
• The View Items is further extended by several use cases such as;
Search Items, Browse Items, View Recommended Items, Add to
Shopping Cart, Add to Wish list.
• All of these extended use cases provide some functions to customers,
which allows them to search for an item.
• Both View Recommended Item and Add to Wish List include the
Customer Authentication use case, as they necessitate authenticated
customers, and simultaneously item can be added to the shopping
cart without any user authentication.
• Similarly, the Checkout use case also includes the following use cases,
as shown below.
• It requires an authenticated Web Customer, which can be done by
login page, user authentication cookie ("Remember me"), or Single
Sign-On (SSO). SSO needs an external identity provider's participation,
while Web site authentication service is utilized in all these use cases.
• The Checkout use case involves Payment use case that can be done
either by the credit card and external credit payment services or with
PayPal.
 Important tips for drawing a Use Case diagram
Following are some important tips that are to be kept in mind while
drawing a use case diagram:
• A simple and complete use case diagram should be articulated.
• A use case diagram should represent the most significant interaction
among the multiple interactions.
• At least one module of a system should be represented by the use
case diagram.
• If the use case diagram is large and more complex, then it should be
drawn more generalized.
Building the Analysis Model
• Analysis Model is a technical representation of the system.
• It acts as a link between the system description and the design model.
• In Analysis Modelling, information, behavior, and functions of the
system are defined and translated into the architecture, component,
and interface level design in the design modeling.
 Objectives of Analysis Modelling
• Understanding Needs: The process of analysis modelling helps in the
understanding and extraction of user needs for the software system.
• Communication: Analysis models facilitate communication between users,
clients, developers, and testers, among other stakeholders.
• Clarifying Ambiguities: Analysis models assist in resolving requirements
disputes and providing clarification on unclear areas.
• Finding the Data Requirements: Analysis modelling assists in determining
the relationships, entities, and qualities of the data that the system needs.
• Defining Behavior: Analysis modelling aids in the definition of the system’s
dynamic behavior, including workflows, processes, and inter-component
interactions.
• System Boundary Identification: It is made easier by analysis modelling,
which helps in defining the parameters of the software system and its
interactions with users, other systems, and hardware components.
Elements of Analysis Model
• Data Dictionary:
It is a repository that consists of a description of all data objects used or produced by the
software. It stores the collection of data present in the software. It is a very crucial element of the
analysis model. It acts as a centralized repository and also helps in modeling data objects defined
during software requirements.

• Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting data modeling
activities. The attributes of each object in the Entity-Relationship Diagram can be described using
Data object description. It provides the basis for activity related to data design.

• Data Flow Diagram (DFD):

It depicts the functions that transform data flow, and it also shows how data is transformed when
moving from input to output. It provides the additional information that is used during the
analysis of the information domain and serves as a basis for the modeling of function. It also
enables the engineer to develop models of functional and information domains at the same time.

• State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the transitions from one
state to another state in the system. It also provides the details of how the system behaves due to
the consequences of external events. It represents the behavior of a system by presenting its
states and the events that cause the system to change state. It also describes what actions are
taken due to the occurrence of a particular event.
• Process Specification:
It stores the description of each function present in the data flow diagram. It
describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced. It also shows
regulations and barriers imposed on the performance characteristics that
apply to the process and layout constraints that could influence how the
process will be implemented.

• Control Specification:
It stores additional information about the control aspects of the software. It is
used to indicate how the software behaves when an event occurs and which
processes are invoked due to the occurrence of the event. It also provides the
details of the processes which are executed to manage events.

• Data Object Description:

It stores and provides complete knowledge about a data object present and
used in the software. It also gives us the details of attributes of the data object
present in the Entity Relationship Diagram. Hence, it incorporates all the data
objects and their attributes.
 Key Principles of Analysis Modelling
• Abstraction: Analysis modelling involves separating important system components from
unneeded specifics. While leaving out unnecessary or low-level information, it concentrates on
capturing the essential ideas, behaviors, and relationships relevant to the system’s requirements.
• Modularity: Analysis models ought to be able to break down a system into smaller, more
manageable parts. It is simpler to understand, assess, and alter the system when each module or
component reflects a different part of its functionality.
• Consistency: Internally and with other project artifacts, including requirements documents,
design specifications, and implementation code, analysis models should be consistent. By
preventing opposing or conflicting representations of the system, consistency promotes greater
stakeholder comprehension and alignment.
• Traceability: Analysis models ought to be able to be linked to other project components so that
interested parties may follow requirements from their inception to their execution. Throughout
the software development lifecycle, it helps with impact analysis, change management, and
requirements coverage verification.
• Precision: To provide an unambiguous picture of the needs and behaviors of the system, analysis
models must be accurate and exact. Accuracy lowers the chance of miscommunication and
misunderstanding among stakeholders as well as implementation problems.
• Separation of Concerns: Analysis modeling divides various system components or concerns into
discrete representations. For instance, behavioral modeling aims to capture the dynamic behavior
of the system, whereas data modeling concentrates on expressing the relationships and structure
Analysis Patterns
An analysis pattern is a template for solving an organizational, social or economic
problem in a professional domain.
• A pattern is a solution template that has proven useful for solving a concrete problem.
• In software development, this concept is known as a design pattern.
• It provides code solutions.
• Analysis patterns are patterns that are also used in software development.
• They describe solutions for problems in specialist domains.
• These solutions are class diagram models (a UML diagram type) instead of code.
• Example : A library has multiple instances of a particular book. These instances all have
the same author and title. This means that the properties are available multiple times
because there are multiple editions available. Applied to modelling with class diagrams,
this means that if you work with a class like Book, you have the problem of having to
save the same properties multiple times, redundantly. With the analysis pattern Instance
type, from Heide Balzert, this problem can be solved: You add another class (book type)
that contains unchanging properties like Title and Author as attributes. This analysis
pattern can be used as a template in other subject areas where this problem occurs.
 Advantages of Analysis Patterns
• Analysis patterns in software development help better understand a
problem.
• The class diagram represents knowledge that has been tried out and
can be applied at a high abstraction level.
• Additionally, analysis patterns offer a means of communication
between system analysts and domain experts.
• Because standardized presentation allows you to understand models
better and take a closer look at the problem.
• This means the work in the analysis phase is reduced whereas the
results will be of a higher quality.
Classification of Analysis
Patterns
There are two types of analysis patterns:
• General/universal (mainly defined by Balzert ):
• Modelling templates
• Building blocks for other patterns
• Application-specific (mainly defined by Fowler ):
• for planning system and merchandise management systems (Patterns
that concern repeating problems when analyzing running information
systems)
 Analysis Patterns in
Requirements Analysis
• Creating models in the analysis phase creates a foundation for
requirements elicitation or for deriving use cases.
• In his pattern catalog “Analysis patterns: reusable object models,” Fowler
provides methods for object-oriented analysis of specific domains like
health, accounting or finances which enable requirement analysis to take
place more quickly.
• Darimone and Lamsweerde have developed analysis patterns for refining
stakeholder goals. Jackson created something similar to an analysis
pattern with his “Problem frames approach”.
• Problem frames don’t correspond to solutions, instead to repeating
problems.
 Agile Requirements Engineering
• Agile Requirements Engineering is a crucial discipline within software
development and project management that focuses on the continuous
identification, documentation, and management of the requirements for
a project in an Agile environment.
• This approach to requirements engineering emphasizes flexibility,
collaboration, and adaptability throughout the project lifecycle, ensuring
that the final product meets the evolving needs of stakeholders and
users.
• Agile Requirements Engineering leverages several key principles and
practices from Agile methodologies such as Scrum, Kanban, and Extreme
Programming (XP) to effectively manage project requirements.
• It involves continuous engagement with stakeholders, iterative
development, and regular feedback loops to adapt to changes quickly.
This approach helps in minimizing risks, enhancing product quality, and
ensuring customer satisfaction.
 Benefits Agile Requirements
Engineering
• Flexibility in Changes: Agile Requirements Engineering allows teams
to respond to changes in user needs and market conditions swiftly,
ensuring that the product remains relevant and competitive.
• Increased Stakeholder Engagement: By involving stakeholders
throughout the project, this approach ensures that their expectations
are accurately captured and met.
• Enhanced Collaboration: It fosters a collaborative environment where
team members can share ideas, solve problems collectively, and make
decisions quickly.
• Improved Quality: Regular reviews and iterations help in identifying
and addressing issues early, leading to a higher quality final product.
 Key Practices and Features
• User Stories and Backlogs: Requirements are captured as user stories,
which are then prioritized in the product backlog. This provides a
clear and flexible roadmap for the project.
• Iterative Development: The project is divided into short, manageable
iterations or sprints, allowing for frequent reassessment and
adaptation of requirements.
• Continuous Feedback: Regular feedback from stakeholders and users
is integrated into the development process, ensuring that the product
aligns with their expectations.
 How to Implement Agile Requirements
Engineering
• Implementing Agile Requirements Engineering effectively requires a deep
understanding of Agile principles and practices. Here are some steps to get
started:
• Stakeholder Engagement: Identify and engage with all relevant stakeholders
early in the project to understand their needs and expectations.
• Create User Stories: Translate stakeholder requirements into user stories,
making them the central element of the requirements engineering process.
• Prioritize the Backlog: Work with stakeholders to prioritize the user stories in
the product backlog based on value, risk, and dependencies.
• Iterative Planning and Development: Plan sprints around prioritized user
stories, and adjust plans based on feedback and changes in requirements.
• Regular Reviews and Retrospectives: Conduct sprint reviews with
stakeholders and retrospectives with the development team to assess
progress and adapt processes accordingly.
 Negotiating requirements
• The inception, elicitation, and elaboration tasks in an ideal requirements
engineering setting determine customer requirements in sufficient depth to
proceed to later software engineering activities.
• You might have to negotiate with one or more stakeholders. Most of the
time, stakeholders are expected to balance functionality, performance, and
other product or system attributes against cost and time-to-market.
• The goal of this discussion is to create a project plan that meets the
objectives of stakeholders while also reflecting the real-world restrictions
(e.g., time, personnel, and budget) imposed on the software team.
• The successful negotiations aim for a “win-win” outcome. That is,
stakeholders, benefit from a system or product that meets the majority of
their needs, while you benefit from working within realistic and reasonable
budgets and schedules.
• At the start of each software process iteration, Boehm defines a series
of negotiating actions.
• Rather than defining a single customer communication activity, the
following are defined:
Identifying the major stakeholders in the system or subsystem.
Establishing the stakeholders’ “win conditions.”
Negotiation of the win conditions of the stakeholders in order to
reconcile them into a set of win-win conditions for all people
involved.
 Validating Requirements
• Each aspect of the requirements model is checked for consistency,
omissions, and ambiguity as it is developed.
• The model’s requirements are prioritised by stakeholders and
bundled into requirements packages that will be implemented as
software increments.
• Were all requirements expressed at the appropriate level of abstraction? Do some
criteria, in other words, give a level of technical information that is inappropriate
at this stage?
• Is the requirement truly necessary, or is it an optional feature that may or may not
be critical to the system’s goal?
• Is each requirement well defined and unambiguous?
• Is each requirement attributed? Is there a source noted for each requirement?
• Are there any requirements that conflict with others?
• Is each requirement attainable in the technical environment in which the system
or product will be housed?
• Is each requirement, once implemented, testable?
• Does the requirements model accurately represent the information, functionality,
and behaviour of the system to be built?
• Has the requirements model been “partitioned” in such a way that progressively
more detailed information about the system is exposed?
• Have requirements patterns been used to reduce the complexity of the
requirements model?