SRS_v4.2

8/2/2019 SRS_v4.2

http://slidepdf.com/reader/full/srsv42 1/25

SRS Document

1

A Software Engineering Project

Software Requirements Specification (ver. 4.1)

Project Manager: Andy

Project Name: QA Quetzals

Company Name: At-A-Glance Software

Contributors: Rani, Sudheera, Ambica, Rama & Robert

Class: CS532, Concepts of Software Engineering – Summer ‘10

8/2/2019 SRS_v4.2


SRS Document

2

Submitted To Customer: Professor Robert Zhu

Date: Saturday, June 7th 2010

Table of Contents

1. Introduction ...............................................................................................................................4 1.1 Purpose.......................................................................................................................................... 4 1.2 Document Conventions ................................................................................................................. 4 1.3 Intended Audience ........................................................................................................................ 4

1.4 Project Scope & Vision .................................................................................................................. 4

1.4.1 Goals .......................................................................................................................... 6

1.4.2 Market Context .......................................................................................................... 8

1.4.3 Stakeholders .............................................................................................................. 8

1.4.4 Key Features .............................................................................................................. 8

1.4.5 Constraints ............................................................................................................... 101.4.6 Appendix & Use Cases ............................................................................................. 10

1.5 References ................................................................................................................................... 12

2. Overall Description ................................................................................................................133 2.1 Product Perspective..................................................................................................................... 13 2.2 Product Features.......................................................................................................................... 13 2.3 User Classes and Characteristics.................................................................................................. 14 2.4 Operating Environment ............................................................................................................... 16 2.5 Design and Implementation Constraints ................................................................................... 187 2.6 User Documentation.................................................................................................................. 187 2.7 Assumptions and Dependencies................................................................................................ 187

3. System Features.......................................................................................................................19 3.1 System Feature 1 ....................................................................................................................... 209 3.2 System Feature 2 ....................................................................................................................... 209

4. External Interface Requirements ............................................................................................20 4.1 User Interfaces............................................................................................................................. 20 4.2 Hardware Interfaces .................................................................................................................. 222 4.3 Software Interfaces...................................................................................................................... 21 4.4 Communications Interfaces......................................................................................................... 21

5. Other Nonfunctional Requirements .......................................................................................22 5.1 Performance Requirements....................................................................................................... 232 5.2 Safety Requirements.................................................................................................................. 232 5.3 Security Requirements............................................................................................................... 232 5.4 Software Quality Attributes....................................................................................................... 232

6. Other Requirements..............................................................................................................232

7. Appendixes ................................................................................................................................237.1 Appendix A: Glossary ...................................................................................................................... 237.2 Appendix B: Analysis Models .......................................................................................................... 237.3 Appendix C: Issues .......................................................................................................................... 23

8/2/2019 SRS_v4.2


SRS Document

3

Revision History

Name Date Reason For Changes Modified By Version

SRS v4.2.doc July 23rd

,2010 Use case correction Ranjeeta 4.2

SRS v4.1.doc July 16th, 2010 Finalization for Mid-Term 2 Rama 4.1

SRS v4.doc July 16

th

, 2010 Addition of Diagrams Rama 4.0SRS v3.doc July 7

th, 2010 Addition of Requirements Rama 3.0

SRS v2.doc July 3rd

, 2010 Submitting to Professor Robert Zhu Andy 2.0

Requirement v1.doc June 30th, 2010 Initial Verbal Customer Requirement Andy 1.0

8/2/2019 SRS_v4.2


SRS Document

4

1. Introduction

1.1 Purpose

This project is undertaken to develop a graphical user dashboard interface that reports statuses of bugsarising from multiple on-going projects within an organization. The graphical user dashboard interface is

simple, inexpensive, convenient and user-friendly tool that can be used by the upper management to

review the bug trends within a particular software project. It provides a report of the overall bug status

information ‘at a glance’ in the form of charts, graphs, and reports. Decision making is enhanced and

simplified.

1.2 Document Conventions

This SRS document does not contain any standards or typographical conventions. Every requirement

statement is to have its own priority.

1.3 Intended Audience

The different types of readers intended for this SRS document are HGU students, professors, teaching

assistants, developers, project managers, marketing staff, users, testers, and documentation writers.

1.4 Project Scope & Vision

The software system specified here is used to deliver the output in a GUI format to the end user. Its main

purpose is to test, identify and report bugs in a software product. This is of great benefit to the upper

management staff in a company. It not only reduces the time involved in transfer of data and information

from different levels of hierarchy in the project development life-cycle, but also gives the President or

the CEO an instant birds-eye view of the overall health of the organization. The goal of this software

system is to be able to track and report all the bugs in multiple software products in a resourceful and

well-organized way to its user so that the user can use that information to make important decisions

8/2/2019 SRS_v4.2


SRS Document

5

regarding an organization’s future.

The high-level diagram of the software system is as follows:

Manual

Testing

Test OK?

Modify Code

Fail

Pass

Projects

(Java/Web-

App)

Report Bug

To JIRA

Product

Release

Query JIRA

DB / My SQL

Data Base

Dash Board

Integrator

43

12

Project vs. Defect Graph

4

12

3

P1 Issues Graph

30%

45%

15%

10%

Bug Criticalities

Pie Chart

3

1

4

2

BRR Graph

System High Level

Diagram

Context models are used to illustrate the operational context of a system. It is the highest level view of a

system similar to the block diagram which depicts system as a whole and its inputs and outputs from/to

external factors that lies outside the system boundaries.

The User interacts with Dashboard Tool which derives inputs from databases and QA testing tool, Checks

security & safety policies for influence of external factors, Processes data in Data processing unit,

Displays GUI content output using reporting tool and maintains the system as a whole using

maintenance system.

The Context model of the system is as follows:

8/2/2019 SRS_v4.2


SRS Document

6

DashboardTool

JIRA DBMy SQL

ReportingTool

QATesting Tool

DataProcessing

Unit

MaintainenceSystem

Safety&

SecurityPolicies

Context Model

1.4.1 Goals

To produce a user interface dashboard style product based on the application of software engineering

principles and models. Follow the Software Engineering philosophy of the OMG by producing first a V-Model to facilitate the development process. The software testing platform will be performed in a

manual testing environment that uses JIRA bug tracking software and Java technology will be used for

coding purposes. The system will use a simple user Id and password mechanism to log in.

Advantages and Disadvantages of V-Model are as follows:

Advantages:

1. Proactive defect tracking wherein defects are found at early stages even may be in the development

phase before application is tested.

2. Avoids the downward flow of the defect

3. Reduces the cost for fixing the defect since defects will be found in early stages

4. It is a fast method.

5. It is also called as verification and validation Model.

8/2/2019 SRS_v4.2


SRS Document

7

6. This means the verification and validation will be done side by side.

7. It emphasis the strict process flow to develop a quality product.

8. The errors occurred in any phase will be corrected in that phase itself.

V-Model

SRS/Defect

Vs Project

System

Test Plan

Integ Test

Planning

Unit Test

Planning

System

Testing

HLD/Data

flow

In the

Integ

Testing

LLD/Data

Type,

Variables,

Unit

Testing

Project

(Java)

Classes

UATUAT

PlanningDashbo

Deliver

BRD/Historical &

Defect resolution

rate

Maintenanc

&

Enhanceme

8/2/2019 SRS_v4.2


SRS Document

8

Disadvantages:

1. It is rigid and least flexible.

2. Requires more people to work.

3. It needs lot of resources and money.

4. It needs an established process to implement.

5. It can be implemented by only some big companies.

1.4.2 Market Context

The equipment currently on market does not support features that provide the people in the upper

management level to check the overall system or project status for on-going software projects in their

company. This technology has just begun the start of its useful life, making it likely to support updates in

the near future. On the other hand this technology has immense need in the market to put us at a

competitive advantage if implemented now.

1.4.3 Stakeholders

Among the stakeholders for this system are the Computer Science and Engineering Department. The list

of the stakeholders and the specific individuals representing them are.

Computer Science Engineering. Zhu, Robert

1.4.4 Key Features

The following are the key features of the software product:

A convenient user-friendly UI tool to allow the customer to obtain reports for each project.

Check the overall project status for each and every on-going project in the company.

8/2/2019 SRS_v4.2


SRS Document

9

LOGINLIST OF

PROJECTS

PROJECTS VSDEFECTS

PROJECTINFORMATION

TEAMINFORMATION

BUGRESOLUTION

RATE

CRITICAL VSNON

CRITICAL

PIE CHARTS

HISTORICALGRAPHS

DAILY/WEEKLY/MONTHLY

GUI COMPONENT DIAGRAM

Sign in

Sign off

ClicktheGraph

SelectProject

GUI Component Diagram

Data flow diagram

INPUTPARAMETERS

REQUIRMENT /TESTANALYSIS

FINDINGBUGS

JIRA DATABASE

JIRADASHBOARD

OUTPUTGRAPHS

Requirement Test case

Jira bug tool

Open source

Historical/Bug resolution graphs

Infrastructure

Data Flow Diagram

8/2/2019 SRS_v4.2


SRS Document

10

1.4.5 Constraints

This project must be completed within two months or before August 21st

2010. The basic architecture as

well as the infrastructure needed will be designed in-house. Close liaison will be maintained between the

software design, development and testing of the user interface tool. Neither the software nor the user

interface shall be considered the independent variable, but rather they should be considered equal.

1.4.6 Appendix

The following are the actors that directly support this vision. Additional actors may be identified later

that are needed to support this or that technology. They should not be added to this list unless they are

deemed to directly support the vision as described in this document.

• Computer Science Department

• Customer. Zhu, Robert

The following are the use cases that directly support this vision. Additional use cases may be identified

later that is needed to support this or that technology or to support the use cases listed here. They

should not be added to this list unless they are deemed to directly support the vision as describe in this

document.

Customer uses dashboard by logging in

Customer views list of on-going projects

User Log In

& Password

Dashboard

8/2/2019 SRS_v4.2


SRS Document

11

User Interface to display the graphs of the selected project

Dashboard Project Vs

Defect

Team Info

Historical

Graph

List of

Project 1

Project 2

Project 3

Project n

User

Dash

boar

Defect Vs

Project

User

8/2/2019 SRS_v4.2


SRS Document

12

1.5 References

This SRS refers to the project located at following web address: http://code.google.com/p/at-a-glance/

All documents including the project-plan, project scope and vision, use case documents, interface guides,

software and tools, including title, author, version number, date and source or location can be found on

this website for your reference.

Dashboard Project Vs

Defect

Rate

resolution

User

http://code.google.com/p/at-a-glance/




8/2/2019 SRS_v4.2


SRS Document

13

2. Overall Description

2.1 Product Perspective

At a Glance is an innovative product for higher management in an organization to identify the state of

the application. It is intended to implement the entire bug tracking features. This product is using Javaplatform and the JIRA bug tracking tools. This product imports all the necessary java packages that areneeded for task. The possible extension for this product is connecting to multiple bug reporting tools.

Defect tracking is a critical component to a successful software quality effort. Software defect data is themost important available management information source for software process improvement decisions,ignoring defect data can lead to serious consequences for an organization's business. Defect trackingdashboard is a web-based defect and bug tracking solution to track product defects and manage productenhancement requests. Follow the defect resolution process and work the defect from initiation toclosure, enhancing product quality and customer satisfaction. Dashboard contains KPIs, metrics, charts,trends and data visualizations.

2.2 Product Features

See Appendix B

2.3 User Classes and Characteristics

An association model:

Associations indicate that an attribute of an object is an associated object or that a method relies on an

associated object.

8/2/2019 SRS_v4.2


SRS Document

14

Login

HomePage DashBoard

Statusaccess

generates

displays

An association model

Associations are indicate that an attribute of an object is an associated object

or that a method relies on an associated object.

Association Model

Sub-System Model:

8/2/2019 SRS_v4.2


SRS Document

15

Sub-System InterfacesSub-Systems

Data Collection

Sub-Systems Applications/Gadgets

CommunicationInterfaces

DashboardUI Interface

Databases

QA Tool

Test PlanTest Cases

InputParameters

SecurityPermissions

JDBCJQL

JIRAReport

Collector

Sub-System Model

Class Diagram:

A class is a system entity that models a real-world object. Login, Homepage , Dashboard and Status are

classes. A class is made up of attributes which define the information that each class knows about itself

and operations which are the processes that a class can carry out. Often you will see operations referred

to as methods.

8/2/2019 SRS_v4.2


SRS Document

16

Class Diagram

State Diagram:

Shows how objects respond to different service requests and the state transitions triggered by these

requests.

8/2/2019 SRS_v4.2


SRS Document

17

State Diagram

Login Waiting

DashBoard Status

signOut

getProj()

signOut()

getStatus()

goHome()

goHome()

Validate()

Graphs

drawGraph()

Charts

drawChart()

initialstate

Shows how objects respond to different service requests and the statetransitions triggered by these requests.

Status complete

Displays graphs

in dash board

State Diagram 2.4 Operating Environment

The environment in which software will operate and other software components or applications with

which it will co-exist are as follows:

Operating System: Windows XP/Vista or higher

Hardware platform (Minimum requirements): Quad/Dual core 2.0 GHz processor, 512MB RAM, 250GB

HDD

Programming language: Java (JDK 1.5), JQL (JIRA Query Language)

Programming Platform: Eclipse IDE

Application server: Apache Tomcat

DB: JIRA Standalone or WAR/EAR (Inbuilt)/ My SQL

Browsers: Internet Explorer/Mozilla F irefox

QA Tools:

Bug Tracking Tools: JIRA

Communication Tools: WebExSubversion Tool: Tortoise SVN

Reporting Tools: JIRA

8/2/2019 SRS_v4.2


SRS Document

18

2.5 Design and Implementation Constraints

The following are the design and implementation constraints that might limit the options available to the

developers and UI designers are as follows:

Corporate policies: Atlassian's regulatory policies

Databases: Memory constraints in JIRA (need to take frequent back-ups)

Design Conventions: Limited customization of filters/permissions (Due to trail version)

Security considerations: Inbuilt Atlassian's security advisories

2.6 User Documentation

There are no user documentation standards or components such as manuals, online help, and tutorials

available for delivery along with this software.

2.7 Assumptions and Dependencies

There are no assumed factors (as opposed to known facts) that could affect the requirements stated in

the SRS. The project has no dependencies on external factors, such as software components reuse from

another project.

Task dependencies and Activity Network Diagram indicating critical path are as follows:

Tasks

Work

Breakdown

Task

Description

Duration

(days) DependenciesT1 Andy Client Interview 3

T2 All Feasibility Study 4

T3 All Requirements Analysis 12

T4 Andy Project Planning 7

T5 All Process Flows 3 T1,T2,T3(M1)

T6 Ambica/Andy

Object Oriented

Analysis 3 T5(M3)

T7 All System Models 7 T5,T6(M2)

T8 Rani Manual Testing 10

T9 Rani/Andy Bug Reporting 7 T8(M4)

T10 Rama/Sudheera UI Integrating 12 T1,T3,T4(M5)T11 All Final Delivery 3 T7,T9,T10(M6)

Critical Path = 27 Days

8/2/2019 SRS_v4.2


SRS Document

19

Start

Task 4 Task 3

Task 1

Task 2Task 8

Task 10

Task 7

Task 9

Task 6

Task 5

M5

M3

M6M2M1

M4

Task 11 Finish

7 Days 12 Days

3 Days

4 Days

10 Days

12 Days

3 Days

7 Days

3 Days

3 Days7 Days

Activity Network Diagram

8/2/2019 SRS_v4.2


SRS Document

20

3. System Features

This section illustrates the functional requirements for the product by system features, the major

services provided by the dashboard product.

3.1 System Feature 1

3.1.1 Description and Priority

NA

3.1.2 Stimulus/Response Sequences

NA

3.1.3 Functional Requirements

REQ-1: Login page requirement: (Fields: User ID and Password).

o User ID field name must be displayed as “User ID” in the UI.

o User ID field is allowed to have only of the following characters: [0-9], [A-Z], [a-z], Special

characters allowed are: underscore (_) and period (.)

o User ID must be of minimum length of 5 characters.

o User ID must be of maximum length of 10 characters.

o The system must display the following error message if the user ID entered is not valid.

o “User ID Invalid”

o Password should be minimum 4 characters long.

o Password can include alphabets, Upper case, Lower case, Numeric and special

characters.

o The user should be allowed to access the application with correct Login.

o The user should not be allowed to access the application with incorrect Login.)

REQ-2: UI page requirement: (Dashboard page fields)

o User should be able to see the fields on the dashboard like PROJECTLIST, RELEASES, and

GRAPH.

o Dashboard should have an option to select RELEASES.

o When GRAPH is selected the user can see a graph with Project Release Date in ‘X’ axis

and Defects in ‘Y’ axis.

3.2 System Feature 2

More system features will be added following the design process.

8/2/2019 SRS_v4.2


SRS Document

21

4. External Interface Requirements

4.1 User Interfaces

User interface of an application will make or break. Although the functionality that JIRA tool provides to

user is important, the way in which it provides that functionality is also important. So we follow the GUIstandards in following points in designing the dashboard and the user interface.

Concise, numbered guidelines

Navigation b/w major interface items & navigation with in a screen

Wording messages and labels

Quality assurance checklist

Align fields effectively & Justify data appropriately

Visual design patterns to solve common design problems

Comprehensive, customizable administration tools

Common buttons on forms

Drop down menus

Tool bars, Menu design

Security to ensure the quality of the content

User Interface with JIRA: Web, email, workflow, My SQL/ JDBC, Excel

Standard buttons and functions appear on each screen: Proposed tabs in dashboard are as follows

Home or Dash boards & Gadgets

Browse List of Project

Find P1 Issues

View historical data and BRR graph for each project

Software components: JAVA, JAVA API, LDAP, Clear case, My SQL/ Oracle

Reports/ Figures: The reports need to be created in a variety of dimensions, including pie chart, linear or

column graphs, and statistical tables. Data should reflect the amount of issues for each individual

customer, the number of issues reported over a specific time frame - such as day, week, month or year,

8/2/2019 SRS_v4.2


SRS Document

22

the average time to resolve an issue, and many other options.

4.2 Hardware Interfaces

There is no communications protocol and hardware interface characteristics implementation of the

dashboard product.

4.3 Software Interfaces

Operating system requirements: Windows XP or higher Database requirements: Using inbuilt databases that comes with the bug tracking tool Tools: A bug tracking tools like JIRA Library requirements: Proposed to use java libraries Incoming messages: No specific user defined messages: But this tool will display the graphical

representation of the defect trends in the form of graphs, charts for selected period of time Information related to the defects will be shared across the software components. No implementation constraints identified by this time.

4.4 Communications Interfaces

The following are the communications functions such as email, web browser, network communications

protocols and other inbuilt communication interfaces to be used:

Communication Platform: WebEx, Google Code

Mail Clients: Microsoft Outlook Express, Google

Web Browsers: Internet Explorer6.x or higher, Mozilla Firefox3.0 or higher

Networking protocols: FTP, HTTP, SMTP

Other Communication Interfaces: Inbuilt JIRA gadgets/plug-ins

8/2/2019 SRS_v4.2


SRS Document

23

5. Other Nonfunctional Requirements

5.1 Performance Requirements

As of now there are no performance requirements for the product under various circumstances.

5.2 Safety Requirements

The database is stored in multiple data centers across the company’s network and would be accessed

from any geographical location.

The Disaster recovery site has been setup to back-up data for any possible loss or damage if incurred

during any natural disaster.

5.3 Security Requirements

The software product will have a simple user Id and password screen to authenticate the user

information and will not be accessible to non-managerial staff thereby restricting editing/viewing of

dashboard pages.

The database is securely stored and has a full 128 bit SSL encryption model supporting the security

requirements.

Documenting company's security policies & procedures for effective security implementations.

Encapsulation and encryption features available for data/file transfer.

Security measures from potential intrusive threats and hardware/software crashes.

5.4 Software Quality Attributes

A desired combination of quality attributes focused for this project is its timeliness, ease of use,

interoperability of the dashboard tool. This combination tradeoff not only satisfies the user requirements

and ensures a better quality system but also; reaps the long-term benefits of improving the customer's

ROI.

6. Other Requirements

No other requirements exist outside the scope of this SRS document, such as internationalization

requirements, legal requirements, reuse objectives for the project, and so on.

8/2/2019 SRS_v4.2


SRS Document

24

Appendix A: Glossary

The following are the interpretation of terms, acronyms and abbreviations for this SRS document:

JQL JIRA Query Language

Appendix B: Analysis Models

Appendix C: Issues List

The first and final release for this product is planned to be in August 21st

, 2010. The project has some

open requirements issues that remain to be resolved. Information is needed on what is the optimumway to connect the JIRA bug tracking tool to a dashboard reporting software tool. The conflicts awaiting

resolution are whether to use Database management or XML based data from the tracking tool software

to read the input into the final output display board.

8/2/2019 SRS_v4.2


SRS Document

Documents

SRS_v4.2