Software Requirements Specification - Advanced Software Engineering | CS 430, Study Guides, Projects, Research of Software Engineering

Download Software Requirements Specification - Advanced Software Engineering | CS 430 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

CS 430

R-Server

Software Requirements Specification

Feb. 16

th

, 2009

Huiha Lu

Nan Wu

Noel David

Marco Maurier

Contents

• 1.0 Introduction..................................................................................................................
  • 1.1 Goals and objectives.................................................................................................
  • 1.2 Statement of scope....................................................................................................
  • 1.3 Software context.......................................................................................................
  • 1.4 Major constraints......................................................................................................
• 2.0 Usage scenario.............................................................................................................
  • 2.1 User profiles.............................................................................................................
  • 2.2 Use-case Diagrams...................................................................................................
  • 2.3 Special usage considerations....................................................................................
• 3.0 Data Model and Description.........................................................................................
  • 3.1 Data Description.......................................................................................................
    • 3.1.1 Data objects.......................................................................................................
    • 3.1.2 Relationships.....................................................................................................
    • 3.1.3 Complete data model.........................................................................................
• 3.1.4 Data dictionary........................................................................................................
• 4.0 Functional Model and Description.............................................................................
  • 4.1 Functions................................................................................................................
  • 4.1.1 Login...................................................................................................................
    • 4.1.1.1 Process Specification....................................................................................
    • 4.1.1.2 Data Flow.....................................................................................................
    • 4.1.1.3 Interface........................................................................................................
    • 4.1.2 Request............................................................................................................
    • 4.1.2.1. Process Specification...................................................................................
    • 4.1.4 Report..............................................................................................................
    • 4.1.5. Register...........................................................................................................
    • 4.1.6 Sample.............................................................................................................
    • 4.1.7 Report..............................................................................................................
    • 4.1.8 Print.................................................................................................................
    • 4.1.9 Save.................................................................................................................
  • 4.2 Software interface description................................................................................
    • 4.2.1 External machine interfaces.............................................................................
    • 4.2.2 External system interfaces...............................................................................
    • 4.2.3 Human interface..............................................................................................
  • 4.3 Control flow description.........................................................................................
• 5.0 Behavioral Model and Description.............................................................................
  • 5.1 Description for software behavior..........................................................................
    • 5.1.1 Events..............................................................................................................
    • 5.1.2 States...............................................................................................................
  • 5.2 State Transition Diagram........................................................................................
  • 5.3 Control specification (CSPEC)...............................................................................
  • 6.0 Restrictions, Limitations, and Constraints..............................................................
• 7.0 Validation Criteria......................................................................................................
  • 7.1 Classes of tests.......................................................................................................
  • 7.2 Expected software response....................................................................................
  • 7.3 Performance bounds...............................................................................................
• 8.0 Appendices.................................................................................................................
  • 8.1 System traceability matrix......................................................................................
  • 8.2 Product Strategies...................................................................................................
  • 8.3 Analysis metrics to be used....................................................................................

1.0 Introduction

1.1 Goals and objectives

The goal of our team is to create a website that will give user an easy and convenient way to access statistical functions to all registered users. It should be able to produce and retrieve reports which are as accurate to an R statistical engine as possible. The system should also allow users to save the reports produced by the server as file in their local computers. The website should also offer administrative options to maintain the data store and the user interface.

1.2 Statement of scope

The system will allow users to register themselves before they start using the R-serve. Once users are authenticated, then they should be able to create and save reports in the form of excel files. The functions available to registered users will be similar to those available in the environment offered by the R statistical computing and graphics language. It will be implemented using drop down menus, text boxes, check boxes, and buttons. The system administrator should be able to manage the database and user interface.

1.3 Software context

The R-server can be use as open source product. I could be incorporated as part of larger package of web services. This system allows users to quickly have access to a statistical analysis engine without having to install one on the computer that they are actually using. This is an advantage for individuals who are not interested in learning how to use the R language and environment.

1.4 Major constraints

The system may have a limited number of functions that can be implemented online, as opposed to what is available through the R integrated suite. Due to the Open Source nature of R-Server this constraint is actually limited to the amount of time that developers can invest into expanding the capability of the system. Since the implementation will use the C# statistical library, it will also be limited to amount of functions this library offers. Implementing the R suite directly into the web server could eliminate most of these constraints.

2.0 Usage scenario

2.1 User profiles

There are two actors that should be defined in the system. These actors interact with the server and have different functions and access levels. The User request authentication via a login interface, once authenticated several options will be made available in the form of variables, samples, reports, analysis selections, save/retrieve reports and functions. The administrator should be able to edit the user database, modify the user interface, and edit the help menu, functions, variables, and analysis option.

2.2 Use-case Diagrams

User R-server Login / Register Display Help View Variables Graph Output Select Function & Analysis Save / Retrive Reports

2.3 Special usage considerations

No special usage considerations needed.

3.0 Data Model and Description

3.1 Data Description

The objective of the R-Server website is to allow users of the website a user friendly, secure, and efficient way to view their data online. The website will provide the user access to the database, view the data, and select build-in statistic analysis to get quick and simple statistical report of the data. The user interface will provide the user different choices of statistical reports and a list of variables that they want to be used for the report. The data used in this project is a sample of how the R-Server website can be applied to different fields. The data here are some sample data that are collected for deaths caused by different drugs. Medical examiners from over the world can access these data as long as they are registered and approved. With access to the data, medical examiners over the world can study different cases that is been collected all over the world and compare them and come up with better analysis and conclusions for the data. 3.1.1 Data objects The data objects for the R-Server can be categorized into two different categories, the user and the database. The objects for the database would be changing depending on the user group registered for the R-Server. For illustration purpose, the data objects for the medical examiners are listed here in the ER-diagram. A detailed list of each object would be meaningless since they will be changing from group to group. However, the data objects for the user category should be consistent. They will always be consisted of the general information of each user such as first name, last name, address, etc., their username, and their passwords. 3.1.2 Relationships Relationship of the data used for this report is illustrated in the next section using a ER- Diagram. The relationship for each database will be different from one another based on which fields of studies are registered and using the R-Server. And each groups uses different database to their interest. The data relationship below is only a sample of what one of the field of data would look like for a particular group such as the medical examiners who are interested in the deaths caused by drugs taken. It is represented using a ER-diagram. The relationship for the user tables will stay consistent. There will always be two tables for the users. One table would be the registered users with their basic information, such as last name, first name, address, etc. The other table would be the assigned username and password for each registered user. A user_id is created in both tables to connect the two tables.

3.1.3 Complete data model

3.1.4 Data dictionary

A data dictionary only for the user and auth_users tables are provided because they are consistent from one group of users to another. They represent the user groups for each groups of users that is registered to R-Server. However, a data dictionary for the database itself will not be provided. It is meaningless because each data dictionary for the database would be different from one another depending on the user group who is using R-Server. Their interest of data would be different. Here is the data dictionary for the user and auth_users tables. They are consistent for each groups of users. Field Name Table Name Type Description auth_user_id auth_user num primary key user_id auth_user num foreign key user_name auth_user char username for registered user password auth_user char password for registered user creation_date auth_user date date account been created user_id users num primary key fname users char first name lname users char last name street users char street name city users char city name state users char state zip users char zip code phone users num phone number email users char email address

4.0 Functional Model and Description

4.1 Functions

4.1.1 Login

The function is used to establish a user’s credentials and permits a user to gain access to the system with permissions specific to the specific user. 4.1.1.1 Process Specification Process Login performs sending the username and password to the server. The server will check if username exists in the data, if the username does not exist the server will send the user back to the login page with a message telling the user that the username or password isn’t valid. If the username exists, the server will check for the password. If the password matches, the server takes the user to the report page. If the password did not match, the server will take the user back to the login page with an error message telling the user that the username or password isn’t valid.

4.1.1.2 Data Flow 4.1.1.3 Interface A text and rectangular shaped submit button with the word Login displayed. It is located below the username and the password input text box on the login page. 4.1.2 Request 4.1.2.1. Process Specification Process Request is a text input box that collects the user’s email address. It sends the user’s email to the server and check if it exists in the database. If the email address does exists, [email exist = true] is send to the server and the user’s username and password will be send to the email address specified. If the email does not exist, [email exist =

false] is send to the server and the user will be directed back to the request page asking the user to type in their email address again. 4.1.2.2. Data Flow 4.1.2.3 Interface A submit button located next to the Email input text box. The text Submit is displayed on the button on the username and password request page.

4.1.3 Register 4.1.3.1 Specifications Process Register transform performs sending the information collected on the registration page to the server. The server will check if any conflict exists, such as if the email address already exists, etc. If any conflict exists, the server will direct the user back to the registration page with an error message telling the user the specific conflict. If no conflict exists, the server will send the information to the administrator. 4.1.3.2 Data Flow 4.1.3.3 Interface A submit button located at the bottom of the registration page. The text Submit is displayed on the button. 4.1.4 Report 4.1.4.1 Specifications Process Report transform performs directing the user to the login page where the user can login and access the report page of the R-Server website. Process Report is displayed as a string of characters that is highlighted and underlined.

4.1.4.2 Data Flow 4.1.4.3 Interface Displayed as, report, it is a link made of a word where the user can click. It is located on the main page of the R-Server website. 4.1.5. Register 4.1.5. 1 Specifications Process register transform performs directing the user to the registration page of the R- Server website. Process register is displayed as, Register as a new user. This string of characters is highlighted and underlined. Once the user clicks on the texts, the website will take the user to the registration page. 4.1.5.2 Data Flow 4.1.5.3 Interface Displayed as, Register as a new user, it is a link made of a line of text where the user can click. It is located on the main page of the R-Server website. 4.1.6 Sample 4.1.6.1 Specifications Process Sample transform performs taking the user to the sample page of the R-Server website. Here the user can see a sample of the reports produced by the R-Server.

4.1.6.2 Data Flow 4.1.6.3 Interface Displayed as, sample, it is a link made of a word where the user can click. It is located on the main page of the R-Server website. 4.1.7 Report 4.1.7.1 Specifications Process Report performs sending the analysis and variables that the user selected to the server. The server runs the statistical package based on the specific analysis on the variables, generates a report, and displays it on the website. 4.1.7.2 Data Flow 4.1.7.3. Interface A submit button located at the bottom of the page, below the analysis and variable drop down menu. The text Submit is displayed on the button. 4.1.7.4 Function REPORT transforms 4.1.7.4.1 Transform description for function ANALYSIS_SELECTION Process Analysis_selection is a drop down menu that is located on the report page. It allows the user to select different types of analysis. The selection made by the user,

[analysis type = selected] is sent to the server and a list of variables will be displayed based on this selection. 4.1.7.4.2 Transform interface description for function ANALYSIS_SELECTION Analysis_selection is a drop down menu that is located at the top of the web page on the report page of the R-Server website. 4.1.7.4.3 Transform lower level flow diagrams for function ANALYSIS_SELECTION 4.1.7.4.4 Transform description for function VARIABLE_LIST Process Variable_list is a list of variables that is displayed. This list is dynamically generated. It is based on the selection from the analysis_selection. Each variable will include a check box in front so the user can select one or more of the variables to be included in the analysis. 4.1.7.4.5 Transform interface description for function VARIABLE_LIST Variable_list is dynamically generated. Number of rows of variables generated will be based on the selection of the analysis. It is located below the Analysis_selection’s drop down menu. In front of each variable, there will be a check box. The user can check one or more of the check boxes. 4.1.7.4.6 Transform lower level flow diagrams for function VARIABLE_LIST

4.1.8 Print 4.1.8.1 Specifications Process Print performs sending the result to the user’s print to be printed. 4.1.8.2 Data Flow 4.1.8.3 Interface Displayed as, print, it is a link made of a word where the user can click. It is located at the bottom of the result page. 4.1.9 Save 4.1.9.1 Specifications Process Save performs allows the user to save the output into EXCEL format and stores them to the user’s local computer. 4.1.9.2 Data Flow 4.1.9.3 Interface Displayed as EXCEL icon located at the bottom of the result page.

4.2 Software interface description

The software interface to the outside world is described. 4.2.1 External machine interfaces Everything of the R-Server is web based. There is no external machine interfaces. 4.2.2 External system interfaces The R-Server will be running on a server provided by R-Server. The users can access the data and website using web browsers as long as the computer is connected to the internet. 4.2.3 Human interface Everything of the R-Server is web based. A monitor, keyboard, and mouse will be required.

4.3 Control flow description

The control flow for the system is presented with reference to Section 5.0 of this document.

5.0 Behavioral Model and Description

5.1 Description for software behavior

5.1.1 Events Invalid user and/or password – When an incorrect username or password is specified at the login page, the system will simply refresh the login page and prompt the user for their credentials again. Valid user and password – If a valid username and password are entered at the login page, the user will then be logged in to the interface. Get Help – The user will get access to a list of help topics. Select Function – The user selects a specific function from the menu. Select Graph – The user can choose to graph their generated results from the function. Return to Menu – The user will be sent back to the main functions menu, with the option of saving any generated results. Select Saved Query – The user will be able to access previously saved results. Logout – The user will be logged out of the interface. 5.1.2 States 5.1.2.1. Login Prompt the user for their username and password. 5.1.2.2. View Functions Menu The main menu, which will display a list of functions, as well as access to help topics and the option to logout. 5.1.2.3. Help Topic The help menu will provide a list of help topics which address the interface and how to use it. 5.1.2.4. Enter Data The user will enter data into a specified function. 5.1.2.5. Graph Generate a graph of the results.

5.1.2.6. Open Saved Query View a previously saved query; results and graph.

5.2 State Transition Diagram

5.3 Control specification (CSPEC)

The software will manage control through the web interface. First, a user has to login to access the system, by submitting proper credentials. The validity of their login information is verified by the system as a form of control. Once a user has been logged in successfully, they will then be taken to the main menu. From here, they can get help on how to use the interface, begin a new query, or open up a saved query.

6.0 Restrictions, Limitations, and Constraints

The web interface will run on a web server, and as such it will be restricted to the limits of that server in terms of bandwidth. The software also requires a database to store all the data, preferably on the same server to minimize delays. To access the web interface, a user would need an internet browser and have to enable cookies.

7.0 Validation Criteria

7.1 Classes of tests

The software can be tested in two phases; the statistical phase, and the web interface phase. The statistical phase involves testing the core of the product; the functions and graphs. Functions will have to be tested for accuracy and to make sure they are implemented correctly. Graphs will need to depict the functions accurately as well, and work on top of the functions properly. The web interface phase will see that the web interface adheres to the web standards of W3C. This ensures that clients using Microsoft Internet Explorer, Mozilla Firefox, or Safari, the most commonly used browsers, will be able to view all objects in the web interface correctly.

7.2 Expected software response

Expected responses to the statistical phase of testing would be correctly generated functions and graphs. This mean correct in terms of mathematical accuracy as well as graphically. Expected responses to the web interface phase would be the interface opening without any errors or misplaced objects.

7.3 Performance bounds

The web interface is restricted to 1000 simultaneous connections to prevent overload. This number can be reconfigured according to server size and client needs.

8.0 Appendices

8.1 System traceability matrix

Does not apply

8.2 Product Strategies

The product itself is the R-Server, a software package. It will be offered to the public free of charge; however it will not be open source. No forms of marketing will take place, rather, R-Server will be initially distributed to beta testers and from there on, its’ usability will determine its’ popularity.

8.3 Analysis metrics to be used

Does not apply