0% found this document useful (0 votes)
89 views26 pages

Software Requirement Specification

This document provides a software requirement specification for a personal software quality tool. It outlines the purpose and scope of developing a tool to calculate and display the code and document quality of developers. It describes the overall system including deployment perspectives, hardware and software requirements. It also includes the functional specifications and requirements of the tool, such as automatically calculating defect density for developers, displaying metrics in a run chart, integrating with JIRA and WBRT data sources, and sending biannual emails to developers with quality reports. Non-functional requirements around the database and exception handling are also documented.

Uploaded by

Rajat Gaur
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
89 views26 pages

Software Requirement Specification

This document provides a software requirement specification for a personal software quality tool. It outlines the purpose and scope of developing a tool to calculate and display the code and document quality of developers. It describes the overall system including deployment perspectives, hardware and software requirements. It also includes the functional specifications and requirements of the tool, such as automatically calculating defect density for developers, displaying metrics in a run chart, integrating with JIRA and WBRT data sources, and sending biannual emails to developers with quality reports. Non-functional requirements around the database and exception handling are also documented.

Uploaded by

Rajat Gaur
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 26

Software Requirement Specification

Software Requirement Specification

Version No.: 0.2

Date: 20 August, 2018

Project Name: Personal Software quality

Project Code: NA

This document contains proprietary information of NEC Technologies India Pvt. Ltd. Unauthorized
access, copying and replication are prohibited. This document must not be copied in whole or part by any
means, without the written authorization of NEC Technologies India Pvt. Ltd, Noida, India.
Personal Software Quality

Revision History

Version Date Author Reviewer Significant Changes

0.1 07/23/2018 Vijesh k Shueb Mohammad Initial Draft

0.2 20/08/2018 Vikas Kumar Shueb Mohammad Requirement Changes

P a g e 2 | 26
Personal Software Quality

Table of Contents

P a g e 3 | 26
Personal Software Quality

DEFINITIONS, ACRONYMS, AND ABBREVIATIONS................................................................................................................4

1 INTRODUCTION.......................................................................................................................................... 5

1.1 PURPOSE.......................................................................................................................................................... 5

1.2 SCOPE.............................................................................................................................................................. 5

2 OVERALL SYSTEM DESCRIPTION................................................................................................................. 6

2.1 SYSTEM OVERVIEW............................................................................................................................................. 6

2.2 PRODUCT PERSPECTIVE........................................................................................................................................6

2.2.1 Deployment perspective.........................................................................................................................6

3 REQUIREMENTS SPECIFICATIONS............................................................................................................... 7

3.1 FUNCTIONAL SPECIFICATION OF TOOL.....................................................................................................................7

3.2 FUNCTIONAL REQUIREMENTS................................................................................................................................7

3.2.1 Use Cases of Features/Functionalities..................................................................................................10

3.3 EXTERNAL INTERFACE REQUIREMENTS SPECIFICATION..............................................................................................14

3.3.1 User Interface Specifications................................................................................................................14

3.3.2 UI Screens.............................................................................................................................................15

3.3.3 Use Case Screen Mapping....................................................................................................................17

3.4 NON FUNCTIONAL REQUIREMENTS......................................................................................................................17

3.4.1 Logical Database Requirements...........................................................................................................17

3.4.2 Exception Handling...............................................................................................................................17

P a g e 4 | 26
Personal Software Quality

Definitions, Acronyms, and Abbreviations

Abbreviation Description
PL Project Lead

PM Project Manager

Org Organization

BD Basic design

FD Functional Design

DD Detail Design

CD Coding

1H First Half(year)

P a g e 5 | 26
Personal Software Quality

1.Introduction
1. Purpose
The objective of this document is to Check the code quality of Developer in Coding phase and
Document quality in different testing phases like UT, FT, ST etc.

2. Scope

To calculate and show the Document and Code quality of the developers. The document quality and
code quality will be displayed in a dashboard. This will be calculated according to all the work products
that the developer worked on in the previous years.

P a g e 6 | 26
Personal Software Quality

2.Overall System Description


1. System overview

The PSQ will be used to keep track of the developer’s product quality. The product quality given
by the developer is calculated on behalf of the defects he/she made compared with the target
defect the organization allotted to the particular developer. The yearly quality are shown with
trend charts. And the quality track of the developer of every 6 months is mailed to the developer.

2. Product Perspective

1.Deployment perspective

1. Hardware Requirements

Hardware Specifications Description

RAM 1 GB RAM will be required with This is standard minimum


at least 200 MB free space. requirement to run any tool.

Processor 1 gigahertz (GHz) or faster 32- This is standard minimum


bit (x86) or 64-bit (x64) requirement to run any tool.
processor will be required to
run the application.

Hard Disk 150 MB free space to install the This is standard minimum
application requirement to run any tool.

2. Software Requirements

Interface Version Purpose

Software Tomcat Apache 8 Development

P a g e 7 | 26
Personal Software Quality

server

Database MySQL 5.7.19 Data extraction.

Tools Eclipse Luna 4.4.1 Development tool. All


the coding is done in
eclipse.

SQL Workbench 6.1 CE For accessing databases.

P a g e 8 | 26
Personal Software Quality

3.Requirements Specifications

1. Functional Specification of Tool

Serial No Functional Specification of Tool

1 All developers of NTI are in Scope

2 Tool will calculate automatically Defect density(DD) of every developers


of coding phase.

3 Tool will be showing above said metrics to every developer in form of a


run chart.

4 To calculate these performance metrics, Tool will be pull the data from
JIRA and WBRT.

5 Actual effort, Testing defect is available in JIRA while Review defect and
size is available in WBRT.

6 Tool will showing these data for last 10 projects in below run chart in a
pop up.

2. Functional Requirements

S. No. Requirements

1 All developers of NTI are in Scope

2 Tool will calculate automatically Defect density (DD) of every developers of coding phase.

P a g e 9 | 26
Personal Software Quality

3 Tool will be showing above said metrics to every developer in form of a run chart.

4 To calculate these performance metrics, Tool will take the data from JIRA and WBRT.

Actual effort, Testing defect is available in JIRA while Review defect and size is available in
WBRT.

5 Developers will receive a mail on every 6 months as per screen.

6 The screen will show the Document Quality Table, Document quality trend and Document
quality meter as well as Code Quality Table, Code quality trend and Code quality meter.
And the developer’s name will be displayed in bold font.

7 Document quality table

7.1 Year will be displayed in increasing trend.

7.2 Year will start from 2016-1 H (1 H is from April to September and 2 H is from October to
March).

7.3.1 Target (USL) is Set by the individual for every half yearly duration and once it is set, it
will be fixed for that duration

7.3.2 If the Individual does not set his/her Target value then Org Target (USL) will be set as
Default value by Org which will be fixed for that duration and will be same for all
developers.

7.4 Document quality is defect density of Requirement phase, HLD Phase & LLD phase and
for every half year it is calculated.

P a g e 10 | 26
Personal Software Quality

7.5.1 All defects in which developers were identified as Author in WBRT will be taken into
consideration.

7.5.2 Defects should be filtered according to below rules

7.5.3 Major and minor defects

7.5.4 Defects which are valid

7.5.5 Defects which are not duplicate

7.5.6 Phase identified as BD, FD, and DD and consider as Detected Phase

7.7 Defect density of author is calculated as total defects (After applying Rule1 &
Rule2)/ Size of work product.

Example: in one review plan size id 10 pages and total defects count is 15 then defect
density would be 15/10 1.5 defects/Pages

7.8 Similarly for every work product and every review plan defect density will be
calculated.( Graph will be taken as Review end date plan wise )

7.9 Total Average defect density per 1H of above document quality will be calculated and
displayed in the table.

8 Code quality table

8.1 Year will be displayed in increasing trend.

P a g e 11 | 26
Personal Software Quality

8.2 Year will start from 2016-1 H (1 H is from April to September and 2 H is from October to
March).

8.3.1 Target (USL) is Set by the individual for every half yearly duration and once it is set, it
will be fixed for that duration

8.3.2 If the Individual does not set his/her Target value then Org Target (USL) will be set as
Default value by Org which will be fixed for that duration and will be same for all
developers.

8.4 Code quality is defect density of CD phase and for every half year, code quality will be
calculated.

8.5.1 All defects in which developers were identified as Author in WBRT will be taken into
consideration.

8.5.2 Defects should be filtered according to below rules

8.5.3 Major and minor defects

8.5.4 Defects which are valid

8.5.5 Defects which are not duplicate

8.5.6 Phase identified as CD; Only these kind of defects are considered.

8.7 Defect density of author is calculated as total defects (After applying Rule1 & Rule2)/
Size of work product.

P a g e 12 | 26
Personal Software Quality

8.8 Similarly for every work product and every review plan defect density will be
calculated.(Graph will be taken as Review end date plan wise )

8.9 Total Average defect density per 1H of above Code quality will be calculated and
displayed in the table.

9 Document Quality Trend

9.1 Org Target (USL) or User Set Target will be displayed in red color in a line chart.

9.2 Document quality will be displayed in Blue color in same line chart.

9.3 This chart must be time sequence.

9.4 This chart will show data of last 1 year.

9.5.1 Document quality table will show data of last 2 years

9.5.2 Color Specification of Document quality table

9.5.3 If the Defect Density is less than Set Target then it is shown in Green Color on
Document quality table.

9.5.4 If the Defect Density is Greater than Set Target then it is shown in RED Color on
Document quality table.

10 Code Quality Trend

10.1 Org Target (USL) will be displayed in red color in a line chart.

10.2 Code quality will be displayed in Blue color in same line chart.

10.3 This chart must be time sequence.

P a g e 13 | 26
Personal Software Quality

10.4 This chart will show data of last 1 year.

10.5.1 Code quality table will show data of last 2 years

10.5.2 Color Specification of Code quality table

10.5.3 If the Defect Density is less than Set Target then it is shown in Green Color on Code
quality table.

10.5.4 If the Defect Density is Greater than Set Target then it is shown in RED Color on
Code quality table.

11 Document Quality Meter

Based on the latest current value, meter will show whether it is in green zone or red zone
and It will be consider as Year wise.

12 Code Quality Meter

Based on the latest current value meter will show whether it is in green zone or red zone
and It will be consider as Year wise.

13 Raw data file

The mail system will send raw data file to developers of last 2 year which will be showing
Document and code quality details with project name, work product, Phase, reviewer
names and size.

P a g e 14 | 26
Personal Software Quality

1.Use Cases of Features/Functionalities

1. Performance dashboard

Use Case Name Personal Software Quality Dashboard

Use Case ID UC001

Overview Developers will be able to see their personal software quality performance in
the dashboard.

Preconditions 1. Defects in document and code are collected for that specific developer
of past 2 years.

2. Document and code quality is calculated.

Author Developer

Outcome Successful display of developer performance metrics.

Exception(s)

Notes -

P a g e 15 | 26
Personal Software Quality

2. Document Quality table

Use Case Name Defects calculation for document quality table

Use Case ID UC002

Overview Defect density of an author is calculated as total average defects in 1H

Preconditions 1. Defect record in previous years is collected for the corresponding


developer.

Author -

Outcome Document Quality table

Exception(s) -

Notes -

Steps

1. Defect density of author is calculated as total defects.


2. e.g. in one review plan, size is 10 pages and total defects count is 15 then defect density would
be 15/10 1.5 defects/Pages.

3. Code Quality Table

Use Case Name Defects calculation for Code quality table

P a g e 16 | 26
Personal Software Quality

Use Case ID UC003

Overview Defect density of author is calculated as total average defects in 1H

Preconditions 1. Defect record in previous years is collected for the corresponding


developer.

Author

Outcome Code Quality Table

Exception(s)

Notes -

Steps

1. Defect density of author is calculated as total defects.


2. E.g. in one review plan, size is 1200 LOC and total defects count is 15 then defect density would be 15/1.2
i.e. 12.5 defects/KLOC.

4. Document Quality Trend

Use Case Name Document Quality Display with trend lines

Use Case ID UC004

Overview The developer’s defect density in Documents is compared with org’s/set target
defect using trend lines.

Preconditions 1. Defect density of the documents of the developer is calculated.

P a g e 17 | 26
Personal Software Quality

Author

Outcome Displaying Document Quality using trend lines.

Exception(s) -

Notes -

Steps

1. Defect density of the developer is calculated.


2. Set/Org Target (USL) will be displayed in red color in a line chart.
3. Document quality will be displayed in Blue color in same line chart.
4. This chart must be time sequence and will show the past 1 years data.

5. Code Quality Trend

Use Case Name Code Quality Display with trend lines

Use Case ID UC005

Overview The developer’s defect density in Code is compared with org’s/set target defect
using trend lines.

Preconditions 1. Defect density of the Code of the developer is calculated.

Author

Outcome Displaying Code Quality using trend lines.

Exception(s) -

Notes -

Steps

P a g e 18 | 26
Personal Software Quality

1. Defect density of the developer is calculated.


2. Set/Org Target (USL) will be displayed in red color in a line chart.
3. Code quality will be displayed in Blue color in same line chart.
4. This chart must be time sequence and will show the past 1 years data.

6. Document Quality Meter

Use Case Name Document Quality meter

Use Case ID UC006

Overview On behalf of defect density calculated on documents of the developer a


quality meter is displayed.

Preconditions 1. Defect density of the documents of the developer is calculated.

Author

Outcome Displaying quality meter for developer’s status on behalf of calculated defect
density.

Exception(s) -

Notes -

Steps

P a g e 19 | 26
Personal Software Quality

1. Based on the latest current value, meter will show whether it is in green zone or red zone.

7. Code Quality Meter

Use Case Name Code Quality meter

Use Case ID UC007

Overview On behalf of defect density calculated on codes of the developer a quality


meter is displayed.

Preconditions 1. Defect density of the codes of the developer is calculated.

Author

Outcome Displaying quality meter for developer’s status on behalf of calculated defect
density.

Exception(s) -

Notes -

Steps

1. Based on the latest current value meter will show whether it is in green zone or red zone.

P a g e 20 | 26
Personal Software Quality

8. Mailing the data

Use Case Name The performance status is sent in every 3 months to the developer.

Use Case ID UC008

Overview With mail system will send raw data file to developers of last 2 year which
will be showing Document and code quality details with project name,
work product, Phase, reviewer names and size.

Preconditions

Author

Outcome Through mail every 3 months the developer’s status is shared.

Exception(s) -

Notes -

Steps

3. External Interface Requirements Specification

1.User Interface Specifications


Screen1: Personal Software quality dashboard

P a g e 21 | 26
Personal Software Quality

Screen2: Document and Code Quality Table

Screen3: Document and Code Quality Trend

Screen4: Document and Code Quality Meter

2.UI Screens

1. Personal Software Quality Dashboard

P a g e 22 | 26
Personal Software Quality

Document and Code Quality Table

Document Quality Table Code Quality Table

P a g e 23 | 26
Personal Software Quality

2. Document and Code Quality Trend

Document Quality Trend Code Quaitly Trend

P a g e 24 | 26
Personal Software Quality

3. Document and Code Quality Meter

3.Use Case Screen Mapping

P a g e 25 | 26
Personal Software Quality

Serial No. Use Case ID Screen Name/ID

1 UC001 Screen1

2 UC002,UC003 Screen2, Screen 3

3 UC004,UC005 Screen4, Screen 5

4 UC006,UC007 Screen6

4. Non Functional Requirements

1.Logical Database Requirements

2.Exception Handling
NA

P a g e 26 | 26

You might also like