Introduction to Software Requirements

Specification (SRS)
Requirements Elicitation Techniques
• Requirements elicitation 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.
• Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system. It is a critical part of the software
development life cycle 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 perhaps the most difficult, most error-prone, and most
communication-intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really need.
Requirement Elicitation Process:
Requirement elicitation process can be depicted using the following diagram:

• Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.
• Organizing Requirements - The developers prioritize and arrange the requirements in
order of importance, urgency and convenience.
• Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
• The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
• Requirement Specification / Documentation - All formal & informal, functional and
non-functional requirements are documented and made available for next phase
processing.
Requirement Elicitation Techniques
• Requirements Elicitation is the process to find out the requirements for an
intended software system by communicating with client, end users, system
users and others who have a stake in the software system development.
• There are various ways to discover requirements:
• Interviews
• Surveys
• Questionnaires
• Task analysis
• Domain Analysis
• Brainstorming
• Prototyping
• Observation
Interviews
• Interviews are strong medium to collect requirements. Organization may
conduct several types of interviews such as:
• Structured (closed) interviews, where every single information to gather is
decided in advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided
in advance, more flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help
to uncover any missing requirement as numerous people are involved.
Surveys
• Organization may conduct surveys among various stakeholders by querying
about their expectation and requirements from the upcoming system.
Questionnaires
• A document with pre-defined set of objective questions and respective
options is handed over to all stakeholders to answer, which are collected and
compiled.
• A shortcoming of this technique is, if an option for some issue is not
mentioned in the questionnaire, the issue might be left unattended.
Task analysis
• Team of engineers and developers may analyze the operation for which the
new system is required. If the client already has some software to perform
certain operation, it is studied and requirements of proposed system are
collected.
Domain Analysis
• Every software falls into some domain category. The expert people in the domain
can be a great help to analyze general and specific requirements.
Brainstorming
• An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
Prototyping
• Prototyping is building user interface without adding detail functionality for user
to interpret the features of intended software product.
• It helps giving better idea of requirements. If there is no software installed at
client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned
requirements.
• The prototype is shown to the client and the feedback is noted. The client feedback
serves as an input for requirement gathering.
Observation
• Team of experts visit the client’s organization or workplace. They observe
the actual working of the existing installed systems. They observe the
workflow at client’s end and how execution problems are dealt. The team
itself draws some conclusions which aid to form requirements expected from
the software.
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:
• Helps to clarify and refine customer requirements.
• Improves communication and collaboration between stakeholders.
• Increases the chances of developing a software system that meets customer
needs.
• Avoids misunderstandings and helps to manage expectations.
• Supports the identification of potential risks and problems early in the
development cycle.
• Facilitates the development of a comprehensive and accurate project plan.
• Increases user and stakeholder confidence in the software development
process.
• Supports the identification of new business opportunities and revenue
streams.
Techniques for Requirements Modelling -
Decision Table
Decision Table
• A decision table is a brief visual representation for specifying which actions
to perform depending on given conditions.
• The information represented in decision tables can also be represented as
decision trees or in a programming language using if-then-else and switch-
case statements.
• A decision table is a good way to settle with different combination inputs
with their corresponding outputs and is also called a cause-effect table.
• The reason to call cause-effect table is a related logical diagramming
technique called cause-effect graphing that is basically used to obtain the
decision table.
Importance of Decision Table:
• Decision tables are very much helpful in test design techniques.
• It helps testers to search the effects of combinations of different inputs and
other software states that must correctly implement business rules.
• It provides a regular way of starting complex business rules, that is helpful for
developers as well as for testers.
• It assists in the development process with the developer to do a better job.
Testing with all combinations might be impractical.
• A decision table is basically an outstanding technique used in both testing and
requirements management.
• It is a structured exercise to prepare requirements when dealing with complex
business rules.
• It is also used in model complicated logic.
Advantage of Decision Table:
• Any complex business flow can be easily converted into test scenarios & test
cases using this technique.
• Decision tables work iteratively which means the table created at the first
iteration is used as input tables for the next tables. The iteration is done only
if the initial table is not satisfactory.
• Simple to understand and everyone can use this method to design the test
scenarios & test cases.
• It provides complete coverage of test cases which helps to reduce the rework
on writing test scenarios & test cases.
• These tables guarantee that we consider every possible combination of
condition values. This is known as its completeness property.
Event Table
In software engineering, an event table is a data structure that stores information about events that
occur in a software system. Events can be anything from user actions to system-level events, such as
a database update. The event table typically includes the following information:
• Event type: The type of event, such as a user click, a system error, or a database update.
• Event time: The time at which the event occurred.
• Event data: Any additional data associated with the event, such as the user who triggered the
event or the data that was updated in the database.
Event tables can be used for a variety of purposes, such as:
• Logging: Event tables can be used to log all events that occur in a software system. This can be
helpful for debugging problems or tracking down performance issues.
• Monitoring: Event tables can be used to monitor the performance of a software system. This can
be done by tracking the number of events that occur over time, the types of events that occur, and
the time at which events occur.
• Alerting: Event tables can be used to generate alerts when certain events occur. This can be
helpful for notifying users of problems or for taking action to prevent problems from occurring.
State Transition Table
State Transition Table:
A state transition table is a table that shows the possible states of a
system and the events that can cause the system to transition from one state to
another. It is a useful tool for software engineers to use to test the behavior of
their systems.

In state transition table all the states are listed on the left side, and
the events are described on the top. Each cell in the table represents the
state of the system after the event has occurred. It is also called State
Table. It is useful in identifying invalid transitions.
Petri Nets
What Does Petri Net Mean?
Petri nets are a graphical for representing a system in which there are multiple
independent activities in progress at the same time. The ability to model multiple
activities differentiates Petri nets from finite state machines.
In a finite state machine there is always a single “current” state that
determines which action can next occur. In Petri nets there may be several states any
one of which may evolve by changing the state of the Petri net. Alternatively, some,
of even all, of these states may evolve in parallel causing several independent
changes to the Petri net to occur at once.
Basic Structure
A Petri net consists of four elements: places, transitions, edges, and tokens.
Graphically, places are represented by circles, transitions by rectangles, edges by
directed arrows, and tokens by small solid (filled) circles. There are a wide variety of
extensions to Petri nets. These extensions add features to model probabilistic
behavior, allow weighted edges, or have tokens of various colors among others.
 A basic Petri net is shown in below figure 2(next slide). This Petri net
has four places, labeled P0 through P4, and three transitions, labeled T0
through T2. Notice that places P0 and P2 each have a single token represented
by the black dot inside each place. Edges, represented as directed arcs, connect
places to transitions and transitions to places.
In a properly formed Petri net, places cannot be directly connected to
other places and transitions cannot be directly connected to other
transitions. Also notice that the Petri net may contain cycles. The Petri net in
Figure 2 contains two cycles. One cycle contains P0, T0, P1, T1, P3, and T3.
The other cycle contains T1, P4, T2, and P2. Cycles are common in Petri nets
which represent activities that happen repeatedly. For example, a web server
repeated services incoming requests to deliver web page content to different
clients.
 The state of a Petri net is represented by the occurrence of the tokens at various
places. The state of the Petri net in Figure 2 has tokens at places P0 and P2. It will be shown
that in another state of this Petri net there are tokens at states P1 and P2. Yet another state
has tokens at states P3 and P4. Not all placements of tokens at places represent a possible
state of the system. For example, the Petri net in Figure 2 will never have as a possible state
one in which the only tokens are at places P1 and P4. Which states are possible and which
are not are determined by the structure of the Petri net and the rules that define how a Petri
net changes its state.
 A Petri net changes from one state to the next state when a transition “fires”. The firing of a
transition involves the transition’s input places and output places. The input places for a transition
are all those places that have an edge directed from the place to the transition. The output places of a
transition are all those places that have an edge directed from the transition to the place. For
example, in Figure 2 the input places for transition T1 are places P1 and P2. The output place for
transition T0 is place P1 while the output places for transition T1 are places P3 and P4.
The firing rules for a transition are:
• a transition is able to fire when there is at least one token on each of the transition’s input places,
• when a transition fires it removes one token from each of its input places and produces a single
token on each of its output places.
A transition that is able to fire is said to be enabled and otherwise disabled. If there is more
than one enabled transition any one of enabled transitions may be the next one to fire. That is, Petri
nets are able to model systems with non‐deterministic behavior. An example of this will be shown
later.
 The Petri net in Figure 2 will be used to explain how a Petri net changes
from one state to the next. In Figure 2 the only transition that is able to fire is
transition T0 because it has a single input place, P0, and that input place has at
least one token. Notice that transition T1 is not able to fire because it has two
input places, P1 and P2, and P1 does not have at least one input token. As a
result of the firing on transition T0, the token in place P0 is removed and a
single token is created in place P1. This state is shown in Figure 3.
 In the state of the Petri net shown in Figure 3 transition T1 is able to fire
because there are input tokens on each of its two input places, P1 and P2. Notice that
transition T1 was not able to fire in the previous state of the Petri net (as shown in
Figure 2). The firing of transition T0 in the earlier state create a new state (the one
shown in Figure 3) in which transition T1 is now able to fire. It is common to find
that the firing of a transition creates a new state in which previously disabled (i.e.,
unable to fire) transitions now become enabled (i.e., able to fire). Notice that in
Figure 3, transition T1 is the only transition that is enabled. The firing of transition
T1 in the state shown in Figure 3 produces the new state shown in Figure 4.
In the state of the Petri net shown in Figure 4 both transitions T2 and T3 are
enabled (i.e., able to fire). As noted about, these transitions may fire in either order
because the Petri net does not determine which one of the two transitions is the next
one to fire. The next state of the Petri net is, thus, not uniquely determined. The next
state can be the one following the firing of transition T3 or the one following the
firing of transition T2. The reader should draw both of these states and see that they
are different.
The state shown in Figure 4 will eventually lead back to one of the previous states. The
possibilities are:
• transition T2 fires and then transition T3 fires, leading to the state shown in Figure 2,
• transition T3 fires and then transition T2 fires, leading to the state shown in Figure 2, or
• transition T3 fires, transition T0 fires, and then transition T2 fires, leading to the state
shown in Figure 3.
This Petri net will continue to transition among these states repeatedly.
Order processing example Significant reasons for preferring Petri net
modelling in connection with workflow modelling
Requirement documentation through Use Cases
• Use cases are a popular technique for documenting and understanding
system requirements. They are used to describe the interactions between
users and a system in order to achieve a specific goal.
• Use case diagrams are a graphical representation of use cases. They show the
actors (users) who interact with the system, the use cases that those actors
can perform, and the relationships between the use cases.
• Use case specifications are a detailed description of each use case. They
include the following information:
• The name of the use case
• The description of the use case
• The actors who can perform the use case
• The preconditions that must be met before the use case can be performed
• The postconditions that are met when the use case is completed
• The flow of events that describes how the use case is performed
• The exceptions that can occur during the use case
• Requirement documentation is the process of gathering, documenting, and managing the requirements for a
software system. It includes the following activities:
• Identifying the requirements
• Analyzing the requirements
• Prioritizing the requirements
• Documenting the requirements
• Managing the requirements
• Use cases can be used to document the requirements for a software system. They are a useful tool for
communicating the requirements to stakeholders and for managing the requirements throughout the
development process.
• Here are some benefits of using use cases for requirement documentation:
• Use cases are easy to understand. They are written in plain language that is easy for both technical and non-
technical stakeholders to understand.
• Use cases are comprehensive. They can be used to document all of the requirements for a software system,
including functional and non-functional requirements.
• Use cases are flexible. They can be used to document requirements for a wide variety of software systems.
• Use cases are reusable. The same use cases can be reused for multiple software systems.
Here are some drawbacks of using use cases for requirement documentation:
• Use cases can be time-consuming to develop. They require a deep
understanding of the software system and the needs of the stakeholders.
• Use cases can be difficult to maintain. As the software system evolves, the
use cases must be updated to reflect the changes.
• Use cases can be difficult to use for complex systems. For complex systems,
it may be necessary to use other techniques, such as user stories, in addition to
use cases.
Introduction to UML
Introduction to Software Metrics & Metrics based
Control Methods
Software Metrics
• A software metric is a measure of software characteristics which are
measurable or countable. Software metrics are valuable for many reasons,
including measuring software performance, planning work items, measuring
productivity, and many other uses.
• Within the software development process, many metrics are that are all
connected.
• Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement.
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics:
These are the measures of various characteristics of the software
product. The two important software characteristics are:
1.Size and complexity of software.
2.Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics:
These are the measures of various characteristics of the software
development process.
For example, the efficiency of fault detection. They are used to measure the
characteristics of methods, techniques, and tools that are used for developing
software.
Types of Metrics
• Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed
to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.
• External metrics: External metrics are the metrics used for measuring properties that are viewed
to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
• Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.
• Project metrics: Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various metrics, like time and
cost; these estimates are used as a base of new software. Note that as the project proceeds, the
project manager will check its progress from time-to-time and will compare the effort, cost, and
time with the original effort, cost and time. Also understand that these metrics are used to
decrease the development costs, time efforts and risks. The project quality can also be improved.
As quality improves, the number of errors and time, as well as cost required, is also reduced.
Advantage of Software Metrics
• Comparative study of various design methodology of software systems.
• For analysis, comparison, and critical study of different programming language concerning their
characteristics.
• In comparing and evaluating the capabilities and productivity of people involved in software
development.
• In the preparation of software quality specifications.
• In the verification of compliance of software systems requirements and specifications.
• In making inference about the effort to be put in the design and development of the software
systems.
• In getting an idea about the complexity of the code.
• In taking decisions regarding further division of a complex module is to be done or not.
• In guiding resource manager for their proper utilization.
• In comparison and making design tradeoffs between software development and maintenance cost.
Metrics based Control Methods
• Metrics-based control methods are a set of techniques used in software engineering to measure
and control the quality and progress of a software project. These methods use metrics, which are
measurable or countable values that can be used to assess the state of a software project.
There are three main types of metrics used in metrics-based control methods:
• Product metrics: These metrics measure the characteristics of the software product itself, such as
its size, complexity, and performance.
• Process metrics: These metrics measure the activities and tasks involved in the software
development process, such as the time spent on each task, the number of defects found, and the
number of changes made.
• Project metrics: These metrics measure the overall progress of the software project, such as the
budget, schedule, and scope.
Metrics-based control methods can be used to:
• Identify potential problems early on: By tracking metrics, project managers can identify
potential problems early on, such as a high defect rate or a slipping schedule. This allows them to
take corrective action before the problems become too serious.
• Make better decisions: By tracking metrics, project managers can make better decisions about
how to allocate resources and manage the project. For example, if they see that the defect rate is
high, they may decide to allocate more resources to testing.
• Improve the quality of the software product: By tracking metrics, project managers can
identify areas where the quality of the software product can be improved. For example, if they see
that the number of changes made is high, they may decide to improve the project's change
management process.
• Metrics-based control methods are an important tool for software engineers and project managers.
By tracking metrics, they can identify potential problems early on, make better decisions, and
improve the quality of the software product.
Here are some examples of metrics-based control methods:
• Plan-Do-Check-Act (PDCA): This is a cyclical process for continuous improvement. It involves
planning what to do, doing it, checking the results, and taking action to improve the process.
• Six Sigma: This is a set of quality management methods that use statistical methods to improve
the quality of products and services.
• TQM (Total Quality Management): This is a philosophy of management that emphasizes
continuous improvement and customer satisfaction.
Some commonly used metrics-based control methods in software engineering:
1.Defect Density: This metric measures the number of defects found per unit of software size (e.g.,
lines of code or function points). It helps assess the quality of the software and identify areas that
require improvement.
2.Code Coverage: Code coverage measures the extent to which the source code of a software
system is executed by the test suite. It provides an indication of how well the code is tested and
helps identify untested or poorly tested areas.
3.Effort Variance: This metric compares the planned effort with the actual effort expended on a
project. It helps in assessing project progress and identifying deviations from the initial plan,
allowing for adjustments in resource allocation and schedules.
4.Schedule Variance: Schedule variance compares the planned schedule with the actual progress of
the project. It helps determine whether the project is ahead of or behind schedule and aids in
managing project timelines effectively.
5.Customer Satisfaction: Customer satisfaction metrics capture the feedback and satisfaction
levels of the software's end-users or stakeholders. These metrics can be obtained through surveys,
feedback forms, or user reviews, providing insights into user experience and satisfaction.
6. Code Complexity: Code complexity metrics, such as cyclomatic complexity or
maintainability index, quantify the complexity of the software's source code. Higher
complexity values indicate code that may be harder to understand, maintain, and test.
7. Reusability: Reusability metrics measure the extent to which software components or
modules can be reused in other projects or contexts. This metric encourages the development
of modular and reusable code, leading to increased productivity and cost savings.
8. Lead Time: Lead time measures the time it takes to complete a software development task or
deliver a software feature. Monitoring lead time helps identify bottlenecks or delays in the
development process, allowing for process improvements and timely delivery.
9. Defect Removal Efficiency: Defect removal efficiency calculates the effectiveness of the
testing and quality assurance processes in detecting and removing defects before software
release. It provides insights into the efficiency of defect identification and correction
activities.
10. Productivity: Productivity metrics measure the output or work accomplished by the
development team over a specific period. It helps in tracking the efficiency and effectiveness
of the development process, aiding in resource allocation and project planning.
Measure of Code & Design Quality
• There are a number of metrics that can be used to measure the quality of code and design in
software engineering. Some of the most common metrics include:
• Cyclomatic complexity: This metric measures the complexity of a piece of code by counting the
number of decision points in the code. A high cyclomatic complexity can indicate that the code is
difficult to understand and maintain.
• Maintainability index: This metric measures the maintainability of a piece of code by
considering factors such as the number of comments, the use of modules, and the complexity of
the code. A high maintainability index indicates that the code is easy to understand and maintain.
• Testability: This metric measures the testability of a piece of code by considering factors such as
the use of clear and concise code, the use of well-defined functions, and the use of unit tests. A
high testability index indicates that the code is easy to test.
• Reusability: This metric measures the reusability of a piece of code by considering factors such
as the use of generic code, the use of well-defined interfaces, and the use of well-documented
code. A high reusability index indicates that the code can be reused in other projects.
• Defect density: This metric measures the number of defects in a piece of code per unit of code. A
low defect density indicates that the code is relatively free of defects.
Some of the most common qualitative metrics include:
• Readability: This metric measures how easy it is to read and understand the
code.
• Clarity: This metric measures how clear and concise the code is.
• Efficiency: This metric measures how efficient the code is in terms of its
execution time and memory usage.
• Robustness: This metric measures how robust the code is in terms of its
ability to handle unexpected inputs and errors.
• Extensibility: This metric measures how easy it is to extend the code with
new functionality.