Sie sind auf Seite 1von 25

SRS Document

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

SRS Document

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............................................................................................................... 10 1.4.6 Appendix & Use Cases ............................................................................................. 10 1.5 References ................................................................................................................................... 12 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 Product Perspective ..................................................................................................................... 13 Product Features.......................................................................................................................... 13 User Classes and Characteristics .................................................................................................. 14 Operating Environment ............................................................................................................... 16 Design and Implementation Constraints ................................................................................... 187 User Documentation.................................................................................................................. 187 Assumptions and Dependencies................................................................................................ 187 System Feature 1 ....................................................................................................................... 209 System Feature 2 ....................................................................................................................... 209 User Interfaces ............................................................................................................................. 20 Hardware Interfaces .................................................................................................................. 222 Software Interfaces ...................................................................................................................... 21 Communications Interfaces ......................................................................................................... 21

2. Overall Description ................................................................................................................133

3. System Features.......................................................................................................................19 4. External Interface Requirements ............................................................................................20

5. Other Nonfunctional Requirements .......................................................................................22


Performance Requirements ....................................................................................................... 232 Safety Requirements.................................................................................................................. 232 Security Requirements............................................................................................................... 232 Software Quality Attributes ....................................................................................................... 232

6. Other Requirements ..............................................................................................................232 7. Appendixes ................................................................................................................................23


7.1 Appendix A: Glossary ...................................................................................................................... 23 7.2 Appendix B: Analysis Models.......................................................................................................... 23 7.3 Appendix C: Issues .......................................................................................................................... 23

SRS Document

Revision History

Name SRS v4.2.doc SRS v4.1.doc SRS v4.doc SRS v3.doc SRS v2.doc Requirement v1.doc

Date July 23 ,2010 July 16 , 2010 July 16 , 2010 July 7 , 2010 July 3 , 2010 June 30 , 2010
th rd th th th rd

Reason For Changes Use case correction Finalization for Mid-Term 2 Addition of Diagrams Addition of Requirements Submitting to Professor Robert Zhu Initial Verbal Customer Requirement

Modified By Ranjeeta Rama Rama Rama Andy Andy

Version 4.2 4.1 4.0 3.0 2.0 1.0

SRS Document

1. Introduction
1.1 Purpose
This project is undertaken to develop a graphical user dashboard interface that reports statuses of bugs arising 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

SRS Document

regarding an organizations future. The high-level diagram of the software system is as follows:

Projects (Java/WebApp) Manual Testing

System High Level Diagram


4 3 1 2

Project vs. Defect Graph Modify Code

4 1 2

Test OK?

Fail

Report Bug To JIRA

Query JIRA DB / My SQL

Data Base Dash Board Integrator

P1 Issues Graph

Pass Product Release

30%

15% 10%

45%
Bug Criticalities Pie Chart

3 1

4 2

BRR Graph

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:

SRS Document

Safety & Security Policies

JIRA DB My SQL Dashboard Tool QA Testing Tool Maintainence System

Reporting Tool

Data Processing Unit

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 VModel 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.

SRS Document

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. BRD/Historical & Defect resolution rate

UAT Planning

UAT

Dashboard Delivery

SRS/Defect Vs Project

System Test Plan

System Testing

HLD/Data flow In the mmodules

Integ Test Planning

Integ Testing

LLD/Data Type, Variables, Naming conventio nnn

Unit Test Planning

Unit Testing

Maintenance & Enhancement

Project (Java) Classes

V-Model

SRS Document

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.

SRS Document

GUI COMPONENT DIAGRAM


TEAM INFORMATION BUG RESOLUTION RATE CRITICAL VS NON CRITICAL PROJECT INFORMATION DAILY/WEEKLY /MONTHLY

Click the Graph Sign in

PROJECTS VS DEFECTS

LOGIN
Sign off

LIST OF PROJECTS

Select Project

PIE CHARTS

HISTORICAL GRAPHS

GUI Component Diagram

Data flow diagram

Requirement

Test case

INPUT PARAMETERS

REQUIRMENT /TEST ANALYSIS

FINDING BUGS
Jira bug tool

Open source

Infrastructure

DASHBOARD

JIRA

JIRA DATA BASE

Historical/Bug resolution graphs

OUTPUT GRAPHS

Data Flow Diagram

SRS Document

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

User

Log In & Password Password

Dashboard

Customer views list of on-going projects

10

SRS Document

Project 1

User

Dash boar d

List of Projects.

Project 2

Defect Vs Project

Project 3

Status

Project n

User Interface to display the graphs of the selected project

Team Info User Dashboard Project Vs Defect graph Historical Graph

11

SRS Document

User

Dashboard

Project Vs Defect Status

Rate resolution Graph

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.

12

SRS Document

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 Java platform and the JIRA bug tracking tools. This product imports all the necessary java packages that are needed 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 the most important available management information source for software process improvement decisions, ignoring defect data can lead to serious consequences for an organization's business. Defect tracking dashboard is a web-based defect and bug tracking solution to track product defects and manage product enhancement requests. Follow the defect resolution process and work the defect from initiation to closure, 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.

13

SRS Document

An association model
generates HomePage DashBoard displays Status Login

access

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:

14

SRS Document

Sub-System Interfaces
Communication Interfaces

Sub-Systems Data Collection


Databases

Dashboard UI Interface

QA Tool

Sub-Systems Applications/Gadgets
Test Plan Test Cases JDBC JQL Input Parameters JIRA Security Permissions Report 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.

15

SRS Document

Class Diagram

State Diagram: Shows how objects respond to different service requests and the state transitions triggered by these requests.

16

SRS Document

State Diagram
drawChart() Displays graphs in dash board drawGraph() initialstate DashBoard getProj() Login Validate() Waiting signOut() goHome() goHome() signOut Graphs getStatus()

Charts

Status

Status complete

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

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 Firefox QA Tools: Bug Tracking Tools: JIRA Communication Tools: WebEx Subversion Tool: Tortoise SVN Reporting Tools: JIRA

17

SRS Document

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:

Work Tasks Breakdown


T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 Andy All All Andy All Ambica/Andy All Rani Rani/Andy Rama/Sudheera All

Task Description
Client Interview Feasibility Study Requirements Analysis Project Planning Process Flows Object Oriented Analysis System Models Manual Testing Bug Reporting UI Integrating Final Delivery Critical Path = 27 Days

Duration (days)

Dependencies
3 4 12 7 3 T1,T2,T3(M1) 3 7 10 7 12 3 T5(M3) T5,T6(M2) T8(M4) T1,T3,T4(M5) T7,T9,T10(M6)

18

SRS Document

7 Days

12 Days

12 Days

Task 4

Task 3
3 Days

M5

Task 10

M3
3 Days

Task 6
7 Days 3 Days 3 Days

Start

Task 1
4 Days

M1

Task 5
7 Days

M2

Task 7

M6

Task 11

Finish

Task 8
10 Days

Task 2

M4

Task 9

Activity Network Diagram

19

SRS Document

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.

20

SRS Document

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 GUI standards 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,

21

SRS Document

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

22

SRS Document

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 companys 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.

23

SRS Document

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 optimum way 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.

24

SRS Document

25