course description - portland state university€¦ · web viewthe ieee standard glossary of...

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


2.4 Updated all requirements sections and moved figures around to fit new organization.


of 14


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

Approval Block

Version Comments Responsible Party Date

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

of 14


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 Behavioral Requirements................................................................................................5

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

3 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

of 14


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.

of 14


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

(Out of Scope)

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.

Modified: - User can see and print the last generated/execute analysis report.

Essential

UI-08 Depending on user’s preference settings; the user can save project information/metrics.

Desirable

(Out of Scope)

of 14


2.1.2 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. 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)

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 73% 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. Number of Milestones2. Closed Tickets/Milestones3. Open Tickets/Milestones4. Remaining Open Tickets/Milestones5. Average Ticket Priority6. Open Tickets/Day7. Mean time between Tickets (Days)8. Mean time between High Priority Tickets (Days)

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 milestone, tickets, and project success based on:

1. Number of Milestones2. Closed Tickets/Milestones3. Open Tickets/Milestones

Essential

of 14


Description Classification

4. Remaining Open Tickets/Milestones5. Average Ticket Priority6. Open Tickets/Day7. Mean time between Tickets (Days)8. Mean time between High Priority Tickets (Days)

SP-09 The system shall provide the ability to email reports to user-specified recipients by using the default email client.

Modified: - User can save or print the analysis report in PDF format.

Essential

SP-10 The system may provide the ability to save user project information/metrics.

Desirable

(Out of Scope)

SP-11 The system will calculate mean, standard deviation and variance for all metrics used in predicting the project status.

1. Number of Milestones2. Closed Tickets/Milestones3. Open Tickets/Milestones4. Remaining Open Tickets/Milestones5. Average Ticket Priority6. Open Tickets/Day7. Mean time between Tickets (Days)8. Mean time between High Priority Tickets (Days)

Essential

2.1.3 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.1.4 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.1.5 UsabilityDescription Classification

of 14


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

Essential

2.1.6 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

(Out of Scope)

FT-03 The system shall attempt to continue upon the occurrence of an error that is not data corrupting.

Essential

(Out of Scope)

FT-04 The system shall notify the user in the event of any error that does not allow analysis to proceed.

Modified: - The error message will get displayed in the Web application.

Essential

2.1.7 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

(Out of Scope)

R-02 The backup process shall not exceed 10 minutes in duration. Essential

(Out of Scope)

2.1.8 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

of 14


2.2 Development Quality Attributes This section documents any requirements or constraints on the system’s static construction.

2.2.1 MaintainabilityDescription 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.

Modified: - Ideally, only the interface that interacts with collaboration tool should be affected in case different collaboration tool is used.

Essential

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

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.

Essential

of 14


2.3 System EnvironmentDMM 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.

of 14


2.4 Domain Model

2.5 Design Constraints Use the Assembla REST API for gathering data.

Use OAuth2 with Assembla for user authentication.

of 14


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.

of 14


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)

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)

of 14


3.6 References Concept of Operations

IEEE]. The applicable IEEE standards are published in “IEEE Standards Collection,” 2001 edition.

Wikipedia.org

of 14

course description - portland state university€¦ · web viewthe ieee standard glossary of...

Documents