Software Requirement Specification (SRS)

Document Checklist




The SRS document is reviewed by the testing person or a group of

persons by using any verification method (like peer reviews,
walkthroughs, inspections, etc.). We may use inspections due to
their effectiveness and capability to produce good results. We may
conduct reviews twice or even more often. Every review will improve
the quality of the document but may consume resources and
increase the cost of the software development. A checklist is a
popular verification tool that consists of a list of critical information
content that a deliverable should contain. A checklist may also look
for duplicate information, missing information, unclear information,
wrong information, etc. Checklists are used during reviewing and
may make reviews more structured and effective.
A Software Requirement Specification (SRS) document is a vital
component of software development. It outlines the functional and
non-functional requirements of the software and serves as a
reference for all stakeholders involved in the project. However,
creating a comprehensive and accurate SRS document can be a
daunting task. That’s where an SRS document checklist comes in
handy. In this article, we’ll discuss the essential elements of an SRS
document checklist.
1. Purpose and Scope
The purpose and scope section of an SRS document should
provide a high-level overview of the software, its intended
audience, and the problem it solves. This section should also
outline any constraints, assumptions, and dependencies that may
affect the software’s development.
2. Functional Requirements
Functional requirements describe what the software should do.
These requirements should be specific, measurable, and testable.
This section should include details about the software’s features,
user interface, and data processing.
3. Non-functional Requirements
Non-functional requirements describe how the software should
perform. These requirements should be measurable and testable.
This section should include details about the software’s
performance, security, reliability, and usability.
4. System Architecture
The system architecture section should describe the high-level
 design of the software. This section should include details about
the software’s components, interfaces, and data flow.
5. Data Management
The data management section should describe how the software
will handle data. This section should include details about the
software’s database, data storage, and data backup and recovery
processes.
6. User Documentation
The user documentation section should describe how users will
interact with the software. This section should include details
about the software’s user interface, user manuals, and help
documents.
7. Testing Requirements
The testing requirements section should describe how the
software will be tested. This section should include details about
the software’s test cases, test environment, and test data.
8. Acceptance Criteria
The acceptance criteria section should describe how the software
will be accepted by the stakeholders. This section should include
details about the software’s acceptance tests, validation criteria,
and sign-off procedures.
9. Project Timeline
The project timeline section should provide a timeline for the
software’s development. This section should include details about
the software’s milestones, deliverables, and deadlines.
10. Stakeholder List
The stakeholder list section should identify all the stakeholders
involved in the project. This section should include details about
each stakeholder’s role, responsibilities, and contact information.
An SRS document checklist should address the following issues :
1. Correctness :
In the SRS document, every requirement stated in the document
should correctly represent an expectation from the proposed
software. All applicable safety and security requirements must be
identified. Also, all the inputs and outputs of each requirement
are required and sufficient for the specified processing. For
example, If there’s a client requirement for the software to
respond to all buttons pressed within 2 seconds, but the SRS
states that ‘the software shall respond to all buttons pressed
within 20 seconds’, then that will be referred to as incorrectness
in the documentation.

2. Ambiguity :
The SRS document may contain some ambiguity in the software
requirements. For example, If a requirement conveys more than
one meaning of a thing, then it will be a serious problem so, to
 avoid this ambiguity, every requirement must have a single
meaning only. Hence, the software requirement statement should
be short, correct, precise, and clear. The SRS document checklist
must focus on ambiguous words to avoid ambiguity.

3. Completeness :
The SRS document should be complete in all aspects it must have
all the important functional requirements (like hardware faults,
I/O errors, computational errors, processing overload, buffer
overflow, events failing to occur, etc.) and non-functional
requirements needed for the software and this completeness of
the SRS document must be checked thoroughly through a
checklist.

4. Consistency :
In the SRS document, the consistency of the document can be
maintained if all the stated requirements do not vary from the
other stated requirements. Every object is referred to with a
unique name and is defined by one set of characteristics that are
not in conflict with one another. Also, if the Mathematical
equations, acronyms, and abbreviations are defined and used
consistently, then the document will be consistent. The checklist
must highlight the issues related to inconsistency and should be
designed to find inconsistencies.

5. Verifiability :
In the SRS document, it is said to be verifiable, if and only if,
every requirement stated in the document is verifiable. The non-
verifiable requirements include statements like ‘good interfaces’,
‘excellent response time’, ‘usually’, ‘well’, etc, which should not
be used. The requirements terminology like “shall”, “will”, “may”,
etc. should be used. In the document, we should only use
measurable terms and must avoid all the indefinite terms.

6. Traceability :
The SRS document can be traceable if the source of every
requirement is defined correctly as it may help in future
development. Traceability may help to structure the document
and should find a place in the design of the checklist.

7. Feasibility :
In the SRS document, some of the requirements may not be
feasible to implement due to technical reasons or lack of
resources so, those such requirements should be identified and
accordingly removed from the SRS document. A document
checklist can also help us to find some other non-feasible
 requirements in the software. Like for example, the data
expected from external sources must exist at the defined
sources, or the data sent to external destinations is expected at
those destinations otherwise, the requirements may not be
feasible to implement.
Goals of SRS document:

1. Problem Breakdown: it divides the problem into parts.

2. Input to design specification: it serves as the parent
document to subsequent documents such as the software design
specification and statement of work.
3. Feedback to the the customer: customer is assured that the
developing organization understands the issues or problems to be
solved.
4. Product validation check: it ensures the good quality of the
product.
Advantages of SRS document:
1. Clarity: The SRS document provides an unambiguous description
of the requirements, which helps to reduce confusion and
misinterpretation.
2. Consistency: The SRS document provides a consistent and
structured way to document requirements, which helps to ensure
that all requirements are covered.
3. Traceability: The SRS document provides a traceable link
between the requirements and the final software product, which
helps to ensure that all requirements have been met.
4. Validation: The SRS document can be used as a basis for
validating the software, which helps to ensure that the software
meets the requirements.

Disadvantages of SRS document:

1. Time-consuming: Creating an SRS document can be time-
consuming, especially if the software system is complex and
involves many stakeholders.
2. Limited flexibility: Once the SRS document is created, it can be
difficult to make changes to it without affecting other parts of the
document.
3. Limited user involvement: If the SRS document is created before
user involvement, it may not reflect the actual needs and
requirements of the users.
4. Misinterpretation: Despite efforts to make the SRS document
unambiguous, there may still be some room for misinterpretation,
which can lead to errors in the final software product.
 In conclusion, an SRS document checklist is an essential tool for
software development. It helps ensure that all the requirements are
included in the SRS document and that the software meets the
stakeholders’ needs. By following this checklist, software developers
can create a comprehensive and accurate SRS document that
serves as a reference for all stakeholders involved in the project.

Design Documentation in Software

Engineering




The design phase of software development deals with transforming

the customer requirements as described in the SRS documents into
a form implementable using a programming language. The software
design process can be divided into the following three levels of
phases design:
 Interface Design
 Architectural Design
 Detailed Design

Software Design Document:

Software Design Document is a written document that provides a

description of a software product in terms of architecture of software
with various components with specified functionality.
The design specification addresses different aspects of the design
model and is completed as the designer refines his representation of
the software. These design documents are written by software
engineers/designers or project managers and further passed to the
software development team to give them an overview of what needs
to be built and how.

[Link] Software Design Document Module, Subpart

01. Reference Documents 1. Existing software documentation

[Link] Software Design Document Module, Subpart

2. System Documentation
3. Vendor(hardware or software) documents
4. Technical reference

1. Processing narrative
Modules for each module 2. Interface description
02. 3. Design language(or other) description
4. Modules used

1. System objective
2. Hardware, software and human interfaces
Scope 3. Major software functions
03. 4. Externally defined database
5. Major design constraints, limitations

1. Data description
Design Description 2. Derived program structure
04.
3. Interface within structure

1. Test guidelines
Test Provisions 2. Integration strategy
05.
3. Special considerations

06. Packaging 1. Special program overlay provisions

2. Transfer consideration

1. External Files structure

File Structure and global data 2. Global data
07.
3. File and data cross – reference

08. Requirement cross-reference 1. cross-reference

Importance of Design Documentation:

1. Requirements are well understood: With proper
documentation, we can remove inconsistencies and conflicts about
the requirements. Requirements are well understood by every team
member.

2. Architecture/Design of product: Architecture/Design

documents give us a complete overview of how the product look like
and better insight to the customer/user about their product.
3. New Person can also work on the project: New person to the
project can very easily understand the project through
documentations and start working on it. So, developers need to
maintain the documentation and keep upgrading it according to the
changes made in the product/software.
4. Everything is well Stated: This documentation is helpful to
understand each and every working of the product. It explains each
and every feature of the product/software.
5. Proper Communication: Through documentation, we have
good communication with every member who is part of the
project/software. Helpful in understanding role and contribution of
each and every member.

Whatisacodereview?

A code review is a peer review of code that helps developers ensure or improve the code quality

before they merge and ship it.

What are code reviews, and how do they work?

Code reviews, also known as peer reviews, act as quality assurance of the code
base.
 Code reviews are methodical assessments of code designed to identify bugs,
increase code quality, and help developers learn the source code.
After a software developer has completed coding, a code review is an important step
in the software development process to get a second opinion on the solution and
implementation before it’s merged into an upstream branch like a feature branch or
the main branch. The reviewer can also act as a second step in identifying bugs,
logic problems, uncovered edge cases, or other issues.

Reviewers can be from any team or group as long as they’re a domain expert. If the
lines of code cover more than one domain, two experts should review the code.

Why are code reviews important?

Developing a strong code review process sets a foundation for continuous

improvement and prevents unstable code from shipping to customers. Code reviews
should become part of a software development team’s workflow to improve code
quality and ensure that every piece of code has been looked at by another team
member.

The code review process is also an important part in spreading knowledge

throughout an organization. For those reasons and more, 76% of developers who
took the 2022 Global DevSecOps Survey said code reviews are “very valuable.”

What are the benefits of code reviews?

 Share knowledge: When software developers review code as soon as a team

member makes changes, they can learn new techniques and solutions. Code
reviews help junior developers learn from more senior team members, similar to
how pair programming effectively helps developers share skills and ideas. By
spreading knowledge across the organization, code reviews ensure that no person
is a single point of failure. Everyone has the ability to review and offer feedback.
Shared knowledge also helps team members take vacation, because everyone on
the team has background knowledge on a topic.
 Discover bugs earlier: Rather than discovering bugs after a feature has been
shipped and scrambling to release a patch, developers can immediately find and
fix problems before customers ever see them. Moving the review process earlier in
the software development lifecycle through unit tests helps developers work on
fixes with fresh knowledge. When waiting until the end of the lifecycle to do a
review, developers often struggle to remember code, solutions, and reasoning.
Static analysis is a cheap, efficient way to meet business and customer value.

 Maintain compliance: Developers have various backgrounds and training that

influence their coding styles. If teams want to have a standard coding style, code
reviews help everyone adhere to the same standards. This is especially important
for open source projects that have multiple individuals contributing code. Peer
reviews bring in maintainers to assess the code before pushing changes.

 Enhance security: Code reviews create a high level of security, especially when
security professionals engage in a targeted review. Application security is integral
in software development, and code reviews help detect security issues and ensure
compliance. Security team members can review code for vulnerabilities and alert
developers to the threat. Code reviews are a great complement to automated
scans and tests that detect security vulnerabilities.

 Increase collaboration: When team members work together to create a solution,

they feel more ownership of their work and a stronger sense of belonging. Authors
and reviewers can work together to find the most effective solutions to meet
customer needs. It’s important to strengthen collaboration across the software
development lifecycle to prevent information silos and maintain a seamless
workflow between teams. To successfully conduct code reviews, it’s important that
developers build a code review mindset that has a strong foundation in
collaborative development.

 Improve code quality: Code reviews are an important way to ensure you ship
high-quality code and quality software. A human who knows your code base can
notice code quality issues that automated tests may miss. They can even help you
reduce technical debt.
 What are the disadvantages of code reviews?

 Longer time to ship: The review time could delay the release process, since
reviewers have to collaborate with authors to discuss problems. Depending on a
reviewer’s workload, they may not complete a review as fast as the author would
like. This challenge can be overcome by using code review tools that include
automated testing to find errors. Automated tooling is an effective way to free up
developer time so that they can focus on the larger software engineering problems
rather than highlight simple lint errors.

 Pull focus from other tasks: Developers often have a heavy workload, and a
code review can pull their focus away from other high priority tasks that they’re
responsible for delivering. Team members may be forced to decide between
completing their task or halting their work in order to do a code review. In either
case, work is delayed somewhere across the organization. To reduce this pain
point, team members can have a reviewer roulette or a list of domain experts so
that a single developer isn’t inundated with review requests.

 Large reviews mean longer review times: If developers have to conduct code
reviews on a large change, they could spend a significant amount of time
examining the code. Large code reviews are challenging to assess, and
developers may naturally move through the process quickly in order to complete it
in a timely manner, resulting in decreased feedback quality. Incremental code
development prevents this challenge by enabling reviewers to look at a small
piece of code several times rather than a large change at once.

Four approaches to code review

Some of these disadvantages can be minimized by selecting the most appropriate

code review method for your team. Here are four common approaches to code
review:
 Pair programming

Pair programming involves two developers collaborating in real time — one writing
code (the driver) and one reviewing code (the navigator). Pairing sessions are
popular with development teams because teammates collaborate to identify the most
effective solution to a challenge. Team members share knowledge and can quickly
overcome difficulties by working through ideas together and drawing on their
expertise.

The benefits of pair programming

 Transfers knowledge

 Prevents information silos

 Solves complex problems

 Increases morale

 Finds more bugs

 Can be conducted remotely

The drawbacks of pair programming

 Time-consuming

 Can be overused

 Difficult to measure

Over-the-shoulder reviews

In an over-the-shoulder-review, two developers — the author and reviewer — team

up in person or remotely through a shared screen and the author explains the
completed change proposal and offers reasoning for the chosen solutions. The
reviewer asks questions and makes suggestions, similar to how team members
collaborate during pairing sessions. The author can make small changes during the
review and note larger fixes for a later time.
 The benefits of over-the-shoulder reviews

 Easy implementation and completion

 Can be conducted remotely

 Faster than pair programming

The drawbacks of over-the-shoulder reviews

 Reviewer is detached from code

 Review moves at the author’s pace

 Lack of objectivity

 No verification that changes were made

 Difficult to measure

Tool-assisted reviews

Teams may decide to use tools to save time and ensure the highest quality code is
shipped. Tool-assisted reviews can automatically gather changed files and display
the differences, or make it easier to provide feedback and have conversations via
comments, and incorporate things like static application security testing (SAST) to
help identify and remediate vulnerabilities.

The best way to look at tool-assisted reviews is to consider them a complement to

other types of reviews. Automated tooling is an effective way to enforce code
standards, identify vulnerability, gather metrics, and gather files, but some teams
may be tempted to completely rely on tooling and forgo team member involvement to
conduct code reviews. Tools should be viewed as an extension of code reviews and
a way to enhance the process.

The benefits of tool-assisted reviews

 Easier to gather metrics

 Automated tooling frees up developer focus

The drawbacks of tool-assisted reviews

 Developers must maintain tools

 Expensive

 Will still require teammate reviews

Email pass-around

Email pass-arounds are often used for minor difficulties and small pieces of code.
They can be conducted via email or source code management systems. During an
email pass-around, an author sends an email containing code changes to reviewers.
Email pass-around is similar to over-the-shoulder reviews in that they can be easily
implemented and don’t require a strong learning curve or a mentoring stage to teach
the author how to make a change.

The benefits of email pass-arounds

 Easy implementation and completion

 Facilitates remote, asynchronous reviews

 Automatic reviews via SCMs

The drawbacks of email pass-arounds

 Time consuming to gather files

 Difficult to follow conversations

 No definite review end date

 No verification that changes were made

 Difficult to measure
 Some best practices for code reviews

 Limit code review sessions to keep them productive. Figure out what works for
your team — say, no more than one hour or 200 lines of code — and encourage
them to stick to that limit.

 Include everyone — including new and senior members of the team — in the
process. Code reviews are an excellent way to help newer members of the team
get up to speed with the code base — both by reviewing code from and having
their code reviewed by more senior developers on the team. Including everyone in
your code review process will also make it easier to adjust when people go on
vacation or are no longer on the team.

 Distribute code review requests amongst the team. It can be easy for a few
developers to get the bulk of code review requests, and this won’t be good for
them or the rest of the team — or the code base — long term. You can create a
list of domain experts or a reviewer roulette to help avoid this.

 Ask questions and provide helpful context. When you’re reviewing someone’s
code, do your best to help both of you learn during the process. Not sure why they
did something a different way than you might have? Ask. Have a suggestion for
how to improve their code? Don’t forget to tell them why you’re suggesting it in
your comment. This will not only help you both learn, but it will likely save time.

Software Testing Metrics, its Types and

Example




Software testing metrics are quantifiable indicators of the software

testing process progress, quality, productivity, and overall health.
The purpose of software testing metrics is to increase the efficiency
and effectiveness of the software testing process while also assisting
in making better decisions for future testing by providing accurate
data about the testing process. A metric expresses the degree to
which a system, system component, or process possesses a certain
attribute in numerical terms. A weekly mileage of an automobile
compared to its ideal mileage specified by the manufacturer is an
excellent illustration of metrics. Here, we discuss the following
points:

Importance of Metrics in Software Testing:

Test metrics are essential in determining the software’s quality and
performance. Developers may use the right software testing metrics
to improve their productivity.
 Early Problem Identification: By measuring metrics such as
defect density and defect arrival rate, testing teams can spot
trends and patterns early in the development process.
 Allocation of Resources: Metrics identify regions where testing
efforts are most needed, which helps with resource allocation
optimization. By ensuring that testing resources are concentrated
on important areas, this enhances the strategy for testing as a
whole.
 Monitoring Progress: Metrics are useful instruments for
monitoring the advancement of testing. They offer insight into the
quantity of test cases that have been run, their completion rate,
and if the testing effort is proceeding according to plan.
 Continuous Improvement: Metrics offer input on the testing
procedure, which helps to foster a culture of continuous
development.

Types of Software Testing Metrics:

Software testing metrics are divided into three categories:

1. Process Metrics: A project’s characteristics and execution are
defined by process metrics. These features are critical to the
SDLC process’s improvement and maintenance (Software
Development Life Cycle).
2. Product Metrics: A product’s size, design, performance, quality,
and complexity are defined by product metrics. Developers can
improve the quality of their software development by utilizing
these features.
3. Project Metrics: Project Metrics are used to assess a project’s
overall quality. It is used to estimate a project’s resources and
deliverables, as well as to determine costs, productivity, and
flaws.
It is critical to determine the appropriate testing metrics for the
process. A few points to keep in mind:
 Before creating the metrics, carefully select your target
audiences.
 Define the aim for which the metrics were created.
 Prepare measurements based on the project’s specific
requirements. Assess the financial gain associated with each
statistic.
 Match the measurements to the project lifestyle phase for the
best results.
The major benefit of automated testing is that it allows testers to
complete more tests in less time while also covering a large number
of variations that would be practically difficult to calculate manually.

Manual Test Metrics: What Are They and How Do They Work?
Manual testing is carried out in a step-by-step manner by quality
assurance experts. Test automation frameworks, tools, and software
are used to execute tests in automated testing. There are
advantages and disadvantages to both human and automated
testing. Manual testing is a time-consuming technique, but it allows
testers to deal with more complicated circumstances. There are two
sorts of manual test metrics:
1. Base Metrics: Analysts collect data throughout the development
and execution of test cases to provide base metrics. By generating a
project status report, these metrics are sent to test leads and
project managers. It is quantified using calculated metrics.
 The total number of test cases
 The total number of test cases completed.
2. Calculated Metrics: Data from base metrics are used to create
calculated metrics. The test lead collects this information and
transforms it into more useful information for tracking project
progress at the module, tester, and other levels. It’s an important
aspect of the SDLC since it allows developers to make critical
software changes.
Other Important Metrics:
The following are some of the other important software metrics:
 Defect metrics: Defect metrics help engineers understand the
many aspects of software quality, such as functionality,
performance, installation stability, usability, compatibility, and so
on.
 Schedule Adherence: Schedule Adherence’s major purpose is
to determine the time difference between a schedule’s expected
and actual execution times.
 Defect Severity: The severity of the problem allows the
developer to see how the defect will affect the software’s quality.
 Test case efficiency: Test case efficiency is a measure of how
effective test cases are at detecting problems.
 Defects finding rate: It is used to determine the pattern of
flaws over a period of time.
 Defect Fixing Time: The amount of time it takes to remedy a
problem is known as defect fixing time.
 Test Coverage: It specifies the number of test cases assigned to
the program. This metric ensures that the testing is completed
completely. It also aids in the verification of code flow and the
testing of functionality.
 Defect cause: It’s utilized to figure out what’s causing the
problem.
Test Metrics Life Cycle:
The below diagram illustrates the different stages in the test metrics
life cycle.

Test Metrics Lifecycle

The various stages of the test metrics lifecycle are:

1. Analysis:
 The metrics must be recognized.
 Define the QA metrics that have been identified.
2. Communicate:
 Stakeholders and the testing team should be informed about
the requirement for metrics.
  Educate the testing team on the data points that must be
collected in order to process the metrics.
3. Evaluation:
 Data should be captured and verified.
 Using the data collected to calculate the value of the metrics
4. Report:
 Create a strong conclusion for the paper.
 Distribute the report to the appropriate stakeholder and
representatives.
 Gather input from stakeholder representatives.
Formula for Test Metrics:
To get the percentage execution status of the test cases, the
following formula can be used:
Percentage test cases executed = (No of test cases executed
/ Total no of test cases written) x 100
Similarly, it is possible to calculate for other parameters also such as
test cases that were not executed, test cases that were passed, test
cases that were failed, test cases that were blocked, and so on.
Below are some of the formulas:

1. Test Case Effectiveness:

Test Case Effectiveness = (Number of defects detected /
Number of test cases run) x 100

2. Passed Test Cases Percentage: Test Cases that Passed

Coverage is a metric that indicates the percentage of test cases that
pass.
Passed Test Cases Percentage = (Total number of tests ran /
Total number of tests executed) x 100

3. Failed Test Cases Percentage: This metric measures the

proportion of all failed test cases.
Failed Test Cases Percentage = (Total number of failed test
cases / Total number of tests executed) x 100

4. Blocked Test Cases Percentage: During the software testing

process, this parameter determines the percentage of test cases
that are blocked.
Blocked Test Cases Percentage = (Total number of blocked
tests / Total number of tests executed) x 100

5. Fixed Defects Percentage: Using this measure, the team may

determine the percentage of defects that have been fixed.
Fixed Defects Percentage = (Total number of flaws fixed /
Number of defects reported) x 100
6. Rework Effort Ratio: This measure helps to determine the
rework effort ratio.
Rework Effort Ratio = (Actual rework efforts spent in that
phase/ Total actual efforts spent in that phase) x 100

7. Accepted Defects Percentage: This measures the percentage

of defects that are accepted out of the total accepted defects.
Accepted Defects Percentage = (Defects Accepted as Valid
by Dev Team / Total Defects Reported) x 100

8. Defects Deferred Percentage: This measures the percentage

of the defects that are deferred for future release.
Defects Deferred Percentage = (Defects deferred for future
releases / Total Defects Reported) x 100

Example of Software Test Metrics Calculation:

Let’s take an example to calculate test metrics:
Data retrieved during
S No. Testing Metric test case development

1 No. of requirements 5

The average number of test

2 cases written per 40
requirement

Total no. of Test cases

3 200
written for all requirements

Total no. of Test cases

4 164
executed

5 No. of Test cases passed 100

 Data retrieved during
S No. Testing Metric test case development

6 No. of Test cases failed 60

7 No. of Test cases blocked 4

No. of Test cases

8 36
unexecuted

Total no. of defects

9 20
identified

Defects accepted as valid

10 15
by the dev team

Defects deferred for future

11 5
releases

12 Defects fixed 12

1. Percentage test cases executed = (No of test cases

executed / Total no of test cases written) x 100
= (164 / 200) x 100
= 82
2. Test Case Effectiveness = (Number of defects detected /
Number of test cases run) x 100
= (20 / 164) x 100
= 12.2
3. Failed Test Cases Percentage = (Total number of failed test
cases / Total number of tests executed) x 100
 = (60 / 164) * 100
= 36.59
4. Blocked Test Cases Percentage = (Total number of blocked
tests / Total number of tests executed) x 100
= (4 / 164) * 100
= 2.44
5. Fixed Defects Percentage = (Total number of flaws fixed /
Number of defects reported) x 100
= (12 / 20) * 100
= 60
6. Accepted Defects Percentage = (Defects Accepted as Valid by
Dev Team / Total Defects Reported) x 100
= (15 / 20) * 100
= 75
7. Defects Deferred Percentage = (Defects deferred for future
releases / Total Defects Reported) x 100
= (5 / 20) * 100
= 25
Conclusion:
Metrics are crucial to software testing in order to assess,
manage and enhance the process. They offer teams useful
information that helps them make better decisions, improves the
quality of the programme and advances the software development
lifecycle as a whole.

Object Oriented Metrics in Software

Engineering




These are used to determine success or failure of a person also to

quantify the improvements in the software throughout its process.
These metrics can be used to reinforce good OO programming
technique which lead to more reliable code. Object-oriented
software engineering metrics are units of measurement that are
used to characterize:
 object-oriented software engineering products, e.g., designs
source code, and the test cases.
 object-oriented software engineering processes, e.g., designing
and coding.
 object-oriented software engineering people, e.g., productivity of
an individual designer.
Why are Object-Oriented Software Engineering Metrics
Different?
OOSE is different because of the following reasons as depicted in the
following figure:

Localization : It is the process of placing items in close physical

nearness to each other.
 Functional decomposition processes localize information around
functions.
 Data-driven approaches localize information around data.
 Object-oriented approaches localize information around objects.
In object-oriented software , from the name suggests the localization
is based on objects. This means:
 Although we may speak of the functionality provided by an
object, atleast some of our metrics identification and gathering
effort must recognize the “object” as basic unit of software.
 Within systems of objects, localization between functionality and
objects is not one-to-one relationships. For example, there are
many objects for one function and also one object can have many
functions.
Encapsulation : It is the packaging of a collection of items.
 Low-level examples of encapsulation include records and arrays.
 Subprograms are mid level mechanisms for encapsulation.
 There are still very long encapsulation mechanisms for the object-
oriented programming languages, e.g., C++’s, classes, Ada’s
packages, and Modula 3’s modules.
 Objects encapsulates:
 Knowledge of state
 Advertised capabilities
 Other objects
 Exceptions
 Constants
 Concepts
Information Hiding: It is the suppression or hiding of the objects.
 We show only the information which is needed to accomplish our
goals.
 Degree of information hiding ranges from partially restricted
visibility to total invisibility.
 Encapsulation and information hiding are not same thing e.g., an
item can be encapsulated but still be to totally visible.
It plays a direct role in such metrics as object coupling and the
degree of information hiding.
Inheritance: It is mechanism where one object acquires the
characteristics from one, or more , other objects.
 Some object-oriented languages support only single inheritance.
 Some object-oriented languages support only multiple
inheritance.
 Inheritance type and their semantics vary from language to
language.
There are many object-oriented software engineering metrics which
are based on inheritance e.g.,
 number of children
 number of parents
 class hierarchy nesting level
Abstraction: It is the mechanism where we focus only on important
details of a concept, while ignoring the in essential details.
 It is a relative concept.
 There are also different categories of abstraction, e.g., functional
data, process and object abstraction.
 Objects are treated as high-level entities in object abstraction.
Classes: There are three commonly used views on the definition for
“class”.
 Class as a cookie cutter: For the structurally identically items, a
class is a pattern, template, or a blueprint. The items which can
be created using class are called instances.
 Class as an instance factory: Basically class is a thing which
contains both a pattern and a mechanism for creating items
based on that pattern and instances are like individual items that
are “manufactured” by using class creation mechanism.
 A class is a set of all the items which are created using a specific
pattern, i.e., the class is the set of all instances of that pattern.