Smart School SRS

Software Requirements Specification for Smart School Learning Platform Page 1
Software Requirements
Specification
for
Smart School Learning Platform

Version 1.0
Prepared by
Group Name: Scorpio
Jebesa Temesgen 1762/10 jebesatemesgen01@gmail.com

Chala Borena 1746/10 chalinan143@gmail.com
Gadise Alemayeh 1752/10 gadisealemayehu@gmail.com
u
Nafol Abdisa 1753/10 aponan122@gmail.com
Jilo Bedecho 1754/10 jalobe25@gmail.com
Adviser: Mr. Rajasekhar B.

Contents
1 Introduction...................................................................................................................................4
1.1 Document Purpose....................................................................................................................5
1.2 Product Scope...........................................................................................................................5
1.3 Intended Audience and Document Overview...........................................................................5
1.4 Definitions, Acronyms and Abbreviations...............................................................................6
1.5 Document Conventions............................................................................................................6
1.6 References and Acknowledgments...........................................................................................6
1.6.1 References.........................................................................................................................6
1.6.2 Acknowledgments.............................................................................................................7
2 Overall Description.......................................................................................................................8
2.1 Product Overview.....................................................................................................................8
2.2 Product Functionality...............................................................................................................9
2.3 Design and Implementation Constraints................................................................................10
2.4 Assumptions and Dependencies.............................................................................................10
2.5 user characteristics..................................................................................................................10
3 Specific Requirements................................................................................................................11
3.1 External Interface Requirements............................................................................................11
3.1.1 User Interfaces................................................................................................................11
3.1.2 Hardware Interfaces.......................................................................................................11
3.1.3 Software Interfaces.........................................................................................................12
3.2 Functional Requirements........................................................................................................12
3.3 Use Case Model......................................................................................................................13
3.3.1 Login Use Case (U1)......................................................................................................17
3.3.2 Manage Accounts Use Case (U2)...................................................................................18
3.3.3 Manage Academic Operations (U3)...............................................................................19
3.3.4 Manage Notifications (U4).............................................................................................20
3.3.5 Manage Exam Use Case (U5)........................................................................................20
3.3.6 Generate Timetable Use Case (U6)................................................................................21
3.3.7 Send Message (U7).........................................................................................................22
3.3.8 View Profile (U8)............................................................................................................23
3.3.9 Attendance Report (U9)..................................................................................................24
3.3.10 Select Subject Preference Use Case (U10).....................................................................25
3.3.11 Video Conference Use Case (U10).................................................................................26
3.3.12 Create Lesson Plans Use Case (U10)............................................................................27
3.3.13 View Library History Use Case (U10)...........................................................................28
3.3.14 Manage Book Store Use Case (U10)..............................................................................29
3.3.15 View Mark Report Use Case (U10)................................................................................30
3.3.16 Take Exam Use Case (U10)............................................................................................31
3.3.17 View Child Status Use Case (U10).................................................................................31

4 Other Non-functional Requirements........................................................................................33
4.1 Performance Requirements....................................................................................................33
4.2 Safety and Security Requirements..........................................................................................33
4.3 Software Quality Attributes....................................................................................................33
4.3.1 Availability......................................................................................................................33
4.3.2 Portability.......................................................................................................................34
4.3.3 Correctness.....................................................................................................................34
4.3.4 Maintainability...............................................................................................................34
Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table does 00/00/00
and not need to be filled in whenever a document is
Number touched, only when the version is being upgraded.
1 Introduction
Now we are in technological century. With new day, new generation with new idea and creativity in
the existed world is born daily. The advancement of computer is enabling us to speak about
technology. The evolution of computer comes up with intelligent technology. One of the remarkable
and much known products of technology advancement is the Conversion of manually system into
automated system. Automation produces a great impact in the lives of man, particularly in the field of
industry, business, medicine, and Education. Nowadays education plays a great role in development
of any country. Many of education organizations try to increase education quality. One of the aspects
of this improvement is managing of school resources. helps to overcome boring paper work in school.
This Application is very easy to use. It can work accurately and very smoothly in different scenario. It
reduces effort work load and increase efficiency in work. In aspects of time value, it is worthy.
The “Smart School Learning Platform” has to be developed to override the problems prevailing in th
e practicing manual system. This system is supported to eliminate and in some cases reduce the hard
ships faced by this existing system in schools. Moreover this system is designed for the particular
need of the school to carry out operations in a smooth and effective manner. The Purpose of SSLP is
to automate the existing manual system by the help of computerized equipment’s and full-fledged
computer software, fulfilling their requirements, so that their valuable data/information can be
stored for longer period with easy accessing and manipulation of the same. It can lead to error free,
secure, reliable, and fast management system. Smart School Learning Platform, as described above,
can lead to error free, secure, reliable and fast management system. It can assist the user to
concentrate on their other activities rather to concentrate on the record keeping. Thus, it will help
organization in better utilization of resources. At present the school learning system and it’s all
procedures are totally manual based. It creates a lot of problems due to wrong entries or mistakes in
totaling etc. This system avoided such mistakes through proper checks and validation control
methods in checking of student record, teachers schedule, examination report, issue of transfer
certificates etc.
1.1 Document Purpose

This document is provided to explain about software requirements specification of Smart School
Learning Platform and is the first version. The document describes about overview of the system
being developed, scope of the project, objectives and goals of the project, functional and non-
functional requirements of the system, references used in this document and other necessary things
are included.
1.2 Product Scope
Any School has its own learning systems that are given in manual based ways. So, this existing
system are not well developed to go with the current involvements of technology that around us. In
order to develop the automated learning platforms, we have to change the existing system to web
based. It gives one school to become smarter by using this web-based system in its school managing
system. Also helps parents to follow-up their child status without going to school.
The scope of our project to automate the schooling system in one school to become smarter.
Our project scope is further limited to:
Add Students and staff to Registration database
Facilitates the managements of library
Enable the users to directly send any messages to others
Localization of the system to (Afaan Oromo, Amharic, English)
Enable the video conference
Easily search and print the information.
Facilitate the exams for students
1.3 Intended Audience and Document Overview
Any one, who is interested to read this document, the better way is to start from introduction because
the introduction clearly states the aim of this document and for what purpose the document is written,
for system developers there is use case diagram that help them to understand the system functionality
using standard UML diagram. The sections are divided based on the IEEE template and there is a
table that use to illustrate the meaning of the use case so, you can see that for better understanding of
the use case or about the system functionality. Because there is information in the document that are
relevant for validation and verification of the system, which is the job of tester, so the testers can also
be benefited from this document.
1.4 Definitions, Acronyms and Abbreviations

We use some abbreviation and acronyms to simplify the process of reading and writing this document
and they are listed below:
Acronyms Definition
SSLP Smart School Learning Platform
HU Haramaya University
UC Use Case
UML Unified Modeling Language
SDLC Software Development Life Cycle
SRS Software Requirement Specification
IEEE Institute of Electrical and Electronics Engineering
1.5 Document Conventions

In general, this document follows the IEEE formatting requirements.
Formatting conventions:
 All text contained in this document is 12pt Times New Roman font
 Section titles are 18pt Times New Roman font.
 Subsection titles are 14pt Times New Roman font.
 Any further subsection breakdown is 12pt Times New Roman font.
 All sections and subsection are numbered using the X.X.X... format, where X represents
numbers.
 Document text will be single-Spaced and maintain 1” margins
 Italics for comments and 1.5-line spacing format.
1.6 References and Acknowledgments

1.6.1 References
The SRS template from the department

Bober, M. (2001). School information systems and their effect on school operations and
culture. Journal of Research on Technology in Education, 33(5), 1-11.
Fulmer, C. (1995). Maximizing the potential of information technology for management:
Strategies for interfacing the technical core of education. In B. Barta, M. Telem, and Y. Gev
(Eds.), Information Technology in Educational Management (pp 1-8). London: Chapman and
Hall.
J. G. Hedberg et. al. (1992). Educational information systems: Problems of the small
educational organization. Australian Journal of Educational Technology, 8(2), 132-160.
http://www.ascilite.org.au/ajet/ajet8/hedberg.html
www.acadamia.edu and etc.
1.6.2 Acknowledgments
First of all, we would like to thank God for giving our health and patience to accomplish this proposal
works successfully and giving our strength on difficult times. We would like to express our gratitude
to our advisor Mr. Rajasekhar B. for his guidance, support and his continuous enthusiasm and
encouragement throughout the project. We would like to also acknowledge the department of
software engineering for the unremitting support.
Finally, many thanks to friends, who have helped and given us suggestions, supports and corrections
throughout the project.
2 Overall Description
2.1 Product Overview

We are building a system that can automate the manual way of learning and managements of one
school to became more automated in advance of to enable the school more digitalized. The system
will work like the normal flow of work that was done in one school but in our system, it is more
computerized rather than manually. The following diagram shows how our system interacts with its
environment and in which context it will be used.
Administrator
Smart School
Learning
Platform
Staff Employer
Librarian
Parent
Database
Student
Figure 1 Product Overview
The system will be build using two frameworks for the front and back end, which are bootstrap and
php for the frontend and JavaScript for the backend. The business process logic of the backend
process is controlled by JavaScript and even some php parts. And also, we will use Agile model for it
may help us for developing such like this project in effective and efficiently.
2.2 Product Functionality

The functionality of our product is summarized as follow with the actors.
Administrator
Login to the system

Manage user accounts
Manage Academic operations
Add users to the system
Create notifications
Send messages
Librarian
Check students and staff book issues status

Add another asset to system
Check book return dates of user
Send message
Staff
Select subject preferences

Create lesson plans
Send messages
Student
Login to the system

Take quiz
View timetable
Check library history
Send messages to the school employers
Parent
Check the status of their student

Buy any available resources
Send messages to the school employers or to teachers
2.3 Design and Implementation Constraints

Constraints: The constraint associated in the development of any software system includes those that
are common to all system. The common constraints may include lack of managerial participation
tighter development schedule etc. some of the constraints of the proposed systems are:
The system is web based, it provides website so in order to make sure the project complete
successfully the developer must have enough knowledge about: -
 The system should be secured from SQL injection and CSRF (Cross-site request forgery)
Attack.
 The system should be component based.
 Object oriented concepts.
 UML modelling language.
 Knowledge on HTTP, SDLC.
Necessary tools like Enterprise architect for UML modelling. The device to be used required to have
at least 8GB installed memory and to be at least core i3 and to have processor speed 2.87GHz.
2.4 Assumptions and Dependencies

In order to complete this project successfully it is assumed that the following things are available
Good quality internet connection
Required resources are available
The information of school is available
The team members are cooperative and do their role effectively
Assuming that there is not required special learning
2.5 user characteristics
The intended user of the product is generally the school headmaster, staff employer, librarian
employer, parent of student, students are considered user of the product.
User Their Role

Admin Manage Overall activities in school
Staff Select subject preferences and conduct class
Librarian Manage library activities and book issues
Parent View their child status and send messages
Student View their account and take books, quiz’s,
3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
The project works as an interface between the user and the system by properly guiding the user how
to use it and perform operations. Any sort of training is not required for using the system. It is
important that the system is easy to learn. The input device is given to keyboard and the output is
viewed on the monitor.
We we’ll strive to create a user interface that is usable and easy. The web system will have a
responsive layout so that it can be accessed from any devices easily. Our System will give the same
functionality on any screen sizes (i.e. mobile device, tablet, pc).
For any inputs, there will be a client-side validation on the forms so that it is possible to control data
entry error. There will be a confirmation message for every task which can alter the database by any
means. It is possible for the user to adopt most of browsers.
JavaScript developer’s community provides us with a lot of validation libraries (i.e. hapi/joi) which
we can adopt into our system.
3.1.2 Hardware Interfaces
Any device (i.e. mobile device, tablet, and pc) that has both a web browser and internet connection
can access the system.
The hardware tools required to develop the system are:
Computer (laptop): Processor – core i3 @ 2.3 GHz, RAM - 4 GB and Hard Drive - 120 GB.
Backup Device: External hard drive and USB Flash Drive
Printer: helps to print documentations
Writing material (pen, paper and Notebook): - for writing all necessary information
associated with the project during interview or time of data collection
Cable: for internet connection
3.1.3 Software Interfaces
The Software Tools

Window: Microsoft Windows 7 and higher
XAMPP Server: because it is: -
- It is used in any (X) operating system.
- Provides an intuitive interface to configure MYSQL database server
Text editor: sublime text3
Web browser: Mozilla, Chrome, Internet Explorer
Microsoft Office 2019: for documentation
E-drawMax8 & visual paradigm: -For designing UML diagrams.
Front-End Development Tools:
 Hypertext markup language (HTML): For creating web visual components
 Cascading style sheet (CSS): For layout design, content decoration in user interface design
 JavaScript (JS): For interactivity of the web page
Back-End Development Tools:
 Hypertext Preprocessor (PHP): For Backend implementation of the project.
 MYSQL: for database.
 Apache: For the server because by Default bundled with PHP and MYSQL
3.2 Functional Requirements

Functional requirements are a function or feature that must be included in our system to satisfy
the system needs and be acceptable to the user. So, it is a statement of exactly what the system
must do. Functional requirements must be included in the system. Those are:
The major functional requirements of the project are:
3.2.1 F1: The system should authenticate and authorize the admin and allow him to create an
account for Staff, Librarian, Students and Parents.
3.2.2 F2: The system should authenticate the Staff, Librarian, students and also parent accounts using
their login information and authorize them in order to function properly.
3.2.3 F3: The system should allow the users in the system to create video conference and facilitate
the communication in the school.
3.2.4 F4: The system should allow the multi-language preferences
3.2.5 F5: The system should allow the students to message to their teacher through the system
3.2.6 F6: The system performs to prepare some certificates and Id for the students
3.2.7 F7: Post a new notification for all users as its necessity
3.2.8 F8: users of the system can manage account of their self.
3.3 Use Case Model

A use case is a list of actions or event steps typically defining the interactions between a role of an
actor and a system to achieve a goal. Use cases define interactions between external actors and the
system to attain particular goals. The diagram is used to model the system/subsystem of an
application. It is used to gather the requirements of a system and identify the external and internal
factors influencing the system.
The system has 5 Actors:
 Admin => Staff => Librarian => Student => Parent
Admin Use Case Model
Staff Use Case Model

Librarian Use Case Model
Student Use Case Model

Parent Use Case Model

3.3.1 Login Use Case (U1)
Author Nafol Abdisa

Purpose Set of credentials used to Admin, Librarian, staff, students and parent.
Requirements Traceability The system must load successfully.
Priority High
Preconditions The user must have account in the system.
Post conditions Logged into the system successfully
Actors Admin, Librarian, staff, students and parent.
Extends Display error
Flow of Events 1. Basic Flow
a. The system displays the home page.
b. Click Login button.
c. Insert required information (like: username, password)
d. Click login button.
e. Use Case Ends.
2. Alternative Flow
c. if the user already logged in display dashboard.
d. use case ends.
3. Exceptions: - If the user inserts invalid username and password
the system must display error message and ask the user to re-enter
the fields again.
Includes Verify password
3.3.2 Manage Accounts Use Case (U2)
Author Jilo Bedecho

Purpose For the Admin to manage accounts in the system
Priority High
Preconditions Only the Admin can perform this task.
Post conditions Successfully manage accounts
Actors Admin

e. Manage Accounts.
f. Use Case Ends.
2. Alternative Flow
c. If the user already logged in display dashboard.
d. Manage accounts.
e. Use case ends.
3. Exceptions: - If the user insert invalid username and password the
system must display error message and ask the user to re-enter the
fields again and if the user insert unappropriated information it
will be rejected and display error and ask for re-enter the
information.
Includes Account check
3.3.3 Manage Academic Operations (U3)
Author Jebesa Temesgen

Purpose For the Admin to manage accounts in the system
Priority High
Post conditions Successfully manage Academic operations.
Actors Admin

e. Manage Academic Operations.
f. Use Case Ends.
2. Alternative Flow
d. Manage Academic Operations.
e. Use case ends.
3. Exceptions- If the user insert invalid username and password the
system must display error message and ask the user to re-enter the
fields again and if the user insert unappropriated information it
will be rejected and display error and ask for re-enter the
information.
3.3.4 Manage Notifications (U4)
Author Gadise Alemayehu

Purpose For the Admin to manage notifications in the system and for other
users to view the notification which is posted by Admin
Priority High
Preconditions Only the Admin can post the notification and the other users only see.
Post conditions View the notification
Actors Admin, Staff, Librarian, Student and Parent
e. View Notification.
f. Use Case Ends.
2. Alternative Flow
d. View Notification.
e. Use case ends.
3. Exceptions
3.3.5 Manage Exam Use Case (U5)

Purpose For the Admin to manage Exams, by making the exam available in
exam bank and preparing the schedule of exam in the system
Priority High
Post conditions Successfully exam content is loaded.
Actors Admin
e. Manage Exam.
f. Use Case Ends.
2. Alternative Flow
d. Manage Exams.
e. Use case ends.
3. Exceptions
3.3.6 Generate Timetable Use Case (U6)
Author Chala Borena

Purpose For the Admin to generate timetable for the school.
Priority High
Post conditions Successfully timetable is generated.
Actors Admin
e. Click Generate Timetable.
f. Use Case Ends.
2. Alternative Flow
d. Generate Timetable.
e. Use case ends.
3. Exceptions
3.3.7 Send Message (U7)
Author Nafol Abdisa

Purpose For the all users in the system to share any message directly to each
other
Priority Medium
Preconditions All the user must have to login to the system.
Post conditions Successfully Message is sent to the account

e. Click Send message.
f. Use Case Ends.
2. Alternative Flow
d. Click send message.
e. Use case ends.
3. Exceptions
3.3.8 View Profile (U8)

Purpose For all users to view their profile and update.
Priority High
Preconditions All the users can view their profile.
Post conditions View profile
e. click profile.
f. click view profile

g. Use Case Ends.
2. Alternative Flow
d. click profile and after that click view profile.
e. Use case ends.
3. Exceptions
3.3.9 Attendance Report (U9)
Author Jilo Bedecho

Purpose For the Admin to view each class attendance report and For staff they
can generate attendance.
Priority High
Preconditions Only the Admin can view the attendance report and staff can generate
the attendance for the class.
Post conditions Show the attendance report
Actors Admin and Staff
e. Click Manage Academic Operations.
g. Click view attendance report.
f. Use Case Ends.
2. Alternative Flow
d. Click Manage Academic Operations and then click view
attendance report.
e. Use case ends.
3. Exceptions
3.3.10 Select Subject Preference Use Case (U10)
Author Chala Borena

Purpose For the Staff to select the subject to its preferences in the course list.
Priority High
Preconditions Only the Staff can perform this task.
Post conditions Successfully Subject is selected
Actors Staff
e. Click subject preferences options.
f. Use Case Ends.
2. Alternative Flow
d. Click subject Preferences option.
e. Use case ends.
3. Exceptions
3.3.11 Video Conference Use Case (U10)

Purpose Enabling the video conference that helps users can contact through it.
Priority High
Preconditions All users must have to login and have the join code
Post conditions Successfully joined the video conference
Actors Admin, Staff, Student,
e. Click Video conference join or create.
f. Use Case Ends.
5. Alternative Flow
d. Click Video conference button.
e. Use case ends.
6. Exceptions
3.3.12 Create Lesson Plans Use Case (U10)
Author Jilo Bedecho

Purpose For the staff to create the lesson plans and make available for teaching
Priority High
Preconditions Only the staff can do this task.
Post conditions Successfully lesson plans is created.
Actors Staff

e. Click create lesson plans.
f. Use Case Ends.
2. Alternative Flow
d. Click create lesson plan.
e. Use case ends.
3. Exceptions
3.3.13 View Library History Use Case (U10)
Author Nafol Abdisa

Purpose For Librarian to check if the book is issued already for student or staff
and to view the history of library book status of users.
Priority High
Preconditions All the user must have to login
Post conditions Go to the dashboard
Actors Librarian, Staff and Student
e. Click view Library History.
f. Use Case Ends.
2. Alternative Flow
d. Click view library history.

e. Use case ends.
3. Exceptions
3.3.14 Manage Book Store Use Case (U10)
Author Chala Borena

Purpose For the Librarian to manage book store.
Priority High
Preconditions Only the Librarian can perform this task.
Post conditions Go to dashboard of the user panel
Actors Librarian
e. Click Library Management.
f. Click Manage book store.
g. Use Case Ends.
2. Alternative Flow
d. Click Library Management.
e. Click manage book store
f. Use case ends.
3. Exceptions
3.3.15 View Mark Report Use Case (U10)

Purpose View the mark report of student and show the status of student
Priority High
Preconditions Only the Admin, Student and Parent can perform this task.
Post conditions Successfully manage accounts
Actors Admin, Student and Parent
e. Click View mark reports
f. Use Case Ends.
2. Alternative Flow
d. Click view mark reports
e. Use case ends.
3. Exceptions
3.3.16 Take Exam Use Case (U10)

Purpose For students take exam which it is posted through Admin
Priority High
Preconditions Only Admin can post the exam and student can take the exam
Post conditions Show the dashboard
Actors Student

e. Click Exam Series.
f. Use Case Ends.
2. Alternative Flow
d. Click the Exam available.
e. Use case ends.
3. Exceptions
3.3.17 View Child Status Use Case (U10)
Author Nafol Abdisa

Purpose It’s the summary report of one’s child status that he/she had
Priority High
Preconditions Parent must have to login and assigned to the his/ her child.
Post conditions Report is generated for the parent
Actors Parent
e. Click show child history.
f. Use Case Ends.
2. Alternative Flow

d. Click show child history.
e. Use case ends.
3. Exceptions
4 Other Non-functional Requirements
4.1 Performance Requirements

Even though our system doesn’t have a wide variety of users, our system will have the capability of
serving them all simultaneously.
Because the system will not have that wide variety of users, the authentication and
authorization process will be fast.
The performance of performing operations should be quick.
The ability of our system in retrieving the schedule should be quick.
The system should be able take minimum time to display researches or any functions asked by
the user.
The system should be able to respond fast enough so as to avoid dead lock and response
collision.
The website should provide a reliable service for multiple users simultaneously
4.2 Safety and Security Requirements
This is a very important aspect of the design and should cover areas of hardware reliability, fall back
procedures, physical security of data and provision for detection of fraud and abuse.
The generated password should be encrypted and stored safely to the database.
The authentication and the authorization mechanism should be secure, so users would see
their page and perform their task with respect to their roles.
The system should be able to backup data in case of any data lose.
The system will have the highest possible security policies in place.
unauthorized people are totally deprived of access to the system.

The system will also be able to resist most of the known security attacks.
For safety mechanism the password is sent to the user email directly.
4.3 Software Quality Attributes
4.3.1 Availability
Because our system is majorly web based it should be accessed by any device with a browser and an
internet connection. Because of this system is changed occasionally (i.e. curriculum changes), it
won’t be unavailable for maintenance related issues. The website should be available for use 24 hours
per day, 365 days per year.
4.3.2 Portability
Because our system is majorly web based it should be accessed by any device with a browser and an
internet connection (i.e. Mobile Phones, Tablets). The website can work in different platforms and
operating system.
 Any user with proper browsers and internet connection can access the Smart School Learning
Platform website.
 The system that we are going to develop works on Windows, Linux, IOS, etc.
 The works independent of the machine, it should work on desktop, phone, etc.
4.3.3 Correctness
The functions of operations should be able to perform the processes by checking all the necessary
data that have been given and report if there is missing data and avoiding some errors.
4.3.4 Maintainability
Because the system will be built using component-based architecture if any problem arises all we
have to do is maintain that single component. Maintainability is a crucial part of the system.
 If there are any bugs captures or if any changes or updates want to be made, the system will
be open for maintenance
 Back up for the database are available.
 Extending the system to add functionality is possible
 The development team will follow best practices for clean code and software modularity in
order to make the system as maintainable as possible.
4.3.5 Accessibility
The system should be installed centrally on one or more servers, and should be accessible via
HTTP or HTTPs using any mobile device and a working internet connection from anywhere
because the servers will allow usability of the system.
4.3.6 Scalability
This system will be designed to accommodate any changes regarding where it is going to be applied
4.3.7 Manageable and Reusable
It is very easy to update the look and feel of the application or for customization and it is expandable,
general and self-descriptive.
Appendix A – Data Dictionary
▪ A Data Dictionary, also called a Data Definition Matrix, provides detailed information
about the business data, such as standard definitions of data elements, their meanings, and
allowable values.
▪ At this time, we haven’t any data dictionary because our database is not built.
Appendix B - Group Log

 We have been meeting each other 2hr per day. When we have been meeting together as a
group we share and compile what all researched alone.

Smart School SRS

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smart School SRS

Uploaded by

Copyright:

Available Formats

Software Requirements Specification for Smart School Learning Platform Page 1

Smart School Learning Platform

Group Name: Scorpio

Jebesa Temesgen 1762/10 jebesatemesgen01@gmail.com

Adviser: Mr. Rajasekhar B.

3.3.17 View Child Status Use Case (U10).................................................................................31

1.1 Document Purpose

1.4 Definitions, Acronyms and Abbreviations

1.5 Document Conventions

1.6 References and Acknowledgments

The SRS template from the department

2.1 Product Overview

Figure 1 Product Overview

2.2 Product Functionality

Login to the system

Check students and staff book issues status

Select subject preferences

Login to the system

Send messages to the school employers

Check the status of their student

2.3 Design and Implementation Constraints

2.4 Assumptions and Dependencies

User Their Role

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

The Software Tools

3.2 Functional Requirements

3.3 Use Case Model

Staff Use Case Model

Librarian Use Case Model

Student Use Case Model

Parent Use Case Model

3.3.1 Login Use Case (U1)

Author Nafol Abdisa

Author Jilo Bedecho

Flow of Events 1. Basic Flow

3.3.3 Manage Academic Operations (U3)

Author Jebesa Temesgen

c. Insert required information (like: username, password)

3.3.4 Manage Notifications (U4)

Author Gadise Alemayehu

3.3.5 Manage Exam Use Case (U5)

Author Jebesa Temesgen

3.3.6 Generate Timetable Use Case (U6)

Author Chala Borena

3.3.7 Send Message (U7)

Author Nafol Abdisa

Actors Admin, Staff, Librarian, Student and Parent

3.3.8 View Profile (U8)

Author Gadise Alemayehu

f. click view profile

3.3.9 Attendance Report (U9)

Author Jilo Bedecho

3.3.10 Select Subject Preference Use Case (U10)

Author Chala Borena

3.3.11 Video Conference Use Case (U10)

Author Jebesa Temesgen

3.3.12 Create Lesson Plans Use Case (U10)

Author Jilo Bedecho

c. Insert required information (like: username, password)

3.3.13 View Library History Use Case (U10)