Distributed Monitoring and Mining Project
Software Requirements Specification (SRS)
Distributed Development Monitoring/Mining
Tom Mooney, Ahmed Osman, Isaac Pendergrass, Shailesh Shimpi
Version 2.1
3/11/2013
This document elicits the Distributed Monitoring and Mining Project’s functional and nonfunctional software requirements.
Revision History
Version
Description of Versions / Major Changes
Responsible Party
Date
1.0
Initial version of SRS
Shail Shimpi
2/9/13
1.1
Sections 1, 2.1 and 3 completed.
Shail Shimpi
2/10/13
1.2
Added UI and System Process Requirements. Added
design constraints.
Tom Mooney
2/12/13
1.3
Adding Performance and Development Quality attributes
Ahmed Osman
2/12/13
1.4
Adding domain model and comments
Tom Mooney
2/13/13
1.5
Added Other Requirements section and comments
Isaac Pendergrass
2/13/13
1.6
Resolve Isaac comments and change the table designs
to be the same
Ahmed Osman
2/13/13
1.7
Minor editions and comments.
Shail Shimpi
2/13/13
1.8
Sections 2.1.1.1 and 3 updated
Shail Shimpi
2/18/13
1.9
Restructuring the Non-Function requirements area
Ahmed Osman
2/18/13
Isaac Pendergrass
3/7/2013
Add tags for each requirement
Added some strikethrough on some requirement
suggested to be deleted
2.0
Updated Non-Functional requirements, System process
requirements, Required Subsets. Changed requirement
numbering scheme to allow minimal document
disruption upon requirement additions or deletions.
Approval Block
Version
1.6
Comments
Responsible Party
Good for first draft
Ahmed Osman
Page 1 of 12
Date
2/13/13
Distributed Monitoring and Mining Project
1.7
Reviewed as a first draft. To discuss with Dr. Stuart on
data centric use cases.
Shail Shimpi
2/13/13
1.8
Reviewed NFR and update according to stuart feedback
Ahmed Osman
2/18/13
1.9
Added some comments. Added to the list of expected
changes. Various grammar corrections.
Tom Money
2/19/13
2.0
Updated Non-Functional Requirements
Isaac Pendergrass
3/7/13
2.1
Added Requirement UI-06, UI-07 and UI-08
Shail Shimpi
3/11/13
Page 2 of 12
Distributed Monitoring and Mining Project
Table of Contents
1
2
Introduction.......................................................................................................................... 4
1.1
Intended Audience and Purpose .................................................................................. 4
1.2
How to use the document ............................................................................................ 4
Requirements ...................................................................................................................... 4
2.1
2.1.1
Functional Behavior .............................................................................................. 6
2.1.2
User Interface Requirements ................................................................................ 6
2.1.3
System Process Requirements ............................................................................. 7
2.1.4
Domain Model....................................................................................................... 8
2.2
3
Functional Requirements ............................................................................................. 5
Non-Functional Requirements (NFR) ........................................................................... 9
2.2.1
Performance ......................................................................................................... 9
2.2.2
Availability ............................................................................................................. 9
2.2.3
Usability ................................................................................................................ 9
2.2.4
Fault Tolerance ..................................................................................................... 9
2.2.5
Recoverability ......................................................................................................10
2.2.6
Security................................................................................................................10
2.3
Developmental Quality Attributes ................................................................................10
2.4
Design Constraints......................................................................................................10
Support Information (Appendices) ......................................................................................11
3.1
Definitions ...................................................................................................................11
3.2
Acronyms ....................................................................................................................11
3.3
Anticipated Changes ...................................................................................................11
3.4
Fundamental Assumptions..........................................................................................11
3.5
Required Subsets .......................................................................................................11
3.6
References .................................................................................................................12
Page 3 of 12
Distributed Monitoring and Mining Project
1 Introduction
1.1 Intended Audience and Purpose
The intended audiences for this software requirements specifications (SRS) document are
mainly the technical personnel who will be working on this project. They include architects,
business analysts, developers, integration specialists and quality engineers. The Concept of
Operations document is created specifically for end customer/users and it covers the use cases.
However, this SRS document will also be useful while discussing the system’s features with the
end customer and other management stakeholders.
Within the Framework, the SRS is completed, reviewed, and approved in the Project Planning
Review Gate. The SRS documents and communicates the software requirements to the
technical community who will specify and build the software. The collection of requirements in
the SRS must be understandable by stakeholder entities and the technical community.
1.2 How to use the document
The project team intends to use the Concept of Operations document and SpecFlow tool to
describe the functional requirements. The functional requirements describe the system’s
business functionality, features and how it satisfies end customer/user’s requirements. This
SRS document primarily illustrates behavioral requirements and quality attributes. The nonfunctional requirements state the system’s expectations in terms of performance, scalability,
availability and maintainability.
2 Requirements
The SRS document lists all necessary requirements that are required for the project
development. To derive the requirements, the project team intends to have a clear and thorough
understanding of the system to be developed.
The IEEE Standard Glossary of Software Engineering Technology defines a software
requirement as:
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
document.
3. A documented representation of a condition or capability as in 1 or 2.
Software Requirements gathering phases can broadly be broken up into Elicitation, Analysis,
Specification, and Management.
The Distributed Monitoring and Mining project will use the Assembla Open Source Collaboration
Software to fetch the data, analyze it and display the results to the end user. This section
gathers all those requirements to develop the system. It is primarily divided into behavioral,
quality, and other requirements. It also specifies the design constraints assumed in the project.
Functional Requirements are those that refer to the functionality of the system, i.e., what
services it will provide to the user. Nonfunctional (supplementary) requirements pertain to other
information needed to produce the correct system and are detailed separately.
Page 4 of 12
Distributed Monitoring and Mining Project
2.1 Functional Requirements
DMM system environment consists of Assembla and its project tracking data. The user
application consists of user interfaces, business objects, data store, reports and the analytical
tool.
`
Developer
`
QA Engineer
ASSEMBLA
Collaboration Software
User Interface
User Interface
User Application
Business Objects
Project Data
`
Project
Manager
UI/Report
UI/Report
Application
Programming Interface
User Interfaces
Analytics Tool
Assembla
Server
Fig.1 System Environment
Page 5 of 12
Project WorkSpace
Project WorkSpace
Project WorkSpace
Distributed Monitoring and Mining Project
2.1.1 Functional Behavior
The functional behavior of the system illustrates how the system will operate. The following
detailed requirements describe the DMM system behavior.
2.1.2 User Interface Requirements
UI-01
Description
Classification
The system will allow the user to login using their existing Assembla
account.
Essential
Assembla provides an authentication API (OAuth2) for all external
applications. These external applications need to be registered with
Assembla and the credentials need to be provided with the OAuth2
API calls.
UI-02
The system will allow the user to choose one of their existing
Assembla projects to analyze against the system’s predictive model.
These project name field will be the one that was used while settingup the project in Assembla.
Essential
UI-03
Once the system has applied the predictive model (analytics engine)
to the selected project, a report will be generated for the user
showing how the particular project compares to the model. This
report will contain:
Essential
1. The raw data for the project that was applied to the model.
For example; milestone data etc.
2. Comparison data with the other project(s).
3. How the project data is compared with other project(s) and
any conclusion based on the model rules.
4. Ability to save and print the report in PDF format.
UI-04
User can receive live alerts over the course of their project. These
alerts will tell the user about any possible impact (such as success or
failure) of the project. The alert would contain the same data as the
report outlined in UI-03
Desirable
UI-05
System can access Assembla user roles so that only specific roles
can access the critical data reports.
Optional
UI-06
Provide information about high level scope and goals about the
project and other project related information i.e. About Screen.
Desirable
UI-07
Depending on user’s preference settings; the user should be able to
get the analysis reports generated for his/her project.
Essential
UI-08
Depending on user’s preference settings; the user can save project
information/metrics.
Desirable
Page 6 of 12
Distributed Monitoring and Mining Project
2.1.3 System Process Requirements
Description
Classification
SP-01 The system will connect to the Assembla REST API.
Essential
SP-02 The system will find all projects with publicly available data on
Assembla.
Essential
SP-03 For each project identified in SP-02, the system will download data
to be used to classify projects as either success or failure. The
data points required are:
Essential
1. All Milestones for each project
If no Milestone data is available for a given project, then the project
will be excluded from the analysis.
SP-04 The system will store the downloaded milestone data in a local
data store.
Essential
SP-05 The system will classify projects as successful based on the
following criteria:
Essential
1. At least 75% of milestones completed on or before due
date. (due_date <= completed_date)
SP-06 The system will download communication metric data for each of
the projects that were classified in SP-05. The data points required
are:
Essential
1. All tickets associated with the project.
SP-07 The system will save the data downloaded in SP-06 to a local data
store
Essential
SP-08 The system will generate a predictive regression model based on
the correlation between tickets and project success based on:
Essential
1. The average closed tickets per completed milestones.
2. The average open tickets per completed milestones.
SP-09 The system shall provide the ability to email reports to userspecified recipients by using the default email client.
Essential
SP-10 The system may provide the ability to save user project
information/metrics.
Desirable
Page 7 of 12
Distributed Monitoring and Mining Project
2.1.4 Domain Model
Page 8 of 12
Distributed Monitoring and Mining Project
2.2 Non-Functional Requirements (NFR)
2.2.1 Performance
Description
Classification
P-01
Response to user action shall take no more than 3 seconds.
(Application state should never be unknown for more than 3
seconds.)
Essential
P-02
Display of post-analysis reports shall take no more than 10
seconds to generate.
Essential
2.2.2 Availability
Description
Classification
A-01
The system shall have a 0.997 or better uptime/total ratio in a
constant load (>= 20 analysis requests) scenario.
Essential
A-02
The system shall support up to 20 simultaneous analyses.
Essential
A-03
The system shall queue analysis requests over 20 for
processing upon resource availability.
Essential
2.2.3 Usability
U-01
Description
Classification
A targeted user shall be able to operate the system’s main
workflow without viewing the manual.
Essential
2.2.4 Fault Tolerance
Description
Classification
FT-01
The system shall halt all operations, within the context of a user
session, immediately, upon the occurrence of a data corrupting
error.
Essential
FT-02
The system shall alert users when a data corrupting error has
occurred.
Essential
FT-03
The system shall attempt to continue upon the occurrence of an
error that is not data corrupting.
Essential
FT-04
The system shall notify the user in the event of any error that does
not allow analysis to proceed.
Essential
Page 9 of 12
Distributed Monitoring and Mining Project
2.2.5 Recoverability
Description
Classification
R-01
The system shall back up the local data cache to a recovery
file at an interval of no more than five minutes upon detection
of a change.
Essential
R-02
The backup process shall not exceed 10 minutes in duration.
Essential
2.2.6 Security
Description
Classification
S-01
The system shall not store any sensitive data that could be
used to identify a user or organization.
Essential
S-02
All system authorization shall occur through credential checks
against the Assembla (or any other supported collaboration
tool) user base.
Essential
2.3 Developmental Quality Attributes
Description
Classification
D-01
Team should use VS 2012
Essential
D-02
The code should follow the Object Oriented programming features
like inheritance and polymorphism.
http://en.wikipedia.org/wiki/Object-oriented_programming
Essential
D-03
The code should follow the coding standards like indentation
suggested by Microsoft http://msdn.microsoft.com/enus/library/vstudio/ff926074.aspx
Essential
D-04
The code should be reviewed, verified and built before being
checked in source repository
Essential
D-05
To ensure the code is maintainable, it should have a cyclomatic
complexity of no more than 10.
Desirable
2.4 Design Constraints

Use the Assembla REST API for gathering data.

Use OAuth2 with Assembla for user authentication.
Page 10 of 12
Distributed Monitoring and Mining Project
3 Support Information (Appendices)
This section includes the following support information.
3.1 Definitions

Authentication – Authentication is establishing true identity of the user.
3.2 Acronyms

API – Application Programming Interface

Oauth2 – Assembla API for user’s authentication
3.3 Anticipated Changes

DMM project heavily relies on the Assembla API for fetching the project(s) data from
its repositories. If there are any changes to the Assembla API, the DMM application
will be impacted including severe fatal errors and that may lead to the application not
working or processing data.

Any changes to Assembla APIs may impact DMM application on the way it calls
Assembla.

Google Analytics will be used as the analytic engine for setting up the predictive model
and performing analysis. Any changes to Google Analytics APIs may impact the way
DMM calls Google Analytics.

The metrics used for classifying a project as a success or failure could change.

The communication metric used to construct the predictive model could change.
Additional metrics could also be added.

The content of the report generated for the user about their project based on the
predictive model could change. For example, we may want to add graphs.
3.4 Fundamental Assumptions

Project team assumes that Assembla Open Source Collaboration software stores all
relevant projects tracking data, as described at the product’s web site.

API and interfaces provided by Assembla performs to the developer’s satisfaction, as
depicted at the product’s web site.
3.5 Required Subsets
Development or implementation will be carried out in iterations. Each version will deliver the
following product capability or features.
Subset 1 (Prototype):



Assembla User Login (Demo)
Assembla User Data Download (Demo)
Google Predictive Analysis (Demo)
Page 11 of 12
Distributed Monitoring and Mining Project

About Screen - Project Scope and Goals
Subset 2:



Integrated Subset 1 Features
User Project Select Functionality
Default Project Report
Subset 3:



Analysis Queue
Print Report
Save Report (pdf)
Subset 4:



Automatic Email Report
User-defined Email Report List
Save Report (xps)
Subset 5:


Analysis Progress Updates
System Data Backup
Subset 6:


Advanced Model
Advanced Reporting
3.6 References

Concept of Operations

IEEE]. The applicable IEEE standards are published in “IEEE Standards Collection,”
2001 edition.

Wikipedia.org
Page 12 of 12