Software Requirements Specification. for. Room Scheduling Software. Version 1.0 approved. Prepared by Norah Almahdali. Dan Easterling, Tim Mihelic

Transcription

1 Software Requirements Specification for Room Scheduling Software Version 1.0 approved Prepared by Norah Almahdali. Dan Easterling, Tim Mihelic Computer Science 430 September 12 th, 2013

2 Table of Contents Table of Contents 1 1. Introduction Purpose Document Conventions Intended Audience and Reading Suggestions Product Scope References 2 2. Overall Description Product Perspective Product Functions User Classes and Characteristics Design and Implementation Constraints System and Network Requirements User Documentation 4 3. External Interface Requirements User Interfaces Section 1: The Course Display Schedule Section 2: Languages Hardware Interfaces 5 4. System Features Error Handling Input Requirements 5 5. Other Nonfunctional Requirements Performance Requirements Safety Requirements Security Requirements Software Quality Attributes Business Rules 6 Appendix A: Glossary 7 Appendix B: Analysis Models 7 Appendix C: To Be Determined List 7 1. Introduction 1.1 Purpose The main purpose of this document is to allow both the client and the developers to get an overview of the product, the Room Scheduling Software. The document should serve as an initial contract between both parties, in order for us to agree on the final system requirements. These system requirements were discussed in the meeting with the client in early September. All the requirements are subject to change and can be flexible as long as the client is satisfied with the changes. The client was working with Microsoft Excel for scheduling needs prior to this Software. Therefore, this software will be the first

3 Room Scheduling Software used by the client. This is a green field project, meaning we are not using an existing code base or doing any maintenance for any code. 1.2 Document Conventions Bold underline Italics Typeface Indicates Headings Sections within the requirements Each requirement Our priority system is implicit, stating the objectives with higher priority first then going into greater detail of that priority, and finally moving into components of the system with lower priority. The typographical table is organized to make the document aesthetically pleasing for the reader. The Bolded parts will be the headings, the underlined parts will show the division of the sections within each heading, and the italicized text will be the title of each requirement. All the requirements are numbered throughout the document in a continuous manner regardless of the heading or subject division. 1.3 Intended Audience and Reading Suggestions This document is intended to be read by the client, the documentation readers, the developers, and the software testers, the head of the Computer Science department, and the intrigued professors. The document was written in order of which it should be read. However, if the reader wishes to only read a specific portion, all the sections are listed in the Table of contents with their page numbers stated. Additionally, the reader can skip to different areas of the document using the typographical table, if they choose to read only what the client wanted or only the higher-level priority requirements. 1.4 Product Scope This software should help the client and other users schedule courses in rooms available for the Computer Science department. Additionally, all the users should be able to view the unavailable rooms that are reserved by other academic departments in the building, Trinkle. The client can also allow access of the schedule to other teachers or academic employees at the University of Mary Washington. According to the design, the client would just provide them with their own secure user name and password to gain admission to the software. Our hope is that the website would be successful enough for other departments inside and outside of the academic building, Trinkle, to use as well. 1.5 References The previously mentioned Excel document that was used to schedule classes is on pages 8-9 of this document. We used this as a template to achieve the desired design of the schedule that will be placed on the website. The format, as can be seen on the original document, will be in the form of an interactive calendar. Additionally Karl E. Wiegers provided the Requirements document template to us.

4 2. Overall Description 2.1 Product Perspective Our client, the Office Manager of the Computer Science department at the University of Mary Washington, Jeanie Campbell, first thought of this product. The project design was devised by the client and the team members, Norah Almahdali, Dan Easterling, and Tim Mihelic. Since it is the first scheduling software that will be used by the Computer Science department it will be an original Greenfield project, and not be based off of prior code. The scheduling sheet that this product will be replacing is referenced in this document on pages Product Functions Our project is to create a software requirement document on a potential scheduling website for our client. Our client has been using a Microsoft excel document and it was being passed along to the head of the department and the teachers involved. Basically, our job is to make the sharing for this schedule easier for our client, which entails taking this schedule and placing it on a website, to make that website simple and interactive. Interactivity entails that the classes on the schedule will be linked to another page, which explains the attributes of each class. There were two big issues that were addressed about the old scheduling system: the sharing ability and the detail aspect. The sharing ability of the old excel system was time consuming; they had to physically and electronically pass along the document to get it rearranged. With a website however, users would be able to change schedules and confirm classes almost automatically if they wished to do so. As for the detail aspect of the schedule; we want to provide links on each time slot shown. The links would take the user to a page that will explain what class is being taught, which department it falls under, the section of the class, and who teaches it. This will provide sufficient information the user may need for problems regarding scheduling conflicts, including who to contact, and other available slots of time they could use instead. One low priority request was to allow other departments the opportunity to work with the schedule as well, in order to provide a better organized scheduling system with all the departments that use the academic building, since Trinkle has a minimum 4 different departments using its rooms at any given time 2.3 User Classes and Characteristics This website should be given access to only the department chairs and the office managers of specific departments. The security and privilege level of the website is set at one standard level. This means that it has a horizontal structure in regards to accessibility of the websites features, placing no user above another when it comes to the user classes. 2.4 Design and Implementation Constraints System and Network Requirements 1. Hosting: The implemented software shall be hosted and run on a UMW server that is

5 readily available for modification by the UMW Computer Science department. Rosemary shall be used unless complications arise. 2. Languages and Software tools: The desired languages and software tool kits used in the construction of this software shall be previously installed on the chosen server. 2.5 User Documentation 1. Provide documentation on setting up a new account: Must supply sufficient documentation on how to set up a new account on the website. 2. Provide documentation on the hosted website: Must supply information on the hosted website. 3. External Interface Requirements 3.1 User Interfaces Section 1: The Course Display Schedule 1. Browser and interface: The user shall interface with the scheduling software over a network, through a web browser. 2. Browsers supported: The following browsers shall be fully supported by the software: Firefox, Chrome, Internet Explorer, and Safari 3. Primary class schedule display: The primary course schedule display shall consist of two separate tables. 4. Domain of each class schedule grid: One grid shall be display information for MWF time slots, the other for TR. 5. Domain of class schedule grid columns: Each column of a grid shall represent a single room. 6. Labeling of class schedule grid columns: Each column shall be labeled above its topmost cell with the name of the room it describes. 7. Domain of class schedule grid rows: Each row of each grid shall represent a time slot. 8. Labeling of class schedule grid rows: Each row shall be labeled to the left of its leftmost cell with the time slot it describes. 9. Visual definition of class schedule grids: lines shall visually define each grid, so that cells are individually demarcated. 10. Color of grid lines: Each line visually defining the grid should be black. 11. Width of grid lines: Each line visually defining the grid should be thinner than the thinnest letter in the font used. 12. Width of column and rows: Each row and each column shall expand so that the cell within that row or column that contains the information that requires the most room to display vertically or horizontally (respectively) can be displayed within that cell without overreaching its boundaries. 13. Minimum display requirement for courses: Each cell with a course or courses associated with it shall display for each course associated, at minimum: a. The four-letter code of the department associated with the course(s) b. The three- or four- digit/letter catalog number associated with the course(s) 1. Display requirements for courses based on information available: Each cell with a course or courses associated with it shall display for each course associated, if such information was entered:

6 a. The section number of the course(s). b. Any exception to a cell representing all of MWF or TR, as appropriate. c. The actual time covered by an entry, if such time does not exactly match the time slot(s) covered by this entry 1. Department color association: Each department shall have a unique color associated with it. 2. Department color persistence across system changes: The colors associated with each department should be the colors representing each department in the existing system. 3. Use of department color associations: The text displaying the course information in each grid shall be colored in the color associated with the department that owns that course Section 2: Languages 1. Required use of English: All information shall be displayed at least once in English. 2. Precedence of English over other languages: If information is displayed in multiple languages, the English version shall be displayed first, except in the case of links directing users of another language to that languages section, until such time as the primary language of the eight or so people using this system is no longer English. 3.2 Hardware Interfaces All system level calls shall be handled through the libraries of the chosen language. Therefore, no hardware interfaces shall be required beyond the language libraries. 4. System Features 4.1 Error Handling 1. Simultaneous data entry: If two submissions happen at the same time or near the same time, no information shall be lost. 2. Data persistence across outages: If a network or power outage should occur and cause no hardware failure, no previously submitted course information shall be lost. 4.2 Input requirements 1. Number of forms for data entry: All course input fields shall appear in one form. 2. Visual definition of input fields: Information entry fields shall be visually separated from their surroundings. This separation shall consist of either a separate background color, a border surrounding the entry field, or both. 3. Data available for user to enter: The user shall be able to enter, at minimum, the following information about a course: Room, Department, Timeslots, Professor, Section, Course Number, and Schedule Anomalies 4. Room selection: The rooms available for entry shall consist of all rooms listed in the

7 existing system, as well as B12 and B Department selection: The Department shall be selectable from a drop-down box which displays the standard four-letter department abbreviations as found in the course catalog. An additional "Other" field shall be included which, if selected, activates a text field that may be used to enter a non-trinkle-standard department. 6. Minimum available text entry fields: The following fields at minimum shall be available as text entry fields a. Course number b. Course section (These fields should display at minimum 4 and 3 entered characters, respectively.) 7. Time slot field availability: There shall be five time slot entry fields, one for each day of the school week, Monday through Friday. 8. Entry of time slot use for a course: Fields for entering time slots for a course shall be in the form of drop-down boxes: These boxes shall have available an "Other" option that allows entry of non-standard times. 9. Persistence of course information across editing: Editing only part of the course information shall not destroy already submitted information that is unrelated to the edited portion of the course information. 5. Other Nonfunctional Requirements 5.1 Performance Requirements No specific requirements are given for this attribute; however, ease of use should be prioritized. 5.2 Safety Requirements No specific requirements are given for this attribute; however, ease of use should be prioritized. 5.3 Security Requirements 1. User names and passwords generation: A username and temporary password shall be automatically generated and ed to a user when such action is requested by an admin. 2. Temporary password change: The user shall be required to create a new password upon logging in for the first time. 3. Password hiding: Password characters shall be hidden upon entering password. 4. Password hashing: The password shall be hashed using either SHA-2 or SHA-3 hashing algorithms.

8 5.4 Software Quality Attributes No specific requirements are given for this attribute; however, ease of use should be prioritized. Appendix A: Glossary Definitions and Sundry: Existing system: The system currently used by department chairs and office managers to schedule courses for an upcoming semester, wherein a spreadsheet is e- mailed around and courses are manually entered in desired cells. Timeslot: Spans of time, as defined in the existing system. Appendix B: Analysis Models <Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams. > Appendix C: To Be Determined List <Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can be tracked to closure. >

9

10