Distributed Monitoring and Mining Project
Software Requirements Specification (SRS)
Distributed Monitoring and Mining
Tom Mooney, Ahmed Osman, Isaac Pendergrass, Shailesh Shimpi
Version 2.6
06/08/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
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.
Isaac Pendergrass
3/7/13
2.2
Changed name of NFR section to Behavioral Requirements
Isaac Pendergrass
3/17/13
2.3
Updated Required Subsets section. Changed names of
functional and Behavioral requirements sections
Isaac Pendergrass
3/18/13
2.4
Updated all requirements sections and moved figures around
to fit new organization.
Isaac Pendergrass
3/19/13
Page 1 of 14
Distributed Monitoring and Mining Project
Version
Description of Versions / Major Changes
Responsible
Party
Date
2.5
Updated Required Subsets.
Isaac Pendergrass
5/19/13
2.6
Final update to match the actual product release
Shail Shimpi
6/8/13
Responsible Party
Date
Approval Block
Version
Comments
1.6
Good for first draft
Ahmed Osman
2/13/13
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
2.2
Reviewed the version
Shail Shimpi
6/8/13
Page 2 of 14
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
User Interface Requirements ................................................................................ 5
2.1.2
System Process Requirements ............................................................................. 6
2.1.3
Performance ......................................................................................................... 7
2.1.4
Availability ............................................................................................................. 7
2.1.5
Usability ................................................................................................................ 8
2.1.6
Fault Tolerance ..................................................................................................... 8
2.1.7
Recoverability ....................................................................................................... 8
2.1.8
Security................................................................................................................. 8
2.2
3
Behavioral Requirements ............................................................................................. 5
Development Quality Attributes .................................................................................... 9
2.2.1
Maintainability ....................................................................................................... 9
2.2.2
Extensibility ........................................................................................................... 9
2.3
System Environment ...................................................................................................10
2.4
Domain Model.............................................................................................................11
2.5
Design Constraints......................................................................................................11
Support Information (Appendices) ......................................................................................12
3.1
Definitions ...................................................................................................................12
3.2
Acronyms ....................................................................................................................12
3.3
Anticipated Changes ...................................................................................................12
3.4
Fundamental Assumptions..........................................................................................12
3.5
Required Subsets .......................................................................................................13
3.6
References .................................................................................................................14
Page 3 of 14
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 14
Distributed Monitoring and Mining Project
2.1 Behavioral Requirements
The behavioral requirements of the system dictate how the system should operate. The
following detailed requirements describe the DMM system behavior.
2.1.1 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 setting-up 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
(Out of Scope)
Modified: - User can see and print the last generated/execute
analysis report.
UI-08
Depending on user’s preference settings; the user can save
project information/metrics.
Page 5 of 14
Desirable
(Out of Scope)
Distributed Monitoring and Mining Project
2.1.2 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. Number of Milestones
2. Closed Tickets/Milestones
3. Open Tickets/Milestones
4. Remaining Open Tickets/Milestones
5. Average Ticket Priority
6. Open Tickets/Day
7. Mean time between Tickets (Days)
8. Mean time between High Priority Tickets (Days)
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 73% 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:
1.
2.
3.
4.
5.
6.
7.
8.
Essential
Number of Milestones
Closed Tickets/Milestones
Open Tickets/Milestones
Remaining Open Tickets/Milestones
Average Ticket Priority
Open Tickets/Day
Mean time between Tickets (Days)
Mean time between High Priority Tickets (Days)
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 milestone, tickets, and project
success based on:
Essential
1.
2.
3.
4.
Number of Milestones
Closed Tickets/Milestones
Open Tickets/Milestones
Remaining Open Tickets/Milestones
Page 6 of 14
Distributed Monitoring and Mining Project
Description
5.
6.
7.
8.
SP-09
Classification
Average Ticket Priority
Open Tickets/Day
Mean time between Tickets (Days)
Mean time between High Priority Tickets (Days)
The system shall provide the ability to email reports to userspecified recipients by using the default email client.
Essential
Modified: - User can save or print the analysis report in PDF
format.
SP-10
SP-11
The system may provide the ability to save user project
information/metrics.
Desirable
The system will calculate mean, standard deviation and
variance for all metrics used in predicting the project status.
Essential
1.
2.
3.
4.
5.
6.
7.
8.
(Out of Scope)
Number of Milestones
Closed Tickets/Milestones
Open Tickets/Milestones
Remaining Open Tickets/Milestones
Average Ticket Priority
Open Tickets/Day
Mean time between Tickets (Days)
Mean time between High Priority Tickets (Days)
2.1.3 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.1.4 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
Page 7 of 14
Distributed Monitoring and Mining Project
2.1.5 Usability
U-01
Description
Classification
A targeted user shall be able to operate the system’s main
workflow without viewing the manual.
Essential
2.1.6 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
The system shall attempt to continue upon the occurrence of an
error that is not data corrupting.
Essential
The system shall notify the user in the event of any error that
does not allow analysis to proceed.
Essential
FT-03
FT-04
(Out of Scope)
(Out of Scope)
Modified: - The error message will get displayed in the Web
application.
2.1.7 Recoverability
R-01
R-02
Description
Classification
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
The backup process shall not exceed 10 minutes in duration.
Essential
(Out of Scope)
(Out of Scope)
2.1.8 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
Page 8 of 14
Distributed Monitoring and Mining Project
2.2 Development Quality Attributes
This section documents any requirements or constraints on the system’s static construction.
2.2.1 Maintainability
Description
Classification
M-01
A change inside any module should not affect any other module
Essential
M-02
A change in module interface should maintain backwards
compatibility with the old interface.
Essential
M-03
Replacing a module with another like the predictive tool with
another, should have minimal impact on other modules.
Essential
Modified: - Ideally, only the interface that interacts with
collaboration tool should be affected in case different
collaboration tool is used.
2.2.2 Extensibility
Description
Classification
E-01
Adding new metrics should not change the prediction module
interface.
Essential
E-02
Adding more contents in the report should not change the
functional behavior of other modules.
Essential
E-03
Adding other collaboration tool other than Assembla should only
change the GUI module with the collaboration interface
Essential
Modified: - The modules are decoupled; however, in addition to
collaboration tool interface modules, there may be still some
changes involved to other system modules, in case different
collaboration tool is used.
Page 9 of 14
Distributed Monitoring and Mining Project
2.3 System Environment
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.
Page 10 of 14
Distributed Monitoring and Mining Project
2.4 Domain Model
2.5 Design Constraints

Use the Assembla REST API for gathering data.

Use OAuth2 with Assembla for user authentication.
Page 11 of 14
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.
Page 12 of 14
Distributed Monitoring and Mining Project
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)
Subset 2 (First Release):



Integrated Subset 1 Features
User Project Select Functionality
Simple Project Report
Subset 3 (Second Release):


Advanced Prediction Model
Advanced Reporting Template (Phase I)
Subset 4 (Final Release):


Save Report in PDF
Advanced Reporting Template (Phase II)
Page 13 of 14
Distributed Monitoring and Mining Project
3.6 References

Concept of Operations

IEEE]. The applicable IEEE standards are published in “IEEE Standards Collection,”
2001 edition.

Wikipedia.org
Page 14 of 14