This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
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
http://slidepdf.com/reader/full/srsv42 4/25
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
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
http://slidepdf.com/reader/full/srsv42 5/25
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
http://slidepdf.com/reader/full/srsv42 6/25
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
http://slidepdf.com/reader/full/srsv42 7/25
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
http://slidepdf.com/reader/full/srsv42 8/25
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
http://slidepdf.com/reader/full/srsv42 9/25
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
http://slidepdf.com/reader/full/srsv42 10/25
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
http://slidepdf.com/reader/full/srsv42 11/25
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
http://slidepdf.com/reader/full/srsv42 12/25
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
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
http://slidepdf.com/reader/full/srsv42 14/25
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
http://slidepdf.com/reader/full/srsv42 15/25
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
http://slidepdf.com/reader/full/srsv42 16/25
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
http://slidepdf.com/reader/full/srsv42 17/25
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
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
http://slidepdf.com/reader/full/srsv42 21/25
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
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
http://slidepdf.com/reader/full/srsv42 22/25
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
http://slidepdf.com/reader/full/srsv42 23/25
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
http://slidepdf.com/reader/full/srsv42 24/25
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.