Srs

ASSOSA UNIVERSITY
COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF COMPUTER SCIENCE
SRS for “Web + Mobile Application COC Information Management System for
BGRS”
A project SRS submitted to the Department of Computer Science of Assosa University in

partial fulfillment of the requirement for the Degree of Bachelor of Science in Computer
Science
Prepared by:
1. Dereje Fenta
2. Lemi Marema
3. Melaku Aragaw
4. Merkew Mekie
5. Muluken Lemecha
Advisers’ Name:
1. Main Advisor Balemlay Gebeyehu
2. Co-Advisor Gebreigziabher Abadi
Nov 24, 2017

Assosa, Ethiopia
Approval Sheet
This is certified that the project entitled on COC Information Management System for BGRS
developed and submitted by:
1. Dereje Fenta
2. Lemi Marema
3. Melaku Aragaw
4. Merkew Mekie
5. Muluken Lemecha
A project SRS submitted to the department of Computer Science of Assosa University in

partial fulfillment of the requirement for the Degree of Bachelor of Science in Computer
Science
Advisor Name Signature Date
1) Balemlay Gebeyehu ___________ ___________
2) Gebreigziabher Abadi ___________ ___________
Approved By:
Examining Board Signature Date
1) ______________________________________ ____________ ___________
2) ______________________________________ ____________ ___________
3) ______________________________________ ____________ ___________
Page | 1
Acknowledgment
Before anything thanks to God for giving strength to complete our SRS without heavy challenge.
Next we would like to thanks our department Instructor for giving their polite advice. Especially
we would like to thanks our advisor Balemlay Gebeyehu and Gebreigziabher Abadi for giving the
hints to do regarding to our SRS detail content and correction.
We will have taken efforts in this project. However, it would not have been possible without the
Kind support and help of many individuals and organizations. We would like to extend our Sincere
thanks to all of them. We are highly indebted to Agency employees for providing necessary
information regarding the project and also for their support in completing the project.
Finally we would like to express our gratitude towards team for their kind co-operation and
Encouragement to help us in completion of this project. Our thanks and appreciations also go to
our colleague in developing the project and people who have willingly helped us out with their
abilities.
Page | 2
Contents
Page
Approval Sheet................................................................................................................................ 1
Acknowledgment ............................................................................................................................ 2
1. Introduction ............................................................................................................................. 4
1.1. Document purpose............................................................................................................ 4
1.2. product scope.................................................................................................................... 5
1.4. Definition Acronyms and Abbreviation ........................................................................... 6
1.5. References ........................................................................................................................ 7
2. Overall description .................................................................................................................. 7
2.1. Products perspective ............................................................................................................ 7
2.2. Product functions ................................................................................................................. 8
2.3. User class and characteristics............................................................................................... 8
2.4. Operating environment ........................................................................................................ 8
2.5. Design and Implementation Constraints .............................................................................. 8
2.6. User documentation ............................................................................................................. 9
2.7. Assumptions and dependency .............................................................................................. 9
3. Specific requirement .............................................................................................................. 10
3.1. External Interface Requirements........................................................................................ 10
3.1.1. User Interfaces ........................................................................................................ 10
3.1.3. Software Interfaces ...................................................................................................... 11
3.1.4. Communication Interfaces ........................................................................................... 11
3.2. System Use Case Modeling............................................................................................ 13
3.2.1. Actors and Use Cases.............................................................................................. 13
3.2.2. Use Case Diagram................................................................................................... 14
3.2.3. System Use Case Documentation ........................................................................... 15
4. Nonfunctional requirements .................................................................................................. 31
4.1. Performance Requirements ............................................................................................ 31
4.2. Safety and Security Requirements ................................................................................. 31
4.3. Software Quality Attributes ........................................................................................... 31
4.3.1. Reliability................................................................................................................ 31
Page | 3
4.3.2. Robustness .............................................................................................................. 31
4.3.3. Availability ............................................................................................................. 31
4.3.4. Maintainability ........................................................................................................ 32
4.3.5. Portability................................................................................................................ 32
Reference ...................................................................................................................................... 33
1. Introduction
1.1. Document purpose
The purpose of this SRS document is to provide a detailed description of the functionalities of the
COC information management system. This document will cover each of the system’s intended
Page | 4
features, as well as offer a preliminary accident of the software application’s User Interface. The
document will also cover hardware, software, and various other technical dependencies.
1.2. product scope
The COCIMS is helpful for the user to minimize manual labor and time consuming at the time of
register for the exam and taking exam. In addition to this the software provide easy and manageable
working environment for the agency workers. The application should be used to all end user by
mobile phone, desk top and PC.
The agency workers can provide to the candidates their daily information using this application.
This information will act as the bases for the search results displayed to the user. An administrator
also uses this software in order to administer the system and keep the information accurate and
secure.
1.3. Intended Audience and Document Overview
This SRS document is read by our self (developers), project examiners, the project adviser, agency
staff member, invited guests, and testers of the system. Our SRS document is contain four basic
sections.
Developer
The developer who wants to read, changes, modifies or adds new requirements into the existing
program must firstly consult this document and update the requirements with appropriate manner
so as to not destroy the actual meaning of them and pass the information correctly to the next
phases of the development process.
User
The user of this program reviews the diagrams and the specifications presented in this document
and determines if the software has all the suitable requirements and if the software developer has
implemented all of them.
Tester
Page | 5
The tester needs this document to validate that the initial requirements of this Programs actually
correspond to the executable program correctly.
This document contains all part of the SRS in different phase.
The introduction section provide an overview of the entire SRS and basically focuses on
identifying what is going to be achieved on our proposed system.
The second section is overall description of the product and any other issues related to our project.
This section describe the context and origin of the product being specified in this SRS and the
dependency our project with the current systems and its implementation assumptions and
constraints. This section also basically states relationship of the product with other products
(whether this product is a follow-on member of a product family, a replacement for existing
systems, or a new, self-contained product) as well as simple diagram that shows the interaction of
system components. Then the functionality of the system is roughly describe. This section also
includes the design and implementation constraints which can be raised as major limitations of the
system.
The third Section states about specifying software requirements in sufficient detail to enable
designers to design a system to satisfy those requirements and testers to verify requirements. State
requirements that are externally perceivable by users, operators, or externally connected systems.
Generally it describes all about functionalities and external interface requirements of the system.
It begin with the detail description of interface requirements and proceeds to hardware
requirements with software requirements. After that the functional requirements of the system that
are expressed as services, tasks and functions the system is required to perform are listed. At the
end of this section use case model considered to show the interaction of the system with the end
user.
The last Section of this document is about non-functional requirement of the system in this section
the major task is Specify any additional quality characteristics for the product that will be important
to either the customers or the developers. The nonfunctional requirement includes performance,
security and safety requirements. Other task to be performed under this section is Software quality
attributes of the system.
1.4. Definition Acronyms and Abbreviation

Page | 6
BGRS: Bensahngul Gumuz Regional State
COC: Center of Competence
COCIMS: Center of Competence Information Management System
SRS: Software Requirement Specification
UML: Unified modeling language
1.5. References
2. Overall description
2.1. Products perspective
Our project is a new. Center of Competence Information Management System is a new, self-
contained product intended for use on the computer and Android platform. This means that no
system release before the time being. Currently we begin to develop this system to solve the
problem of existing manual system starting from the scratch. In our project some stockholders who
Page | 7
interact system are list below in short the stockholders are actors of the system. Administrator,
candidates, exam preparation section and exam evaluation section. We depicted the whole system
architecture roughly by the following diagram.
2.2. Product functions
 Login  Online register
 Create  Prepare exam
 Delete  Set exam time
 Update  Evaluate exam
 Send comment  Take exam
 View comment  View result
 View report  Payment
 Generate report
 post notice
2.3. User class and characteristics
The typical users of this system, such as candidates, who want to use COCIMS for register COC
exam, online payment and view the results. The other users are exam preparation section for the
purpose of preparing and evaluate the COC exam. The other user of the system is Administrator to
manage all the system.
2.4. Operating environment
COCIMS is plan to become platform independent. This means it can run in different operating
system like windows, Linux, MAC and android operating system. To make the system platform
independent we propose to use bootstrap content management system that contains HTML, CSS
and JS inside it. Users use the operating system listed above and browsers like Google Chrome,
Internet explorer, Mozilla Firefox, UC, Baidu Spark and others are used for run inside local area
network.
2.5. Design and Implementation Constraints
Page | 8
The project is develop and submitted to the department of Computer Science in partial fulfillment
of the requirement for the Degree of Bachelor of Science in Computer Science. In a since there is
no more constraint that given to us at the time of design and implementation like business area
system development. But there is some programing language constraint which given by our
department. Initially our project tittle is proposed to develop web based system totally. Currently
the system modified to Web Based +Mobile application.
2.6. User documentation
The product will include a user manual. The user manual will include product overview, complete
configuration of the required software and hardware, technical details and contact information
which will include email address. A user manual explaining what the functionality and usage of
the visualization software will be required.
Additionally, the team developing the software would potentially need to be available in case of
questions or problems with the software once it starts being used by other users/administrators.
Our source code will be heavily documented. This will make it easier for other people to
understand and continue development on our product if needed. We also support help center
button in the software that will support the end user of the system.
2.7. Assumptions and dependency
The first assumption about the product depend on the internet connection. The product will always
be used on mobile phones that have enough performance mostly in smart phone and desktop with
in the local area network. If the phone and PC or desktop does not have enough hardware resources
and available broadband Wi-Fi or data connection the system does not perform any task. In this
case our assumption is there will be enough internet connection for us to develop the software and
in Benishangul Gumuz Regional State COC management and enterprise agency in order to use the
software product to perform their activity properly. If the lack of connection occur, for the
developer it is difficult to develop the target software in given time and difficult to use properly
the system for end user.
Assumptions and dependencies: -
Page | 9
 It is assumed that the user has basic knowledge of the system (i.e. he/she is not a first time
user) as any action by the user is considered valid during an examination.
 It is assumed that the data entered by the user while registering is true.
 It is assumed that the candidate does not cheat during the exam as there are no supervisors
around to monitor.
3. Specific requirement
3.1. External Interface Requirements
3.1.1. User Interfaces
Page | 10
The user interface of COCIMS is very easily understandable and flexible, in a since no need finding
professional experts to work on the system. The system user interface specifically design with the
consideration of the end user ability to use the system giving them convenience while they use the
system for long period of time. We consider many things about the interface of the system like
simple operation process and color visible background. The home screen offers a menu with a list
of functions that the end users perform. The user can select one of the options on the menu, and is
taken to the respective screen. Every screen displays the menu on the bottom. The user can click
on any one of the options and is taken to the screen of their choice.
3.1.2. Hardware interfaces
The system works on any computer and smart phone to generate online functional operation with
no device type selection of computer. The Android platform and computer provides abstractions
for all network communication interfaces as well as hardware parts of the device.
3.1.3. Software Interfaces
The mobile web based software application communicates with the server application and database
in order to get COC related information about where the user is located and the visual
representation of it, and with the database in order to get the information about the COC. The
communication between the database and the server consists of operation concerning both reading
and modifying the data.
3.1.4. Communication Interfaces
The subsystem of project is dependent each other. Therefore communication between the different
parts of the system is important. However, in what way the communication is achieved is not
important for the system and is therefore handled by the underlying operating systems for both the
mobile application and computer. The intended product to exploit existing Web service
technologies to leverage component would be performed through message passing over the IP
network. From technical point of view TCP/IP will be used as the transport protocol, where content
delivery network server establishes a TCP connection to the network elements using a well-known
port number. Information will be sent using TCP/IP and the HTTP protocol.
Page | 11
3.2. Functional Requirements
In this section includes the requirements that specify all the fundamental actions of the software
system. Our proposed system has the following main functionalities or functional requirements.
Login The system should support authentication for the actor of the system and
enable them to operate with the system.
The user should have user account and password to loin to the system.
In this software all actors Administrator, EPS and Candidate give privilege
to login in to the system.
Create Account The system should be enabling the administrator to create user account.
The page of create account should be contain text field to fill user
information and create account button to submit the information to
database. The functional requirement is majorly use by administrator.
Delete Account: The administrator use functional requirement to reject the user. The
functional requirement shall be used when the user cancel from privilege.
Update Account The system should be used when some incorrect information is inserted
regard to user profile.
The system shall use by administrator to update user account information.
Send Comment The system shall enable the candidate to send comment to EPS.
View Comment The system shall enable the Exam preparation section to read the comment
given from the Candidates.
View Report The system should allow to view the result the report generated by the
administrator
Generate Report The system should be enable the administrator to generate report to give
announcement for users using the system especially for EPS. The system
should be given authority for the user to view the generated report.
Register The system should enable candidate to register for COC online by using the
system. The page of registering candidate should be contain text field to fill
Page | 12
candidate’s information and register button to submit the information to
database. The functional requirement is majorly use by candidate.
Prepare Exam
Evaluate Exam
Take Exam
View Result
Payment
3.2. System Use Case Modeling
A system use case model is composed of use case diagram associations.
Use case diagram: Use Case represents interaction between a user (human or machine) and
the system.
Actor identification: In the use cases an actor interact with the system. Actors in this system
are Administrator, Candidate and Exam preparation sections
Use case identification: The most important and basic use cases of this system are
Manage user account (add, delete, update), Take Exam, View Exam Results, Evaluate Exam,
Preparation Exam, View Report, Generate Report, Send Comment and View Comment.
3.2.1. Actors and Use Cases
Table 3.1 actor and use case
Actor Use Case
Administrator Login, Create Account, Update account, Delete Account, Post Notice and
Generate Report
Page | 13
Login, register, Payment, Take exam, view result, view Report and Send
Candidate
comment
EPS Login, Prepare the Exam, Evaluate the Exam and View Comment
3.2.2. Use Case Diagram
Page | 14
Figure 3.1 use case diagram
3.2.3. System Use Case Documentation

The System use case documentation is a structured, action and system response in the language
that the application domain and users to describe the system use case in complete meaning full
way.
Page | 15
Table 3.2 Action and system response use case documentation for Login button
Use case name Login
Use case id UC#1

Actors Administrator, Candidate, EPS
Precondition The user must be registered as user or have an account.

Post condition The system allow for login to required page
Description Describe how user login to the system by using their
user name and password.
Priority High
Basic Flow of Events
Actors Action System Response
1, The user opens the application. 2, Login form is displayed

3, User selects his privilege
4, The user enters his/her username 6, The system validates the user inserted information.
and password
5, The user clicks login button 7, The system logs in the system
8, The use case ends.
Alternatives flow of event
E9. The User Name or Password is incorrect. Please

try again, message is displayed.
E10. Use Case ends
Exceptional flow of Events
E7, Error! Can’t Open Database. Please Contact Manager

message is displayed.
Page | 16
Table 3.3 actions and system response use case documentation for update user account
Use case Update account

Use case id UC#2
Actors Administrator
Precondition The user must be having an account first and admin should
be known the modifying user information to update.
Post condition The user account successfully updated by admin.
Description Describe how administrator modifies the user account.
Priority Medium
1, The administrator click 2, modify user account form is displayed

modify user account button.
3, fill all necessary information
4, then click save button. 5, The system validates the inserted information.
7, The use case ends. 6, The system update and stored the user account.
E8. The information you enter is incorrect format. Please try

again, message is displayed.
E9. Use Case ends
E10, Error! Can’t information to Database. Please Contact

Manager message is displayed.
Page | 17
Table 3.4 Action and system response use case documentation for create account
Use case name Create Account
Use case ID UC#3

Precondition The administrator identify who access the system.

Post condition The user account successfully created by administrator and
user use the account properly.
Description Describe how administrator create the user account.
Priority High
1, The administrator click create user 2, create user account form is displayed
account button.
3, Then fill all necessary information
4, then click save button. 5, The system validates the inserted information.
6, The system create and stored the user account in
7, The use case ends. database.
E8. The information you enter is incorrect formated.

Please try again, message is displayed.
E9. Use Case ends
E10, Error! Can’t store in Database. Please Contact

Page | 18
Table 3.5 Action and system response use case documentation for evaluate exam.
Use Case name Evaluate Exam

Use case id UC#4
Actors EPS
Precondition To evaluate exam student should take the exam
Post condition Exam preparation section evaluates and know candidate
exam result.
Description Describe how Exam preparation section evaluates the
exam.
Priority High
Actors action System Response
1, EPS click Evaluate Exam 2, Candidate ID and evaluate exam button is displayed.
button.
4, the system start check the select letter and exact
3, The EPS click the start evaluate answer to know result of candidate.
button.
E6, No student take exam
E7, Use Case ends
E9, Unable to check the exam. Please Contact Manager

Page | 19
Table 3.6 Action and system response use case documentation for View report.
Use Case name View report.

Use case id UC#5
Actors Candidate
Precondition EPS should be generate new report and release to the
system
Post condition View the generated report
Description Describes how the candidate view report
Priority Medium
1, Candidate open the system and 2, list of new report is displayed
click view report button
3, Candidate click report link. 4, the report hold by the link is expanding within the
5, Candidates view concerned report. screen.
E7. No released report

E8. Use Case ends
E9, Error! Unable to display the report please try it
later message is displayed.
Page | 20
Table 3.7 Action and system response use case documentation for Send comment.
Use Case name Send comment.

Use case ID UC#6
Actors Candidate
Precondition All require fields of form are correctly fill by the candidate
Post condition The EES successfully send comment.

Description Describes how the candidate sends comment to the exam
preparation section.
Priority High
1, candidate click send
2, System Displays comment writing area successfully.
comment button.
3, The candidate writes 5, system validates the text format of written comment.
comment.
4, click send comment.
E7. The information you enter is incorrect formatted. Please try

E8. Use Case ends
Exception flow of event
E9, Error! Can’t store in Database. Please Contact Manager
Page | 21
Table 3.8 Action and system response use case documentation for View comment.
Use Case name View comment

Use case id UC#7
Actors EPS.
Precondition The candidate must write comment
Post condition EPS view comment accept take correction
Description Describes how EPS view comment.
Priority Medium
1, EPS Open the system and click 2, System Display list of comment link.
comment button.
3, EES Click any link of comment 4, System process and open comment
and view it
5, Use case ends.
E6. The information you enter is incorrect. Please try

E7. Use Case ends
Exception flow of event
E8, Error! Can’t store in Database. Please Contact

Page | 22
Table 3.9 Narrative style use case documentation for Generate report.
Use case name Generate report

Use case identification UC#8
Actor(s) Administrator
Precondition List work must view from the system how many things are done.
Post condition Generate needed reports
Describe Describe how to generate report
Priority Medium
1. administrator open application
Basic flow of event
2. press generate report button
3. generate report form display
4.fill the required forms
5. press submit button
6. check the validation of the system
7. Generate report successfully.
8. use case ends
Page | 23
Table 3.10 Action and system response style use case documentation for View result
Use Case name View result

Use case id UC#9
Actors Candidate
Precondition Candidate must be take exam and evaluated by EPS
Post condition Candidate know their exam result
Description Describes how candidate view their exam result
Priority Medium
1, Candidate click view result

button.
2, system displayed list of evaluated courses.
3, candidate click link of each course
step by step and see result.
4, use case end.
5, sorry no evaluated course try later message is

displayed.
6, use case end.
7, unable to display the result, contact the system

manager message is displayed.
Page | 24
Table 3.11 Action and system response style use case documentation for Register
Use Case name Register

Use case id UC#10
Actors Candidate
Precondition Should be login to the system first
Post condition The candidates successfully register to take exam
Description Describe how candidate register to the exam using the
system.
Priority High
1, candidate click register button.

2, System displayed the register form
3, candidate fill the form and
click register button. 4, The system validates the inserted information.
6, Use case end 5, The system stored the information in database.
E7. The information you enter is incorrect. Please try

E8. Use Case ends
9, Sorry unable to register to the data base, Please try

again message is displayed.
Page | 25
Table 3.12 Action and system response style use case documentation for Payment
Use Case name Payment

Use case id UC#11
Actors Candidate
Precondition Candidate should have balance in account more than pay
cash.
Post condition Candidate pays money to take the exam successfully.
Description Describe how candidate pay money to take the exam using
the system
Priority Medium
1, Actor click register button. 2, The system displayed payment form.
3, the user fill the form with 5, The system validates the inserted information.
appropriate information
6, The systems minus money from candidate accounts
4, Click the pay button. and add to the institution account.
7, Sorry you have no sufficient balance to pay, try to add

money to your account.
8, the use case end.
9, Sorry unable to register to the data base, Please try again

Page | 26
Table 3.13 Action and system response style use case documentation for Take exam
Use Case name Take exam

Use case id UC#12
Actors Candidate
Precondition The candidate should have account, register, pay cash
and the EPS prepare exam.
Post condition Candidates fill the answer and submit the answer to
EPS successfully.
Description Describes how candidates take exam using the system.
Priority High
1, candidate click take exam button 2, the system display exam question.
3, The candidate chose the letter 4, system store the selected letter to the data base.
click the select box near to the letter
5, Use case end.
6, No question is released now try later message is

displayed.
Sorry unable to open this page please contact with the

system admin message is displayed
Page | 27
Table 3.14 Action and system response style use case documentation for Delete Account
Use Case name Delete Account

Use case id UC#13
Precondition Created account must be existing to deleted.
Post condition Administrator delete account successfully
Description Describes how administrator deletes user account from

the database.
Priority Low
1, admin click delete account button 2, the system display list of users
3, the Admin click delete button by 4, the system remove the account from list of user in the
select unwanted account. data base
5, use case ends.
6, sorry no account to be delete , create account first

message is displayed
7, use case ends
8, unable to delete the user account , please try it later
Page | 28
Table 3.15 Action and system response style use case documentation for Post Notice
Use Case name Post Notice

Use case id UC#14
Actors EPS
Precondition New thing should be occur that need notice
Post condition EPS successfully posted by the admin candidate read it.
Description Describes how exam preparation section posts the
notice using the system.
Priority Medium
1, EPS click post button on the 2,the system display text area to write the notice
system
4, the system validate wrote text format.
3, EPS write the notice on the text area
5, The system posts the notice to the intended page.
and click post button.
6, use case ends
7, the input format is not formal please check the text

format again message is displayed.
8, use case ends.
9, Sorry the system is unable to post the notice now please

communicate with the system admin message is displayed.
Page | 29
Table 3.16 Action and system response style use case documentation for Prepare Exam
Use Case name Prepare Exam

Use case id UC#15
Actors EPS
Precondition The EPS open the system and login

Post condition The EPS prepare the COC exam successfully.
Description Describes how EPS prepare COC exam for the candidate.
Priority High
1, EPS prepare exam notice 2, the system display text area to write the question.
button on the system
4, the system validate wrote text format.
3, EPS write the notice on the
5, The system store exam to the database.
text area and click post button.
6, use case ends

7, the question should be containing only multiple choice try
to check it again message is displayed.
8, use case ends.
9, Sorry the system is unable to create question, contact the

administrator message is displayed.
Page | 30
4. Nonfunctional requirements
4.1. Performance Requirements
System accomplishes tasks with in good response time and produce output within a good
throughput time. Checking the fact that the system must perform as what every user expects. So
in every action-response of the system, there are no immediate delays. Unless there are, hardware
and Internet connection constraints, the system can handle multiple users request at the same time
and responsive to user’s requests.
4.2. Safety and Security Requirements
This system uses different security systems to protect its data. Among this Password and user
name. The system users are allowed to perform activities or make a modification to the data if and
only if they are authorized which will be checked by their username, password, and account type.
In other word unauthorized user cannot access the system.
4.3. Software Quality Attributes
4.3.1. Reliability
The system is always reliable. The new system will operate for long period of time without failure.
If a connection failure occurs while submitting a request for consultation, the system must save
the data and retry sending when connection is reestablished.
4.3.2. Robustness
The new system will show errors message when errors occur. This means the system should be
designed in such a way that users cannot proceed having entered invalid input or data in all cases
of interacting with the system.
4.3.3. Availability
Our system should be available 24 hours per a week unless there is no internet connection or it is
under some failure.
Page | 31
4.3.4. Maintainability
The system is designed with Object oriented approach and different modules. Our system can
maintain easily when the problem or failure occur. The system does not need higher expert to
troubleshoot failure of it. Generally any developer can easily maintain and modify without
affecting other parts.
4.3.5. Portability
The system can be executed in different platforms without any restriction . Candidate can access the
system through any mobile phone with android operation system. COC professional and system
administrator can access the system through web browsers with all platforms.
Page | 32
Reference
Page | 33

Srs

Uploaded by

Document Information

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

Srs

Uploaded by

Copyright:

Available Formats

ASSOSA UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

A project SRS submitted to the Department of Computer Science of Assosa University in

Nov 24, 2017

A project SRS submitted to the department of Computer Science of Assosa University in

1.2. product scope

1.3. Intended Audience and Document Overview

1.4. Definition Acronyms and Abbreviation

COC: Center of Competence

COCIMS: Center of Competence Information Management System

SRS: Software Requirement Specification

UML: Unified modeling language

2.3. User class and characteristics

2.4. Operating environment

2.5. Design and Implementation Constraints

2.6. User documentation

2.7. Assumptions and dependency

Assumptions and dependencies: -

3.1.2. Hardware interfaces

3.1.3. Software Interfaces

3.1.4. Communication Interfaces

3.2. System Use Case Modeling

A system use case model is composed of use case diagram associations.

3.2.1. Actors and Use Cases

Table 3.1 actor and use case

Actor Use Case

3.2.2. Use Case Diagram

3.2.3. System Use Case Documentation

Use case name Login

Use case id UC#1

Precondition The user must be registered as user or have an account.

Actors Action System Response

1, The user opens the application. 2, Login form is displayed

E9. The User Name or Password is incorrect. Please

E7, Error! Can’t Open Database. Please Contact Manager

Use case Update account

Basic Flow of Events

Actors Action System Response

1, The administrator click 2, modify user account form is displayed

Alternatives flow of event

E8. The information you enter is incorrect format. Please try

Exceptional flow of Events

E10, Error! Can’t information to Database. Please Contact

Use case name Create Account

Use case ID UC#3

Precondition The administrator identify who access the system.

Basic Flow of Events

Actors Action System Response

Alternatives flow of event

E8. The information you enter is incorrect formated.

Exceptional flow of Events

E10, Error! Can’t store in Database. Please Contact

Use Case name Evaluate Exam

Actors action System Response

5, The use case ends.

Alternatives flow of event

E6, No student take exam

E7, Use Case ends

Exceptional flow of Events

E9, Unable to check the exam. Please Contact Manager

Use Case name View report.

E7. No released report

Use Case name Send comment.

Post condition The EES successfully send comment.