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 non-functional 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

Add tags for each requirement

Added some strikethrough on some requirement suggested to be deleted

Ahmed Osman 2/18/13

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/2013

Approval Block

Version Comments Responsible Party Date

1.6 Good for first draft Ahmed Osman 2/13/13

Page 1 of 12

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 Contents1 Introduction.............................................................................................................................4

1.1 Intended Audience and Purpose.....................................................................................4

1.2 How to use the document...............................................................................................4

2 Requirements..........................................................................................................................4

2.1 Functional Requirements................................................................................................5

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

3 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 non-functional requirements state the system’s expectations in terms of performance, scalability, availability and maintainability.

2 RequirementsThe 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.

Fig.1 System Environment

Page 5 of 12

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 RequirementsDescription Classification

UI-01 The system will allow the user to login using their existing Assembla account.

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.

Essential

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:

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.

Essential

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 RequirementsDescription 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:

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.

Essential

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:

1. At least 75% of milestones completed on or before due date. (due_date <= completed_date)

Essential

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. All tickets associated with the project.

Essential

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:

1. The average closed tickets per completed milestones.

2. The average open tickets per completed milestones.

Essential

SP-09 The system shall provide the ability to email reports to user-specified 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 PerformanceDescription 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 AvailabilityDescription 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 UsabilityDescription Classification

U-01 A targeted user shall be able to operate the system’s main workflow without viewing the manual.

Essential

2.2.4 Fault ToleranceDescription 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

2.2.5 RecoverabilityDescription 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

Page 9 of 12

Distributed Monitoring and Mining Project

2.2.6 SecurityDescription 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/en-us/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.

3 Support Information (Appendices) This section includes the following support information.

3.1 Definitions Page 10 of 12

Distributed Monitoring and Mining Project

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 SubsetsDevelopment 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) About Screen - Project Scope and Goals

Subset 2: Integrated Subset 1 Features User Project Select Functionality Default Project Report

Page 11 of 12

Distributed Monitoring and Mining Project

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

<<Overall this has addressed most of the issues raised for version 1. There are still some issues for the Developmental Quality Attributes (what you are calling NFRs). The approach the team is currently taking to these does not really leverage the thinking and techniques that we covered in several classes. This would include thinking about designing for change, modularization, information hiding.

If this is not ringing any bells, we can talk about it. The SRS being developed by Android Lifebulb project also provides some good examples in this area.

SF>>

Page 12 of 12