Software requirement specification

6,844 views

Published on

This is another example documentation of SRS(Software requirement specification).

Published in: Education
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,844
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
545
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Software requirement specification

  1. 1. Software Requirement Specification Student registration System Rajarata University of Sri Lanka Faculty of Applied Sciences INFORMATION AND COMMUNICATION TECHNOLOGY
  2. 2. 1 | P a g e Table of Content 1. Introduction………………………………………………………………………………………………..03 1.1 Purpose…………………………………………………………………………………………..03 1.2 Scope………………………………………………………………………………………………03 1.3 Intended audience………………………………………………………………………….04 1.4 Glossary…………………………………………………………………………………………..04 1.5 References………………………………………………………………………………………05 1.6 Overview…………………………………………………………………………………………05 2. Functional Requirements……………………………………………………………………………06 2.1 Use case diagram…………………………………………………………………………...06 2.1.1 Use case for Super user…………………………………………...............06 2.1.2 Use case for Administrator………………………………………….........07 2.1.3 Use case for Student………………………………………….....................08 2.1.4 Use case for Guest………………………………………….........................08 2.2 Use cases………………………………………………………………………………………..09 Use Case 1 : Login into the system………………………………………………….09 Use Case 2 : Change user password………………………………………………..10 Use Case 3 : Add users………………………………………………………………….…11 Use Case 4 : Remove users………………………………………………………………12 Use Case 5 : Manage users……………………………………………………………...13 Use Case 6 : Edit profile information……………………………………………….14 Use Case 7 : Remove selected subjects from student's selections…..15 Use Case 8 : Create new subjects……………………………………………………..16 Use Case 9 : Edit existing subjects……………………………………………………17 Use Case 10 : Delete subjects…………………………………………………………….18 Use Case 11 : Create new subject lists……………………………………………….19 Use Case 12 : Make adjustment of credits per subject………………………20 Use Case 13 : Subject combination tool ……………………………………………21 Use Case 14 : Publish time table………………………………………………………..22 Use Case 15 : Update time table………………………………………………………..23 Use Case 16 : Current subjects by subject vice…………………………………..24 Use Case 17 : Past subject selections by subject vice…………………………25 Use Case 18 : View past & present subject selections of a student……26 Use Case 19 : Edit student's profile…………………………………………………….27 Use Case 20 : Select subjects………………………………………………………………28 Use Case 21 : Remove subjects from the list………………………………………30 Use Case 22 : Save………………………………………………………………………………31 Use Case 23 : View previous semester information…………………….………32 Use Case 24 : View Notices…………………………………………………………………33 Use Case 25 : Guest view of the student's profile……………………………….34 Use Case 26 : Super user confirmation……………………………………………….35 Use Case 27 : Access Control Matrix…………………………………………..………36
  3. 3. 2 | P a g e 3. Activity Diagram…………………………………………………………………………………………..37 3.1 Super user………………………………………………………………………………….……..37 3.2 Administrator……………………………………………………………………………………38 3.3 Student…………………………………………………………………………………………….39 3.4 Guest………………………………………………………………………………………….…….40 4. Nonfunctional Requirements……………………………………………………………………….41 4.1 Product…………………………………………………………………………………………….41 4.1.1 Usability requirements………………………………………………………...41 4.1.2 Efficiency requirements……………………………………………………….41 4.1.3 Performance requirements………………………………………………….41 4.1.3.1 Reliability requirements…………………………………………..41 4.1.3.2 Storage requirements……………………………………………..41 4.1.4 Portability requirements………………………………………………………42 4.2 Organizational………………………………………………………………………………….42 4.2.1 Delivery requirements…………………………………………………………42 4.2.2 Implementation requirements…………………………………………….42 4.2.3 Standard requirements………………………………………………………..42 4.2.4 Operational requirements……………………………………………………42 4.3 External Requirements.…………………………………………………………………….43 4.3.1 Interoperability requirements……………………………………………...43 4.3.2 Ethical requirements……………………………………………………………43 4.3.3 Legislative requirements……………………………………………………..43 4.3.3.1 Privacy requirements………………………………………………43 4.3.3.2 Safety requirements………………………………………………..43 5. Entity Relationship Diagram…………………………………………………………………………44 5.1 Entities and attributes………………………………………………………….................46 6. Class Diagram………………………………………………………………………………………………47 7. Verification and Validation……………………………………………………………………………48 7.1 Verification………………………………………………………………………………………..48 7.2 Validation………………………………………………………………………………………….49
  4. 4. 3 | P a g e 1. Introduction 1. 1.1 Purpose The purpose of this System Requirements Specification is to outline the functional, non- functional and business requirements of the “Student Registration System” of Rajarata University of Sri Lanka. The document provides a detailed overview of the software prod- uct, its parameters and goals. The requirements are documented in such a way that facilitates developers to understand the functionality to be developed along with the constraints they meet. The document would also provide assurance to the client that the development team has fully under- stood the needs of the system and would also support in validating the product delivered. 1.2 Scope The main objective of the Student Registration System is to allow internal students of the university to register for a new semester via internet. The system will maintain 3 categories of user accounts in performing the tasks. They are namely “Super user”, “Administrator” and “Student”. The Super User is given supreme privileges in the system and therefore is able to do anything in the system. S/he will also control the privilege access matrix of Administrator and Student accounts. The Administrators are of different levels of privilege depending on the tasks they perform. The administrators are entitled to manage other user accounts, to make amendments to subjects, to add new subjects and also to view student details. Students are of the lowest privilege level with only being able to register for a new se- mester, edit or view profile information, view previous and current semester information and to view notifications. All 3 categories of users must login to the system with the user name and the password to perform any of the operations. Other than the above mentioned 3 user categories the system will also allow guest users. However the guest users can only view the results of a particular student by entering the student registration number and the index number. Since the existing registration process is a manual one, the proposed Student Registration System will increase the efficiency of the registration process quite significantly while
  5. 5. 4 | P a g e providing time and cost benefits. Furthermore it will provide a sophisticated system for the enrollment thus enhancing the decision making process of the administration. 1.3 Intended Audience The document is designed for the developers of the system, ICT academic staff, and ad- ministration of faculty of applied sciences and also for any party who is interested. 1.4 Glossary Term Description Activity Diagram Shows the activities involved in a process or data pro- cessing Administrator Person of the academic or non-academic staff of Raja- rata university who is authorized to perform important operations with regard to the Student Registration sys- tem Class diagram Shows object classes in the system and the associations between them Database A collection of stored related data ER diagram Entity Relationship Diagram; Data model for describing a data base in an abstract way GPA Grade Point Average; an internationally recognized cal- culation used to find the average results Guest user A person who doesn’t has a Html Hyper Text Markup Language PHP Hypertext preprocessor; an open source scripting lan- guage Privilege access matrix A matrix that decides the tasks each user can perform. Student Internal student of Rajarata University of Sri Lanka Super user Person of the academic or non-academic staff who has the highest authority of the system Sea level Known as user goal level. Something the actor is trying to set done other levels kite level, cloud level, fish level etc.… Use case diagram Representation of a user’s interaction with the system and depicting the specifications of a use case
  6. 6. 5 | P a g e 1.5 References  UML A beginner’s guide- Jason T Roff  UML DeMYSTiFieD- Paul Kimmel 1.6 Overview of the Document The next chapter of the document is on functional requirements of the system. It covers required features of the software product and the services it provides in detail using Activity diagrams, use case diagrams. The 3rd chapter of the SRS is on non-functional requirements. This includes the emergent system properties and constraints on the system such as reliability, portability, response time. The 4th chapter includes Entity relationship diagram and class diagram. The Final chapter includes the verification and validation methods used in the Student Registra- tion System. .
  7. 7. 6 | P a g e 2. Functional requirements 2.1 Use case diagram 2.1.1 Use case diagram for super user
  8. 8. 7 | P a g e 2.1.2 Use case diagram for administrator
  9. 9. 8 | P a g e 2.1.3 Use case diagram for student 2.1.4 Use case diagram for guest
  10. 10. 9 | P a g e 2.2 Use cases Use Case 1 : Login into the system. Goal level : Sea Level Aspect : Moderators & users can log into the system to perform various actions. Trigger : When someone attempts to use system functions. Actors : Administrators of various privilege levels. Super users Students Third party users Preconditions : An activated login Necessary requirements for public users. Main Success Scenario 1. User selects a login option. 2. Login interface is produced. 3. User enters password and username. 4. System validates input against system database. 5. System accepts user type. 6. Privileged user interface produced. Alternative Scenarios 3a: Either user name field of password field is empty or contain unaccepted characters. Error message display to verify input. 1. Let’s user to re-enter username/password. 3b: Person use forgot my password. 1. System notifies to enter “email” address. 2. Action confirm by user. 3. System validates e-mail and sends information into it. 4a: Username/Password invalid 1. System notifies “invalid username/password”. 2. Let’s user to re-enter login information again, for three consecutive attempts. Exceptions: 4a: User failed to provide necessary information after all 3 attempts. 1. Interface is refreshed and directed to page asking to wait 10 minutes before next attempt. 2. Upon time lock expiration, user is directed back login interface.
  11. 11. 10 | P a g e Use Case 2 : Change user password Goal level : Sea Level Aspect : Users can change their own login password. Trigger : User clicks on “change password” after login. Actors : Administrators Super users Student users Preconditions : User must log into system. Main Success Scenario 1. User selects “change my password” option. 2. System produces change password interface. 3. User enters current password. 4. User enters new password. 5. User asked to re-enter new password. 6. User confirms change. 7. System validates current password. 8. System accepts new password and confirms. Alternative Scenarios 3a: Incorrect current password entered. 1. System notify “incorrect current password”. 2. Go to step 4. 3a: User enter unmatching password secondly. 1. System notifies that password does not match. 2. Go to step 6. Business Rules 1. Password should contain at least one upper case letter and lower case letter. 2. Password should be longer than 8 characters. 3. Password should contain at least one number. 4. Users will be given 3 attempt to log into the system, after 3rd unsuccessful attempt, user will have to wait another 15 minutes for the next attempt.
  12. 12. 11 | P a g e Use Case 3 : Add users Goal level : Sea Level Aspect : Add users into the system. Trigger : When administrator clicks on “Add users”. Actors : Administrators with sufficient privileges, Super user. Preconditions : User must be logged in, Users should possess necessary privileges. Main Success Scenario 1. User select add users’ option. 2. System displays “Add new user”. 3. User selects add a new user. 4. User enters new user name. 5. User enters new user password. 6. User selects type of the new user accounts. 7. User selects privileges level (admin/student) of new user account. 8. User modifies default capabilities of selected privilege level. 9. User enters email address associates with user account. 10. User confirms changes. 11. System prompts to enter current administrator password. 12. System validates the password. 13. System accepts changes and creates new profile. 14. Confirmation email sent to new user about his/her login. Alternative Scenarios 9a: User enters an invalid email address. 1. Go to step 10. 2. System notifies the email address is already in use or not a valid one. 3. System prompts to re-enter the email. 4a: 9a: User leaves one or more required information fields blank. 1. Go to step 10. 2. System notifies to complete all fields. 3. Systems prompts data form to re-enter required data. 11a: User enters incorrect password. 1. Go to step 12. 2. System displays an error message. 3. User enters password again. Business Rules : 1. Password should contain at least one upper case letter and lower case letter. 2. Password should be longer than 8 characters. 3. Password should contain at least one number. 4. Upon the password change, system will issue a notification email to the relevant email address with a link to reset the changes.
  13. 13. 12 | P a g e Use Case 4 : Remove users Goal level : Sea Level Aspect : Remove existing users from the systems. Trigger : When user clicks on “Remove users”. Actors : Admin Super user Preconditions : User must be logged in as an admin with required privileges or user may logged as super user. Main Success Scenario 1. User selects remove users. 2. System produces a list of users who can be removed depending on Admin’s privileges. 3. Admin searches for the desired user. 4. Admin selects the user or users from the list. 5. Admin selects remove. 6. System prompts for me admin’s password. 7. System validates password. 8. System displays confirmation messages. Alternative Scenarios 2a: Admin cannot find required user in the eligible to remove list. 1. Admin has no privileges to remove that user. 2. Admin will have to contact super user or another privileges Admin. 3a: Invalid user names entered. 1. Click “search”. 2. System will display an error message. 3. System prompt user to enter user name again. 6a: Invalid password is entered. 1. Go to step 7. 2. System notify “Invalid password” entered. 3. System prompts to enter password again. Post conditions: 1. System deletes the user information from the system. Business Rules: 1. Administrators cannot remove another Admin, only super user can do so.
  14. 14. 13 | P a g e Use Case 5 : Manage users Goal level : Sea Level Aspect : Allow/restrict certain users to perform their default privileges. Suspend user accounts temporarily. Modify user's profile type/privileges. Actors : Super user Preconditions : Users must be logged as super user. Main Success Scenario 1. Super user selects update users. 2. System will list down all users with their privileges levels and basic information. 3. Super user can select desired user and change his/her privilege level, capabilities. 4. Super user selects access control. 5. System display access control interface enable super user to allow/restrict individual users have certain features. 6. Super user selects necessary suspending options it necessary. 7. Super user confirms changes. 8. System display operation successful message. 9. System sends profile updates messages to particular users to view upon the log on. Alternative Scenarios 8a: Targeted user is logged into the system at the particular movements. 1. Systems will automatically logout the user with a notification to re-log in. 2. User will not gain access until upper user moves changes and confirm. 3. When user re-login, new configurations will be applied into his account. Business Rules: 1. Changes will be notified to users by system
  15. 15. 14 | P a g e Use Case 6: Goal level : Sea Level Aspect : Edit profile information Trigger : When user selects Edit profile information Actors : Administrators, Super user Preconditions : User must be logged in as Administrator/Super user Main Success Scenario 1. User login with their passwords and usernames. 2. User selects Edit profile information 3. System shows editable version of user's profile. 4. User make desired changes. 5. User confirms changes 6. System saves changes to the main database. 7. System displays successfully completed message. Alternative Scenarios 1a. User enters incorrect username/password 1: System notify “Incorrect password/username” error. 2: System prompts user to enter re-enter username/password. 6a.System cannot connect to the database to save changes 1: System notify “Unable to save changes” error message. 2: Retries to establish connection. Business Rules : 1. User will not be able to change username, Name, and other registration details
  16. 16. 15 | P a g e Use Case 7 : Remove selected subjects from student's selections Goal level : Sea Level Aspect : Remove subjects from the selection Trigger : User clicks on remove subjects Actors : Administrators, Super users Preconditions : User must be logged in as privileged actor Main Success Scenario 1. User logs into the system 2. Select “subject operations” 3. Select “Remove selected Subject” 4. System will display current time tables that selected subject will affect 5. Select confirmation to proceed 6. System removes subject from future student's selection lists Alternative Scenarios 4a: Use selects “Remove from the current timetables also” option 1: Subject will be removed from current timetables. 2: Relevant users will be sent notices to view upon the login. Business Rules : 1. Subject that is being currently followed, should not be removed.
  17. 17. 16 | P a g e Use Case 8 : Create new subjects Goal level : Sea Level Aspect : Introduce new subjects into the system Trigger : When user selects “Create new subjects” Actors : Administrators, Super user Preconditions : User must login as a privileged administrator, or super user. Main Success Scenario 1. User logs in as administrator/super user 2. Selects “Subject operations” 3. Selects “Create new subjects” 4. Select relevant Academic year, Semester, Stream and other details *. 5. System views current subject lists that will be affected by the modification. 6. Confirm to continue. Descriptions * Details such as Lecturer, No of credits per subject, No hours per semester, practical hours, and Subject coordinator. These details will be available in the same interface. Alternative Scenarios 5a: User selects apply modifications immediately into subject selections 1: Added subject will be available to select from subject selections immediately. Business Rules : 1. New subjects will have to be introduced with Super user approval 2. New subjects will have to get approval from UGS first
  18. 18. 17 | P a g e Use Case 9 : Edit existing subjects Goal level : Sea Level Aspect : Edit details of existing subjects and alter predefined attributes. Trigger : When user selects Edit subject’s option Actors : Administrators with relevant privileges, Super user Preconditions : User must be logged as an Administrator/ Super user. Main Success Scenario 1. User login as an Administrator/Super user 2. Select “Subject operations” 3. Select “Edit subjects” 4. Choose relevant Academic year, Semester, Stream 5. System will display subject list in editable view. 6. Make necessary changes. 7. Confirm to proceed. Alternative Scenarios 7a: Select “Apply modifications immediately” 1: Modifications will affect immediately in timetables, subject lists 2: System will notify relevant users to be viewed upon the login. Business Rules : 1. Credit level of the subject should not be altered without notifying respective parties. 2. Changes should only be applied immediately if that subject is not followed currently.
  19. 19. 18 | P a g e Use Case 10 : Delete subjects Goal level : Sea Level Aspect : Remove subjects from system. Trigger : User selects “Remove subject” option Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. User login as Administrator/Super user 2. Select “Subject operations” 3. Select “Delete Subjects”' 4. Choose relevant Academic year, Semester, Stream 5. System will display the subject list. 6. Select the subject need to be deleted. 7. Select Delete 8. Confirm to continue 9. System will remove the subject and all its related data, records. * 10. Relevant users will receive notifications on the modification. Alternative Scenarios 8a: Select “Remove from system but keep current assignments” 1: Subject will no longer available to select but will be appear on timetables 2: System will not send notifications to current students, but a general notification will be displayed about subject's discontinuity. Business Rules : 1. Subjects should be only deleted if that subject it not being followed by students at that time
  20. 20. 19 | P a g e Use Case 11 : Create new subject lists Goal level : Sea Level Aspect : Add new subject lists into the student's selections Trigger : When user selects to add subject list Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. User logs into the system 2. Selects “Subject operations” 3. Selects “Create new subject lists” 4. Selects relevant Academic year, Semester, Stream. 5. System will display “add new subject list” interface. 6. Enter Subjects and relevant details regarding them * 7. Confirm to proceed. 8. System will accept new Subject list. 9. Successful notification will be displayed. 10. Notifications will be sent to relevant users. Alternative Scenarios 7a: User selects apply changes immediately. 1: The new subject list will be available to select overriding any predefined list. 2: System will prompt if any conflicts are likely to occur. 3: If user decides to make the changes confirm, system will update accordingly. Descriptions: * No of credits, Lecturer, course content, course coordinator. Business Rules : 1. Subject lists should be able to fulfill credit requirement of a semester. 2. Before creating subject lists, prospectus should be referred.
  21. 21. 20 | P a g e Use Case 12 : Make adjustment of credits per subjects Goal level : Sea Level Aspect : Adjust no of credits defined for a Subject Trigger : User selects Adjust no of credits option Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user 1. User login as an Administrator/Super user 2. Select “Subject operations” 3. Select “Make adjustment of no of credits” 4. Choose relevant Academic year, Semester, Stream. 5. System will display subject list with credits in editable view. 6. Make necessary changes. 7. Confirm to proceed. Alternative Scenarios 7a: Select “Apply modifications to system, affecting all calculations” 1: Modifications will affect immediately in timetables and subject lists. 2: System will notify relevant users to be viewed upon the login. 3: New credit scheme will be used to calculate GPA process. 4: Relevant users will be sent notifications and notify via emails. 7b: Select “Apply modifications to system, affecting from now onwards only” 1: Modifications will affect immediately in timetables and subject lists. 2: System will notify relevant users to be viewed upon the login. 3: New credit scheme will be used to calculate GPA process in future calculations, old calculations will be remain unchanged. 4: Relevant users will be sent notifications to be view upon login. Business Rules : 1. Credit levels should be determined considering lecture hours and no of practical hours.
  22. 22. 21 | P a g e Use Case 13 : Subject combination tool Goal level : Sea Level Aspect : Subject combinations that students are able to select and incompatible combinations will be defined. Trigger : When user selects “Subject combination tool” Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. User logs into the system. 2. Selects “Subject operations” 3. Selects “Subject combination tool” 4. Selects Academic year, Semester, Stream. 5. System will display an editable matrix to select which core subjects cannot be selected with each other. 6. Select which subjects cannot be taken simultaneously? 7. System will display editable matrix to select which subjects should be taken with each other simultaneously. 8. Select which subjects that should be taken together. 9. System will show any rising conflicts. 10. User confirm changes and resume. 11. System will be updated and it will use these defined constraints when students chose subjects. Business Rules : 1. Upon adding new subjects, administrators should define subject selection constraints using Subject combination tool.
  23. 23. 22 | P a g e Use Case 14 : Publish time table Goal level : Sea Level Aspect : Creating timetables for students Trigger : User click on create timetables option Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. Subject coordinating administrators log into system 2. Create timetables and allocate practical times in Labs 3. System shows conflicts and problems likely to rise 4. User confirms timetables 5. System saves timetables and notify relevant users by notices upon login. 6. Successful message is displayed. Alternative Scenarios 3a: System detects some problems 1: User resolves issues manually changing timetables 2: With the confirmation of user, system will make necessary changes. Business Rules : 1: Timetables should be covering required no of hours for each lecture in including practical. 2: Changing and assigning subjects for time table should be completed with first week of the semester. 3: Timetable should contain end of semester and exam dates with it.
  24. 24. 23 | P a g e Use Case 15 : Update time table Goal level : Sea Level Aspect : Modify existing timetable Trigger : User selects timetable updating option. Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. Subject coordinating administrators log into system 2. Select Edit timetable option. 3. Select relevant academic year, stream, and semester 4. System view show editable timetable. 5. Edit subjects, scheduled time, practical sessions and other details 6. System shows any conflicts or likely to rise problems. 7. User confirms changes. 8. System updates databases. 9. System will send notices to relevant users which they will see upon login. Alternative Scenarios 6a. User confirms even though there's conflicts present 1: System will alert before proceeding into next step. 2: User's decision will be in effect after confirmation. 8 a: Database update fails 1: Changes will not be in effect. 2: System will try to establish connectivity again. 3: System will notify when the update is completed.
  25. 25. 24 | P a g e Use Case 16 : Current subjects by subject vice Goal level : Sea Level Aspect : View student's selections by subject vise Trigger : User selects to view student's current subject selections Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. User logs into the system 2. Select “View student's choices” option. 3. Enter student's index number 4. Confirm to proceed. 5. System will display information view interface with options. 6. Select “Current subjects by subject vise” 7. Exit interface after viewing. Alternative Scenarios 3a: Invalid index no is entered 1: Go to step 4 2: System will notify with “Invalid Index Number” error message. 3: Enter Index number again Business Rules : 1. Only viewing, no editing capability is provided.
  26. 26. 25 | P a g e Use Case 17 : Past subject selections by subject vice Goal level : Sea Level Aspect : To view student's past subject selections Trigger : User selects view student's subject selections option. Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. User logs into the system 2. Select “View student's choices” option. 3. Enter student's index number 4. Confirm to proceed. 5. System will display information view interface with options. 6. Select “Past subjects by subject vise” 7. Exit interface after viewing. Alternative Scenarios 3a: Invalid index no is entered 1: Go to step 4 2: System will notify with “Invalid Index Number” error message. 3: Enter Index number again Business Rules : 1. Only viewing, no editing capability is provided.
  27. 27. 26 | P a g e Use Case 18 : View the past and present subject selections of a student Goal level : Sea Level Aspect : View all past and present subject selection of student. Trigger : User select the subject selection option. Actors : Administrators with relevant privileges, Super users Preconditions : User must be logged as an Administrator/Super user Main Success Scenario 1. User logs into the system 2. Select “View student's choices” option. 3. Enter student's index number 4. Confirm to proceed. 5. System will display information view interface with options. 6. Select “Past and present subject selections by subject vise” 7. Exit interface after viewing. Alternative Scenarios 6a: Select “View student's subject selection overview” 1: System shows student's subject selection history. 6b: Select “View all student's subject selection overview” 1: Enters desired subject stream. 2: Enters an Academic year, semester and a calendar year. 3: System shows subject selection history for that time period of all student's. Business Rules : 1. Only viewing, no editing capability is provided.
  28. 28. 27 | P a g e Use Case 19 : Edit student's profile Goal level : Sea Level Aspect : Let student to edit his/her profile Trigger : Student selects Edit profile option Actors : Student user Preconditions : Users should login to system as student users Main Success Scenario 1. Users log into system using username/password 2. System provides an editable interface of student's profile. 3. Edits selected data and values. 4. Selects other options if needed. 5. Confirms changes 6. System saves details into database. Alternative Scenarios 1a: Invalid username/password entered 1: Go to step 5 2: System produces an “Invalid password” error. 3: System lets user to re-enter password/username 6a: Database is not available 1: System notify an Error saying “Error in connectivity” 2: System will not save any configurations due to risk of data loss. 3 System will try to establish connectivity again. Business Rules : 1. Users are only able to remove subjects within the time duration declared by Administrator 2. After expiring the time period to modify subjects, users will have to contact an Admin for any inquiries.
  29. 29. 28 | P a g e Use Case 20 : Select subjects Goal level : Sea Level Aspect : Student user can select their subjects from available subject lists Trigger : User selects “Select subjects” option Actors : Student Users Preconditions : User must be logged as a Student Main Success Scenario 1. User login as a student with his/her username/password. 2. Selects “Select subject” option 3. System determines Student's academic year, semester, and stream 4. System determines whether student is eligible to take subjects* 5. System displays available subject list 6. Student selects desired subject levels under defined constraints** 7. User confirms changes. 8. System will check necessary requirements of the selection. 9. System displays time period remaining to alter student's selection. 10. System saves changes into the databases. 11. System notify Successful operation message. Descriptions * Administrator will define a time period that a student can select subjects, alter their choices at the begin of the student enrollment. After expiring this time period, any student will not be able to select or change courses without contacting a system administrator with relevant privilege levels. ** Subject administrators will introduce certain constraints for subject selections depending on the Department heads. Students will not be able to take some subjects along with certain subjects, and some subjects will be compulsory which cannot be skipped though credit level is met. Alternative Scenarios 1a: Invalid username/password entered 1: System produces an “Invalid password” error. 2: System lets user to re-enter password/username. 8a: Predefined no of minimum credits per semester is not met. 1: System notify the “Incomplete Selection” error.
  30. 30. 29 | P a g e 2: User re-arrange his/her selection. 3: System will save changes. 8b: Predefined no of minimum credits per semester is not met. 1: System notify the “Incomplete Selection” error. 2: User select to skip the process for now. 3: System displays contact details of relevant subject coordinator. 4: System will not save any details of the session. Business Rules 1. A semester will have to have a minimum number of credit for all children in all streams. This limitation will be vary with the university. 2. Student may chose more than required minimum level for a semester but not less than it.
  31. 31. 30 | P a g e Use Case 21 : Remove subjects from the list Goal level : Sea Level Aspect : Student can remove subject that he/she selected earlier Trigger : When student user needs to change subject selection Actors : Student users Preconditions : User must be logged as Student user Main Success Scenario 1. Selects “Remove subjects” option. 2. System determines that student is eligible to make changes to subject selection.* 3. System displays editable view of subject list. 4. User selects necessary subject's to be removed. 5. User confirm changes and continue. Descriptions * If the administrator defined time period is expired then user will no longer able to alter any of his selections. (E.g. after two weeks of enrollment time, students are no longer able to change their subjects) Alternative Scenarios 2a: User is no longer able to alter selections 1: System notifies that user is no longer able to perform this action 2: User may have to contact relevant administrator to do the necessary changes. Business Rules : 1. Changes can be done only within the time period Administrator defined. 2. After enrollment period expired, students will have to contact administrator to make any changes.
  32. 32. 31 | P a g e Use Case 22 : Save Goal level : Sea Level Aspect : Save changes users make in the system into database Trigger : When any user make an update, input a data into the system Actors : System Preconditions : Relevant database is connected and connection is up. Main Success Scenario 1. System detects any changes as user confirm his/her actions 2. System connects to the database 3. System save changes into the system. Alternative Scenarios 2a: Database is not available 1: System notify an Error saying “Error in connectivity” 2: System will not save any configurations due to risk of data loss. 3 System will try to establish connectivity again. Business Rules : 1: Database connectivity should not be down more than an hour during working days. 2: During enrollment duration, database should maintain high level of reliability, thus it should accompanied with methods to increase its performance without compromising minimum requirements.
  33. 33. 32 | P a g e Use Case 23 : View previous semester information Goal level : Sea Level Aspect : Student will see an overview of his/her previous semesters Trigger : Student selects “View previous semester’s information” option. Actors : Student users Preconditions : User must logged in as student actors Main Success Scenario 1. Selects “View previous semester information” 2. Systems shows student's academic history and current GPA Alternative Scenarios 2a: User selects “View list of semesters” 1: System will display all available information on student's academic history. 2: A GPA chart for class distinctions will be displayed bottom of the page. 3: A GPA calculator will be available to use. Business Rules : 1. Only viewing, no editing capability is provided.
  34. 34. 33 | P a g e Use Case 24 : View Notices Goal level : Sea Level Aspect : Student's will see important notices generated by system changes, and administrators. Trigger : When there's a change occurred, a relevant notice will be generated. Actors : System, Administrators Preconditions : User must log into the system as a student user. Main Success Scenario 1. User see available notices upon the log in. 2. Some important notices will be received via E-mails also. Alternative Scenarios 1a: User does not log into the system to view the notice. 1: All notices will be kept in a database, and will be available upon user login... Business Rules : 1. Student user will have an inbox capable of holding 20 notices, Administrator will have an inbox of 100 notices and user should clean inbox occasionally.
  35. 35. 34 | P a g e Use Case 25 : Guest view of the student's profile Goal level : Sea Level Aspect : People outside the system will be able to view records of a student with his index number. Trigger : When someone outside the system logged into the system. Actors : Guests Preconditions : Guest user logs into the system using index number and guest password. Main Success Scenario 1. User views student's academic performance. 2. System displays additional contact information of referees. Alternative Scenarios 1a: User selects to view addition details. 1: Users can view student's past academic related activities, projects and extra activities. Business Rules : 1. Guest view is for the Prof Purposes in various situations. For example, online searching in the interviews is common practice today. This Guest profile will facilitate that, and the guest user account will require student's index number and a password provided by the student. But guest view will not display any private information other than required performance Profs.
  36. 36. 35 | P a g e Use Case 26 : Super user confirmation Goal level : Sea Level Aspect : Super user login should be handled with extra security, this method will confirm super user identity other than username/password, its use E-mail confirmation also. Trigger : When a super user logs into the system with username/password Actors : Super user Main Success Scenario 1. Super user enter username/password into the system. 2. An additional email will be sent to the assigned email account with a key. 3. User logs into the relevant email and enter the Key to the login 4. System authenticates super user login. Alternative Scenarios 3a. Entered key is not matching to the system's key 1: System notifies about mismatch. 2: User is given another attempt to re-enter the key. Business Rules : 1. Upon the entering correct username/password, system will send special random access code to the related email address of the user account. And user will have to provide this code into the confirmation interface. 2. This confirmation will have to best quickly, eliminating unnecessary delay.
  37. 37. 36 | P a g e Use Case 27 : Access Control Matrix Goal level : Sea Level Aspect : Super user defines other administrator's privileges and access capabilities Trigger : When user selects “Access Control Matrix” Actors : Super users Preconditions : User must be logged as a Super user Main Success Scenario 1. Super user selects “Access control Matrix” 2. User “selects subject operation” combo box. 3. Define what each user is capable of doing. 4. System sends notification to other users if “send notifications” selected. 4. Exits the interface. Alternative Scenarios: 1a: User selects different categories from the selections 1: System displays relevant matrix below. 2: Changes are recorded to database. 3: If asked, notifications will be sent to users. Business Rules : 1: Super user will give proper capabilities to other users but not all privileges to one Admin. This will share responsibilities among Admins and it'll be easier to manage duties. 2: Administrators may not be technical professionals and tend to be careless on security. So admins will not get all the privileges of a super user, in case of a security breach, system's damage will be minimal. 3. All the important privileges should not be accessible to a one admin. 4. Super user can define what others may see, access and operate.
  38. 38. 37 | P a g e 3. Activity diagrams 3.1 Super user
  39. 39. 38 | P a g e 3.2 Administrator
  40. 40. 39 | P a g e 3.3 Student
  41. 41. 40 | P a g e 3.4 Guest
  42. 42. 41 | P a g e 4. Nonfunctional requirement 4.1 Product Requirements 4.1.1 Usability Requirements  The Student Registration System shall include three types of accounts; Super User, Administrators and Students.  To login to the system user name and password is required. The user name shall be name of the user and the password as they prefer.  If a password is forgotten by a system user, an e-mail should be sent to the relevant e- mail account with a recovery password within 2 minutes.  The system should be implemented with simple HTML interfaces for it to be easy to understand and easy to learn.  Interface action and elements should be consistent.  Only limited attractiveness is required since the system is for the internal university community.  There should be help pages included that explain how to achieve common tasks.  It should also include error messages explaining how to recover from the error.  The actions which cannot be undone should ask for confirmation. 4.1.2 Efficiency Requirements  The system should response to user actions within 20ms  The system should handle 100 users/second 4.1.3 Performance Requirements 4.1.3.1 Reliability Requirements  Database processing time should not exceed 100ms  The system shall facilitate data integrity  Downtime with in a day should not exceed 100ms  The system shall be available 24 hours everyday 4.1.3.2 Storage Requirements  The space provision for images should not exceed 200mb  The space provision for the database should be greater than 10GB  If a student drops a selected subject that should be removed from the relevant tuple of the database
  43. 43. 42 | P a g e 4.1.4 Portability Requirements  Users should be able to log in to the system through a PC, a laptop or a smartphone 4.2 Organizational Requirements 4.2.1 Delivery Requirements  The system shall be deployed within six months  The system shall be completed within the allocated budget. 4.2.2 Implementation Requirements  The web based student registration system should be implemented with HTML and CSS for interfaces, PHP for sever side scripting, Java script for the validation and MYSQL for database management system.  The environment that shall be hosting the system should contain minimum hardware requirements.  The environmental that shall be hosting the system should contain minimum software requirements. (Windows XP/ Vista / 7, Linux Debain 6.*, operating system, PHP version 5.3.)  The university staff will shall be provided with training upon implementation. 4.2.3 Standard Requirements  A student shall complete minimum of 30 credits per semester.  Cancellation of a registered subject is permitted within 14 days of selection and it is sub- ject to the decision of the Super user.  Registration cancellation deadlines for courses should be available in the course infor- mation. Contact Super user for more information.  Public viewer shall be able to search results of a particular student by entering the student index number and the registration number. 4.2.4 Operational Requirements  University will require appropriate staff and other resources for the new system.  There shall be an initial Super User in the system, who can login in to the system.  The Super user shall create accounts for the administrators.  The Administrator shall create accounts for the students.
  44. 44. 43 | P a g e 4.3 External Requirements 4.3.1 Interoperability requirements  The system shall be interoperable with the other existing systems of the university. 4.3.2 Ethical requirements  GPA should be calculated in accordance with the standard procedure.  The super user shall not be permitted to change students’ personnel data. 4.3.3 Legislative requirements 4.3.3.1 Privacy requirements  The system shall not disclose personnel information of students to unau- thorized users or public. 4.3.3.2 Safety requirements  Guest users must not be able to edit any information  The system shall be facilitated with a backup file system
  45. 45. 44 | P a g e 5. Entity relationship diagram
  46. 46. User Super User Administrator Student Department Course ControlMatrx ResultPrevi ew Notice TimeTable Subjects SubjectList CurrentSeme ster ImportantDay s Name SuperUserID AdminID Reg_No DeptName CourseName Admin-ID CourseCode NoticeID Coursename SubName SubName SemNo StartDate Password AdminLevel IndexNo Name SubjectName Title Day CourseCode CourseCode SubNmae EndDate E mail Name Add users Result Description Time Credit Year ExamDate Mobile Remove users Credits Author SubjectName Year Manage users TotalGPA BeginimgDate Code Semester View users Profile EndingDate Coordinator Remove selected subject from selection Create new subjects Edit existing subjects Delete subjects Create new subject lists Make adjustments of no of credits Subject combination tool Time table management Create time table Update time table View student choices
  47. 47. 5.1 Entity and Attributes Result preview Reg-no Index-no Course code Name Sub-name Result Credits Total GPA Subjects Code Semester Year Credits Sub-name Admin-ID Stu- dent Reg- no In- dexNo Fname Lname Mo- bile Dept- name Course name Pass- word Email Name Sem- no Year Important days Sem-no Year Sub-name End date Start date Exam date Compulsory Sub-name Credit Code Year Semester Optional Sub-name Credit Code Year Semester Notices Title Start date End date Author Description Notice-ID Admin-ID Super user Super user ID Include Course name Code Course Course name Dept-name Admin Admin-ID Admin-level User Name E-mail Password Current semester Sem-no Year Sub-name Time table Code Day Time Sub name Course name Subject list Course code Subject name
  48. 48. 47 | P a g e 6. Class diagram
  49. 49. 48 | P a g e 7. Verification and Validation Verification and Validation is a process that should be applied to all stages of the software development life cycle. 7.1 Verification Verification is the process of assuring that the software meets its specifications. This is a human based approach to ensure that the software is as per the requirements specification.  Validity check : Checking the extent to which the requirements of each stakeholder is met and the compromises made.  Consistency check : Checking whether the requirement contradict with each other.  Completeness check : Checking whether the SRS covers all the functional requirements of the Student Registration System  Realism check : Checking whether the identified requirements can be met with the existing technology, budget and time constraints. To perform the above checks we will be using the following activities.  Requirements review : This approach is where the requirements are analyzed by a review team systematically. The review team will be consisting of members of the development team and academic and non- academic staff members.  Inspection : This is involves a team of inspectors who will be given the code and associated documents to discover errors. The inspection team will consist of some of the developers and representatives of the client.
  50. 50. 49 | P a g e  Walkthroughs : This is an informal approach which involves both developers and the client of the Student Registration System. This will be helpful in achieving a common understanding and to gather feedback. 7.2 Validation This is the dynamic mechanism of validating and testing the Student Registration System. This involves executing the code.  Prototyping : An executable model of the Student Registration System will be given to the client and the end users. The prototype then will be used to identify necessary changes to the requirements.  Test case generation : Test cases are generated based on test scenarios produced. There will be number of test scenarios for the Student Registration System on which test cases are developed. e.g.: Checking the functionality of the login button. The test cases for this scenario will be: o Click the button without entering the user name and password o Click the button after only entering user name o Click the button with wrong username and wrong password o Click the button with correct username and wrong password o Click the button with correct user name and correct password  Component Testing : The different components of the Student Registration System is tested in Isolation. e.g.: Login component: test whether the component can check the validity/invalidity of a given username and password.
  51. 51. 50 | P a g e  Integration Testing : Testing the system for correct interactions between the system components. This will be done by developer/testers with the use of test cases. Integration testing will discover the inconsistencies in the combination of components. E.g.: testing whether “login” component route to the “student” component without causing problems when a student successfully login to the system.  Stress Testing : This is the test which is performed to test how a system behaves when it fails. Stress testing is carried by exercising the system beyond its maximum design load or by taking away resources to identify the breaking point. e.g.: o Test how the system reacts when 125users/sec log in to the Student Regis- tration System. o Shut down or restart of network ports randomly o Turning the database on and off  Security Testing : This involves testing the Student Registration System in order to identify flaws and gaps from security and vulnerability point of view. The following aspects of the system is tested under security testing; o Confidentiality o SQL insertion attacks o Data security o Authorization o System is according to all security regulations
  52. 52. 51 | P a g e Team name: Humming Bird Team leader: W.D.R.Y. Jayasundara Members: Y.M.Y.T.K Yaparatne ICT/10/11/050 2687 K.Gunawardana ICT/10/11/008 2640 K.A.D.C.P. Kaluarachchi ICT/10/11/057 2650 S.D. Thrimawithana ICT/10/11/032 2675 W.D.R.Y. Jayasundara ICT/10/11/013 2648

×