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. 16th, 2009 Huiha Lu Nan Wu Noel David Marco Maurier Contents 1.0 Introduction..................................................................................................................4 1.1 Goals and objectives.................................................................................................4 1.2 Statement of scope....................................................................................................4 1.3 Software context.......................................................................................................4 1.4 Major constraints......................................................................................................4 2.0 Usage scenario.............................................................................................................5 2.1 User profiles.............................................................................................................5 2.2 Use-case Diagrams...................................................................................................6 2.3 Special usage considerations....................................................................................7 3.0 Data Model and Description.........................................................................................8 3.1 Data Description.......................................................................................................8 3.1.1 Data objects.......................................................................................................8 3.1.2 Relationships.....................................................................................................8 3.1.3 Complete data model.........................................................................................9 3.1.4 Data dictionary........................................................................................................10 4.0 Functional Model and Description.............................................................................11 4.1 Functions................................................................................................................11 4.1.1 Login...................................................................................................................11 4.1.1.1 Process Specification....................................................................................11 4.1.1.2 Data Flow.....................................................................................................12 4.1.1.3 Interface........................................................................................................12 4.1.2 Request............................................................................................................12 4.1.2.1. Process Specification...................................................................................12 4.1.4 Report..............................................................................................................14 4.1.5. Register...........................................................................................................15 4.1.6 Sample.............................................................................................................15 4.1.7 Report..............................................................................................................16 .................................................................................................................................. 17 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 | Administrator R-server Edit User Interface Edit Help Ezit Functions & Analysis, Edit Variables 2.3 Special usage considerations No special usage considerations needed. 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 = 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.1Specifications 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 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.