FLUTE

ADDIS ABABA INSTITUTE OF
TECHNOLOGY
CENTER OF INFORMATION TECHNOLOGY AND

SCIENTIFIC COMPUTING
DEPARTMENT OF INFORMATION TECHNOLOGY
FLUTE
Team Members
Name ID
1.Abel Kefale ----------------ATR/2462/06
2.Tekleab Hadush -----------ATR/2578/06
3.Yohans Teklewold --------ATR/3032/06
4.Zelalem Molla -------------ATR/4756/06
Advisor: Mr. Eyob Wondimkun
February 12, 2017

Addis Ababa Institute of Technology
Information Technology and Scientific Computing
Flute
This Project documentation submitted in partial fulfillment of the requirements for the Degree of
Bachelor of Science in Information Technology.
Project Advised by:
Mr. Eyob Wondimkun
Name and signature of Members of the examining board:
Name Title Signature Date
1. __________________ Advisor _____________ _____________
2. __________________ Chairperson _____________ _____________
3. __________________ Examiner _____________ _____________
4. __________________ Examiner _____________ _____________
5. __________________ Examiner _____________ _____________
February 2017
i
Declaration of Originality
We declare that this project is our original work and has not been presented for a degree in any
other university.
Name Signature Date
1. Abel Kefale __________________ __________________
2. Tekleab Hadush __________________ __________________
3. Yohans Teklewold __________________ __________________
4. Zelalem Molla __________________ __________________
This project documentation has been submitted for examination with my approval as university
advisor:
Advisor Name _________________________
February 2017
ii
ACKNOWLEDGEMENT
First of all, we would like to thank our almighty God, who gives us love, patience, healthy,
wisdom and ability to walk through all the problems and obstacles during the period of our
study.
Our heartfelt appreciation for our advisor Instructor Eyob Wondimkun for his indefatigable
guidance, valuable suggestion, moral support, and constant encouragement in the documentation
part.
Finally but not the least, we would like express our love, thanks, appreciation, and respect for the
ongoing support of our parents and family members, for their continues encouragement and
financial support. And also we would like to thank the teaching staffs of ITSC who have
contributed wholly to the success of this documentation.
iii
ABSTRACT
Flute is a web based system planned to work on the AAiT’s intranet network. The goal of the
project is to solve the existing problem in our campus such as using manual system to announce
the community different activities held on the institute, lack of information and file sharing
mechanism, there is a gap between Instructors and students, staff offices and students. The
designed system will solve such problem by changing a manual system to automated system
and will build an effective information management system to the institute by integrating it on
the campus Intranet network.
The system includes three main modules: The event management module, Discussion module
and file sharing module. using this site every institute’s announcement, conference schedules,
class schedules will be announced, the community can discuss on different issues and also the
community can upload and download educational pdf material which then store on the site.
The system provides question and answer discussion forum for students based on their
department and also it gives a chance to a student to ask any information and question to any
staff office and access it. On the other way the system provides a social media capabilities like
commenting on files and like the information posted on the site.
The community member will be divided into staff member and student and each member will
have its own personal profile. Based on department and section groups will be created to
exchange information.
This application will be developed using PHP programming language for back end or for server
side functionalities, JavaScript, AJAX, HTML, CSS and Bootstrap for front end development
and APACHE and MYSQL for the database.
iv
Table of Contents
List of Figures.............................................................................................................................viii
List of Tables.................................................................................................................................ix
ACRONYMS.................................................................................................................................xi
Chapter 1: INTRODUCTION......................................................................................................1
1.1 Background..........................................................................................................................1
1.2 The Existing System............................................................................................................2
1.3 Statement of the Problem....................................................................................................3
1.4 Objective of the Project.......................................................................................................6
1.4.1 General Objective....................................................................................................6
1.4.2 Specific Objective.....................................................................................................6
1.6.1 Economic Feasibility.....................................................................................................8
1.6.2 Technical Feasibility.....................................................................................................9
1.6.3 Schedule Feasibility......................................................................................................9
1.7 Scope.....................................................................................................................................9
1.8 Methodology.......................................................................................................................10
1.9 Project Management plan.................................................................................................11
1.9.1. Time Management plan............................................................................................11
1.9.2 Quality Management Plan.........................................................................................11
1.9.3. Communication Management Plan..........................................................................11
Chapter 2: Requirement Analysis..............................................................................................13
2.1 Introduction........................................................................................................................13
2.2 Scope...................................................................................................................................13
2.3 General Description...........................................................................................................15
2.4 Product Perspective...........................................................................................................15
v
2.6 User Characteristics..........................................................................................................17
2.7 General Constraints...........................................................................................................17
2.8 Assumptions and Dependencies........................................................................................17
2.9 External Interface Requirements.....................................................................................17
2.9.1 User Interfaces............................................................................................................17
2.9.2 Hardware Interfaces...................................................................................................23
2.9.3 Software Interfaces.....................................................................................................24
2.9.4 Communications Interfaces.......................................................................................24
2.10 Functional Requirements................................................................................................25
2.11 Use Case Models..............................................................................................................27
2.11.1 Actors.........................................................................................................................27
2.11.2 Use Cases.......................................................................................................................27
2.11.3.3 Instructor and Office Admin Use Case Diagram....................................................30
2.11.4.1 UC #1: Register/Create account...............................................................................30
2.11.4.2 UC #2: Update profile...............................................................................................31
2.11.4.3 UC #3: Login..............................................................................................................32
2.11.4.5 UC #5: Upload file.....................................................................................................33
2.11.4.6 UC #6: Download file.................................................................................................33
2.11.4.7 UC #7: Post announcement.......................................................................................34
2.11.4.8 UC #8: View announcement.....................................................................................34
2.11.4.9 UC #9: Post ideas in the community........................................................................35
2.11.4.11 UC #11: Add member to the group........................................................................36
2.11.4.12 UC #12: Remove member from the group............................................................36
2.11.4.13 UC #13: Ask questions to the group.......................................................................37
2.11.4.14 UC #14: Answer question in the group..................................................................37
vi
2.11.4.15 UC #15: Give comment...........................................................................................38
2.11.4.16 UC #16: Remove a comment...................................................................................38
2.11.4.17 UC #17: Like posts...................................................................................................39
2.11.4.18 UC #18: Chat............................................................................................................39
2.11.4.19 UC #19: View post...................................................................................................39
2.11.4.20 UC #20: Describe services Provided......................................................................40
2.11.4.21 UC #21: Remove users.............................................................................................40
2.11.4.22 UC #22: Post Class schedule...................................................................................41
2.12 Non-Functional Requirements.......................................................................................42
2.12.1 Performance..............................................................................................................42
2.12.2 Reliability...................................................................................................................43
2.12.3 Availability................................................................................................................43
2.12.4 Security......................................................................................................................43
2.12.5 Maintainability..........................................................................................................43
2.12.6 Portability..................................................................................................................43
2.13 Inverse Requirements......................................................................................................44
2.14 Design Constraints...........................................................................................................44
2.16 Other Requirements........................................................................................................45
2.17 Change Management Process.........................................................................................46
Chapter 3: SYSTEM DESIGN...................................................................................................47
3.2 Development Methods & Contingencies..........................................................................48
3.3 System Architecture..........................................................................................................50
3.3.1 Subsystem decomposition..........................................................................................50
3.3.1.3 Hardware/software mapping..................................................................................55
3.4 Object Model......................................................................................................................56
vii
3.4.1 Class Diagram.............................................................................................................56
3.4.2 Sequence Diagram......................................................................................................58
3.2 Sequence Diagram...............................................................................................................58
4. Detailed Design.........................................................................................................................61
Chapter 4: CONCLUSION AND RECOMMENDATION.....................................................70
6.1 Conclusion......................................................................................................................70
6.2 Recommendation...............................................................................................................70
BIBLIOGRAPHY........................................................................................................................72
APPENDIX...................................................................................................................................73
List of Figures
Figure 1: Sign in page……………………………………………….………….………….…….18

Figure 2: Home Page……………………………………………….………….………….……..19
Figure 3: A page for admins to manage members……………………………………………….20
Figure 4: Users Discussion Page………………………………………………………………...21
Figure 5: File sharing Page……………………………………………….………….…………..22
Figure 6: Office administrator page……………………………………………………………...23
Figure 7: Student use case diagram……………………………………………………………...28
Figure 8: Admin use case diagram……………………………………………………………....29
Figure 9: Instructor and Office admin use case diagram………………………………………...30
Figure 1.1 Context-Diagram…..…………………………………….………….………….…….48

Figure 2.1 Sign in Activity diagram ……………………………….………….………….……..50
Figure 2.2 Admin activity diagram…..…………………………………….………….…………51
Figure 2.3 View announcement and post idea activity diagram..………….………….…………52
Figure 2.4 Upload/Download files activity diagram...…….…….……….………….…………..54
Figure 2.5 Component Diagram of FLUTe.……………………………….………….…………55
Figure 2.6 Deployment diagram………………………………….………….………….……….56
viii
Figure 3.1 Class diagram for Model……………………………...….………….………….……58
Figure 3.3 Login Sequence Diagram.………………………………….………….………….….59
Figure 3.4 Logout Sequence Diagram..……………………………….………….………….…..60
Figure 3.5 Register Sequence Diagram..……………………………….………….………….…61
Figure 3.6 Admin Sequence Diagram.. .……………………………….………….………….…62
List of Tables
Table 1: Software Interfaces…………………………………………………………. 24
Table 2: Logical Database Requirements……………………….……………………. 45
Table 4.1: Account class……………………………………………………………………… 63

Table 4.2: Attributes description for Account class …………………………………………. .63
Table 4.3: Operation description for Mobile Client class…………………………………….. 63
Table 4.4: User class…………………………………………………………………………... 64
Table 4.5: Attributes description for user……………………………………………………… 64
Table 4.6: Update Profile………………………………………………………………………. 64
Table 4.7: Attributes description for Update Profile…………………………………………… 65
Table 4.8: student class…………………………………………………………………………. 65
Table 4.9: Attributes description for Student Class……………………………………………... 65
Table 4.10: Attributes description for Student Class………………………………………….… 21
Table 4.11: Adminstrator class…………………………………………………………………... 21
Table 4.12: Attributes description for Adminstrator class……………………………………….. 22
Table 4.13: Operation description for Adminstrator class……………………………………….. 22
Table 4.14: Instructor class………………………………………………………………………. 68
Table 4.15: Attributes description for Instructor class…………………………………………… 69
Table 4.16: Operation description for Instructor class…………………………………………… 69
ix
Table 4.17: chat class………………………………………..………………………………………. 70
Table 4.18: Attributes description for Chat class………………………………………..…………... 70
Table 4.19: Operation description for Chat class……………………………………….…………… 71
x
ACRONYMS
AAU --------------------- Addis Ababa University.
AAiT -------------------- Addis Ababa institute of Technology.
Admin ----------------------- Administrator.
AJAX ------------------------ Asynchronous JavaScript and XML.
CSS ------------------------ Cascading Style Sheet.
ECTS ---------------------- European Credit Transfer and Accumulation System.
FDD ----------------------- Feature Driven Development.
FLUTE -------------------- Facebook, LinkedIn, YouTube and twitter for education.
FR ----------------------- Functional Requirement.
FTP ----------------------- File Transfer Protocol.
HTML ------------------------ Hyper Text Markup Language.
IE ----------------------- Internet Explorer.
ITSC --------------------- Center of Information Technology and Scientific Computing.
LAN ------------------------ Local Area Network.
MIT OCW -------------------- Massachusetts institute of technology open courseware.
PHP ------------------------ Hyper Text Pre Processor.
24/7 ----------------------- 24 hours a day and 7 days of a week availability.
SRS ----------------------- Software Requirements Specification.
S/HE ----------------------- She or he.
SDS ---------------------- Software Design Specification.
UML ---------------------- Unified Modeling Language.
xi
UC ----------------------- Use Case.
URL ---------------------- Uniform Resource Locator.
xii
Chapter 1: INTRODUCTION
1.1 Background
This project is one of 2016/17 Final academic project for the graduate class students with B.sc in
information technology form the center of information technology and scientific computing at
AAiT.
Being social animal, we humans have a great desire of living harmoniously, own rules for the
way we should behave as a member of the community. tracing 4/5 centuries back such style as a
result of advancement in technology and industrial revolution were becoming degraded with
differences in working class divisions. Indeed, it was until Tim-Berners Lee invented the web,
which lay the foundation for global connection and access to information.
It is with the web, social medias began to build virtual community and integration among their
members. Facebook, Instagram, link din, YouTube, twitter, online training libraries and some
other Dating sites designed with an intention of being a global community shall not be restricted
with borders.
Here at AAIT we already got LAN network with an always on local servers. The campus
community from securities through college deans usually uses digital appliances like
smartphones, tablets, laptop and desktop computer on their daily basis, which in fact will enable
them access to the LAN of the campus easily and might get informative of what is going on
through internet. The Availability of such appliances and social medias acceptance with in the
community enables the ease of implementation to the project.
As a team we get enthusiastic to bring the campus’s manual systems on hand through a local
LAN. Instructors can create a group/network of his ongoing course and connect with his
students, announce assessments and updates with no need of contacting with class
representatives. post recommendations, share resources, and be able to help them with their
doubts out of class through question and answers. Registrars stuff’s and admins shall use this site
for announcing news, updates upcoming events, public lectures/invited guests and new
clients/customers. The community may share the resources they have with others publically.
1
Implementing this project will cost nothing other than the available LAN infrastructures and
handy devices for accessing the network which in fact is what we almost all have already owned.
The services shall cover only for AAIT as of currently but it of course is scalable and will
support all AAU campuses and research institutions as far as the campuses can connect to the
network.
This project is an extension of AAIT intranet/intranet.aait.edu.et, science faculty MSc download,

ITSC: course repository, AAIT module which are too limited provides with static content only.
We are about to develop this concept to a dynamic and multi user access with the addition of
social medias for adding, commenting and sharing/tweeting ideas, connecting with their peers
and instructors and got updates type better system.
We believe this project could be advantageous for an upcoming technology like E-learning file
sharing, streaming media like video conferencing and online collaboration with other campuses,
for independently organized events and meetings. Support for integrating AAU with all other
universities and high schools throughout the country in behalf of knowledge sharing. To the
future It shall support educational social media and bring free education to all over the country
like MIT OCW.
1.2 The Existing System

Based on the current witnesses the campus is handling every activity traditionally with paper
works and manually with employee’s labor. Systems available to provide this services are
intranet.aait.edu.et. 10.5.56.5, AAiT module science faculty misc. downloads. Those systems
merely allow downloading for users in which files are only shared by the admins. Which lacks
interactivity, they support access only feature and that in fact won’t appeal users experience, you
only click then it brings you an ftp server, done, they have nothing else to do. In the current
systems the user’s functionality is limited only to downloading files and admins are uploading
files.
1.2.1 List of problems in existing system are: -
 Lack of communication platform supported with technology between

users/students and admins/instructors out of class: - in the current existing
2
system there is no system developed to enable communication between users
and the admin
 Lack of way for asking help and clarify doubts from their instructors through
the advantage of network: - existing system doesn’t have a way to enable
students/users asking for doubts they face while being remotely shouldn’t
pose restriction.
 Lack of social medias/connection: -the system doesn’t have a way user can
create profiles and capable of add friends or connecting with others.
 Lack of tweets/posts for the campus community publicly: -the existing system
doesn’t support for such features in which users can poet for what is going on
or what is coming
 Lack of providing news feeds, announcements: - despite of having such
system they don’t provide a way to enable all the announcements, upcoming
events and academic schedules or reschedules for students and other users
 Lack of users to share what they have with peers: - the existing system
doesn’t support users to upload their files and share additional resources with
other members of the community.
1.3 Statement of the Problem

This project is about addressing a problem in the faculty which has been existed since it was first
launched/began its work officially. Of course as we are about try to address most the manual
system and interactions to a web based and able to dynamically synchronize, in which the system
shall notify the college community about new updates and the web system is a recent discovery.
2 years back act stuffs were launch an intranet to the faculty, it has too little resource which of
course is shared with an ftp server. Center of ITSC try to use ftp too, but it is not worth than
downloading uploaded files.
Considering the existing system being manual and tiresome to catchup with new updates the
community needs to have a way to: -
3
 Students need to communicate with their course instructors to make the best of
in the course: -they need a way to connect them and capable of asking for helps
when they get trapped with doubts not only from the teachers but also from their
colleagues
 Users need a way to connect with the whole community: -users have desires to
have a dynamic way to communicate with their friends in the campus free
 When there is a network outage or no internet access users need a way that files,
movies, music etc. accessed from the local server which shall be uploaded by
any interested users
Element Description
The problem of 1.Ease of communication among students with instructors
Affects ... 2. Students who didn’t get the idea of what to do faces difficulties
in this academics.
3. Instructor may not get his students easy unless there is a class or
he/she has to call for the class rep.
And results in ... 1.Loose communication and unclear with each other may be
ddacademic failure too for students.
2.result in bored one over another, lost the key concepts.
Benefits of a solution ... 1.instructors will create a group for his/her course and students
fffshall join the group and then.
A. instructor can:
- Announce schedules for class change, assessments, projects
- Add lecture materials and related resources, like seminars, talks

ddto enable
- Students embrace the worth of what they are learning about

fffand enhance creativity
B. Students can:
4
- Ask for their doubts and get clarifications among them and the
dd instructor may help too.
- easy of getting up to date with the resources and comments fff

kkkkshared with peers
- will get clear with the course and get better understanding of it
Description
The problem of ... Announcements, upcoming events., schedules being manually

with paper
Affects ... The whole community
And results in ... 1. Other announcement might be added over and hide it
2.might be torn
3.you have to look for it usually or call somebody what is new out
there everyday
Benefits of a solution ... With online news feed/announcements and upcoming events
module:
1. Every announcements and notices shall be write as a

post/tweet for the community. Or
2. Notices might be scanned or digitized and posted
3. Users shall be notified with what things new is added to the
site
Description
The problem of ... 1. unable to Share additional resources like movies, music, talks
ffffetc. among peers when there is no internet to access external
ffffwebsites
Affects ... Members incapable of connecting with the internet
5
And results in ... Lack of updates about the external world and members unable to
catch up with the programs or shows etc. due to work hours. And
users need to connect to the internet to access them which in turn
results in high traffic and minimal bandwidth.
Benefits of a solution ... Members can upload whatever they have resources for others to
access whenever there is no internet access to the outside network
-the campus also will be benefit from minimal traffic usage by

students
Example: someone who is looking for a movie might found from

the local server and can easily download, use at as it is on his own
computer
-presence or absence of internet shall not make difference as far as

the local LAN works
Table 1.1 Elements of Problem and Description
1.4 Objective of the Project

1.4.1 General Objective
The main objective of the project is to create a local social media/network for the AAiT
community using the advantage of social networks amusing features and desire of the users to
such medias with tuition free access from local LAN network. In which enabling easy of
connection among users with their course instructors out of class, get notified with news feeds
instructor’s plans, every announcement. In addition, users are capable of creating accounts make
friends, join groups, upload and download files of they want uploaded by peers.
6
1.4.2 Specific Objective
IT is our aim of creating a unique, 24/7 accessible and user friendly web application, the solution
we come up with will be flexible, modular and extensible. It assures a solid structure and
compatible model for the upcoming advanced projects supporting extra features to the future.
Our projects focus will be mainly on creating a local but scalable solution of bringing
educational features from the most popular social medias to support education with social
network capabilities. Review/analyses existing and propose a new and extended efficient system.
Providing an easier mechanism for sharing files. Providing a better method for users be notified
with new updates. Bring advancement for the campus and change the way we learn. Provide a
mechanism users get updates where ever they are through personal their mails. Develop a user
friendly, aesthetic and efficient website for performing the specified tasks. Testing and verifying
the project functionality.
1.5 Proposed System
By observing the problems in the existing system. We propose a system FLUTE which solve the
problem in the existing system. Where the institute’s administration and staff office can
announce the event like meeting program, conference schedule held on the campus and class
schedule to the community online through a web browser by using the campus’s intranet network
rather than using a notice board. The system enables a user to ask and get information from any
offices online rather than going to offices in face. The user can login using his/her account
details or new users can set up an account very quickly. They should give the details of their full
name, department, contact number and email. Every student has its own personal profile based
on their department.
The proposed system will solve lack of communication environment between the institutes
community by providing an online discussion forum where every user participate and discuss
about different issues. On this system a community member can react their feeling on the
content or announcement which is posted on the site by giving comment and like. In addition to
this there will be Question & Answer Home-It gives a capability of asking any educational
question and answer between student based on department.
7
In order to facilitate information exchange between students in the same department groups will
be created on each section.
The proposed system provide a student and teacher to upload and download educational
materials such as books and short notes based on their department.
In the proposed system Public announcements are open to all users who have access of intranet
network on the other way Department announcements and public announcements are displayed
to only registered user.
1.6 Feasibility Study
It’s obvious the campus still uses traditional way for different activities for customers. Such tasks
like announcements, class scheduling, registrar related process and other tasks still done
manually. We aim to change this traditional process by easy method internet all paper based
works now no longer used. All campus community can use this website together.
We build this website from and users can use easily from existing things like intranet, computers,
and network materials such hub, switches, routers and they build to serve users.so no cost at all
to invest for this project because all are there before. But sadly our campus community doesn’t
get properly what the materials give to the campus they build to easy community life inside
campus.
1.6.1 Economic Feasibility

There is no cost for users to use the website because it is a LAN technology but not use before
that much before. Now all are change campus societies simply connect LAN connection and get
what they want if someone needs class schedule program he can get from this website or if he
needs new announcements or campus related news, department related issues, course materials
he can get all from single website.
1.6.1.1 Developmental cost
There will be no personal cost because it is our final project so we believe if we develop this
website successfully the campus community and we developers may get great satisfaction.it also
save users time they are not confuse and tired longer. We are not plan to give training or it is not
necessary to give personal training because it is a simple web page and users may use different
8
websites so it will be easy normally. Users improve technology their skills above all they can
saved their time and energy.
1.6.1.2 Operational Cost

Without question this project may will be solve many problems. Obviously campus society so
tired by campus mechanism and feel mistreated but our project solve this problems slightly.
Peoples inside campus can communicate and share everything what they want easily. Without
paid any cost.it will fulfill their needs. They can also save their time.
1.6.2 Technical Feasibility

This project is centered on human factors it is a problem solver users can go to labs or they can
use by their own personal computers, smartphones to visit the website and get information about
all things.it is often computer-oriented and the solution is practical seen and witnessing by users.
1.6.3 Schedule Feasibility

We estimate to finish this project by the end of the year it is a final year project as well as it is
huge and vast so is reasonable why this project needs that much time if we do early that it may
not be sufficient so it will better give long time and work by the schedule.
1.7 Scope
This project resolved on web based file sharing mechanism and information exchange system on
AAiT. And at the end of the project we can give good opportunities for AAiT community by
enabling them to view new information and ask their doubt through the web and it ensuring good
file management and data base management system.
The system is composed of four major modules.
1.Create Event Announcement management module-This module will be designed to announce

every Institute’s activities, conference schedules and class schedules to the campus community.
This feature will have this method.
 Administrative offices:-
 Post any announcement to the community
9
 Post all department class schedules
 Users:-
 Can like and give comments on online announcements
 Download class schedules
2.Create a discussion/communication environment for the institutes community-this module will

be designed to create an environment where teachers, students and staff members can
communicate and exchange their idea. They can start the discussion by posting new idea, on the
other side other user can like and give comments on online posted discussion idea.
3. Upload and download pdf files: - This module will be designed for teachers to upload
educational material like a textbook, a reference book, power point to their student and the
student can access it and download. students also can upload such types of file.
4.Question and Answer environment-At this module the student can ask any educational
question and the answers will be giving by any other student and teachers.
1.7.1 Limitation of the Project
The study of the project is limited to only AAiT. The project is not concerned about the other
colleges and schools.
1.8 Methodology
In order to achieve goals and planned results within a defined schedule we will use a Feature
Driven Development (FDD). This methodology is more focused on simple and well-defined
processes, short iterative and feature driven cycles. All the planning and execution in this project
type take place based on the features. And also we will begin with basic practice steps which is
analysis of the existing system.
 Analysis: -analyze researches related to the subject of this project.

 Design and Implementation: -
 Based on the analyzed data, the system will be design. For the
deployment of use case diagrams we will use Visual paradigm designing tool.
 The implementation will be developed using PHP for back end
10
development. And HTML, CSS, Bootstrap, JavaScript, AJAX and JQuery for
front end development.
 Testing: -this step is the final step which includes testing all the functionalities
and dead link testing and analyze performance capabilities.
1.9 Project Management plan

1.9.1. Time Management plan
Chart 1.1. Time Schedule
1.9.2 Quality Management Plan
The Quality Management Plan for our project will establish the activities, processes, and
procedures for ensuring a quality product upon the conclusion of the project. Our quality
management activities ensure that:
 Products are built to meet agreed- upon standards and requirements

 Work processes are performed efficiently and as documented
 Non-conformances found are identified and appropriate corrective action is taken
11
1.9.3. Communication Management Plan
Type of Communication Method/ Frequency/ Information Participants/

Tool Schedule Responsibles
Internal Communication:
Project status,
Project Meetings Face to Face 4 days problems, risks, Project Team
changed
requirements
Sharing of project data Email Weekly New event, Project Team

Face to Face problems
Milestone Meetings Face to Face Weekly Project status Project Advisor

(progress) Project Team
Final Project Meeting Face to Face Monthly Allproject Project Advisor

documentation Project Team
and reports
External Communication and Reporting:

Project Report Paper with Monthly Project status Project Advisor
face to face -progress Project Team
-forecast
- risks
Table 1.2 Communication Management Plan
12
Chapter 2: Requirement Analysis
2.1 Introduction
This specification document is intended to serve as a reference point during the development
process and captures requirements that need to be met by the final system/application
deliverable. Basic issues addressed in this SRS documentation includes functionality, external
interfaces, performance requirements, attributes and design constraints. The documentation also
will serve as a contract between the developer or the supplier and the customer/users with respect
to what the final product would provide and help achieve. The detailed functional and non-
functional requirements have been provided with a complete use case and sequence diagrams of
how the expected product/system is going to be used/work. Having this clarity will help the
designer to adequately design and implement the desired product.
2.2 Scope
Project Flute is a LAN based web application for AAiT which enables users to share files by
uploading them to the server, create user accounts and connect with friends, instructors to create
course groups and share updates with his students, admins and offices create pages for providing
updates and descriptions to services they provide with updates on scheduling’s.
This project targets people who have access to the intranet and basic knowledge of website
navigation.
The platform developed will accomplish the following tasks for the different groups we have in
the system
Users will be able to
 Create account
 Add/confirm friend requests
 View public posts of upcoming events, schedules and news feeds of the faculty and
the stuffs
13
 Upload and download files to/from the file Spot, local server for peers don’t have
those files
 Chat with other users
 give comments on the posts
Students in addition to the regular users will be able to
 Join course groups created by instructor

 Request instructors to add them to course groups
 Ask questions to groups
 Respond/recommend for questions raised by the group members
Instructors in addition to regular users, is optional, will be able to
 Create course groups

 Add/remove members to the course group
 Post for announcements, group updates, assessment schedules and additional resource
recommendations to the members
 Give responses to questions raised by the members
Admins and stuffs will be able to
 create their own pages

 provide complete description of the services they provide
 post updates, news feed and office hours
14
2.3 General Description
Flute is a project to build a flexible and user-friendly, platform-independent web application in
order to replace the traditional paper based system for posting announcements to the notice board
to a web based. This targets primarily on creating adaptive web platform for students, instructors
and admins and offices to exchange latest updated information and news feeds.
As this system will be implemented on the campuses LAN network and the available
infrastructures. The existing network infrastructures performance, multi-user support and
failover recovery capability will pose greater impact on how better the system achieves its
desired plan.
Despite the available infrastructures, the user’s basic knowledge of using the web browsers will
be a critical factor for them to get the most out of the services provided.
2.4 Product Perspective

Instructors working at top/the leading universities like MIT, Stanford, Princeton create a course
website for interacting with students enrolled by enabling create their account. In these course
website/webpage instructors will post the resource and related recommended materials for
students, enable students to submit their assessments, solutions to the exams and projects will be
available for enrolled students only.
The other website is piazza, it gives instructor to make a course page and enable add students
enrolled for a course as a member. The instructor then can give updates, assessment schedules,
and share resources materials for the members, students can ask for questions or give comments,
answer questions quested by the members, and instructor does responses too.
In modern social media website like twitter and Facebook quick tweets/posts are implemented as
a feature for users to raise issues to discus with his/her friends and followers, and what other
friends or followed peoples have raised, ideas, will be shown as a newsfeed at the other friends
and followers.
Here at AAiT there is an intranet based file sharing systems, such as intranet.aait.edu.et,
software download center, despite too limited resources available it provides an ftp service for
15
downloading files and software’s. The 10.5.56.5, ITSC course repository uses as an ftp server for
sharing learning materials.
Like the above systems flute is a system that will provide a combined and concise ways for the
instructors can create course groups and give updates and share resource with enrolled students
by adding them as a member, enrolled students can ask for doubts and comment on raised ideas
out there. And those ideas will be viewed as a news feed to the groups. Admins and stuffs too
will create a page for propagating the services they provide, schedules and service hours etc.
Flute will also enable users to create accounts and chat with friends, upload files to the file spot
to share with and able to download files he wants uploaded by the others.
2.5 Product Functions

The final deliverable of these software product will have the main groups of user general users,
the students, instructors and admins and stuffs. This classification is based on the functionalities
while using the system they are about to use.
The system, flute, for general users will provide a functionality of enabling to create accounts
and access files uploaded to the file spot. The system will view the updates and news feeds
posted to the general public for those users. After the user clicked or requested for the files will
be provided for download automatically. The system also provides the users the functionality of
chatting with connected/online available users.
Students in addition to the general users, the product will have a functionality of them to be able
to join the course groups they are currently enrolled and ask for doubts to the course instructors
and the students enrolled too. Also the system will enable the student to give comments and
answers.
Instructors, if they want they have a full access to use the functionality of the general users. In
addition to the general users they have a functionality to create course groups and add enrolled
students as members, remove member and provide updates to his students will be viewed for
them while logged on to the group page.
Admins and stuffs will have a functionality to create their page. With their page the system will
provide them to describe the services they provide, give announcements and events to the
16
general users. The system will enable the admins and stuffs to provide updates to their page
users.
2.6 User Characteristics

Once the flute is up and running, started working, the users of the system according to the above
groups can be anyone at AAiT. But precautions need to be taken in order for the users to use all
the functionalities available on the system.
For users to gain the most out of the products provided by the system, basic understanding of
website navigation and an understanding of how to access the websites. Having the above
awareness will enable the users to use the functionalities provided by the product fully.
2.7 General Constraints

The following are considered to be the general constraint for the system we are going to develop.
a) Reliability Requirement- the system must be available 24 hours a day 7 days a week and
365 days a year. The functionalities of the system should always be working.
b) Criticality of the system- the system is important to all users to keep update with ongoing
activities. Especially updates shall be available.
c) Safety and Security consideration- the system and user data shall be kept on a server and
necessary precautions have to be taken for data not to be compromised.
2.8 Assumptions and Dependencies

Using this projects product, despite whatever platform/operating system they are suited with,
users already have a basic knowledge of using a website and browser navigation. To gain access
of some privileged features the users must have to create a user account and get permission from
the admins to use those specific features.
17
2.9 External Interface Requirements
2.9.1 User Interfaces
The website should work and be tested against IE, Firefox, Google Chrome and other websites.
There is a front and back end interface to build this website. We started from front end. Front end
will build with CSS, AJAX, JQuery, HTML, JavaScript. The back end also built in PHP and
their will be MySQL for database.
Sign in page
Figure 1: Sign in page
18
Home page
Figure 2: Home Page
19
A page for admins to manage members
Figure 3: A page for admins to manage members
20
Users Discussion Page
Figure 4: Users Discussion Page
21
File sharing Page
Figure 5: File sharing Page
22
Office administrator page
Figure 6: Office administrator page
2.9.2 Hardware Interfaces

The hardware interfaces used in should have to access the LAN network either through wired or
wireless connectivity. This includes:-
 Smartphones
 Tablets
 Laptops
 Desktop/Workstation computers
23
2.9.3 Software Interfaces
Software requirements of the system are very nominal and no other special requirement is there
hence it is economically feasible. Also PHP is open source and thus easily available free of cost.
Software used Description
Operating system We have chosen different windows,
Linux and mac operating system for its
best support
Database To save users record we have chosen

MySQL database
PHP, JavaScript, AJAX, JQuery, CSS, To implement the web app we have chosen
HTML 5 this languages for their more interactive
support
Table 1: Software Interfaces
2.9.4 Communications Interfaces

The communication between the different parts of the system is important since they depend on
each other. 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
the web portal.
Since flute is delivered in a web-based system, it will use HTTP for all communications over the
internet.
24
2.10 Functional Requirements
Functional requirements are the main functions that are performed in the projects. This
functional requirements are mainly focus on the project .the functional requirements are must
fulfill to implement.
STUDENT FUNCTIONALITIES
Student includes all students of AAiT in all programs who are currently learning in all
department.
2.10.1 FR #1 Upload and download files in the group
 The system shall display all uploaded files on the page which is assigned to display
uploaded files to an eligible users
 The system should allow all eligible users to upload a document
 The system should allow students to download a document
2.10.2 FR #2 Give comments
 The system shall provide an easy interface to give comments about the public
announcements they read
 The system shall allow the students to edit the comment he/she gave
 The system shall allow the students to remove his/her comment
2.10.3 FR #3 Like a posts
 The system shall provide an easy interface to like the public announcements they read
2.10.4 FR #4 Chat
 The system shall provide an easy interface to show online status of admin offices
 The system shall allow students to ask any question online with admin offices
 The system shall allow students to chat with their class mate who is online
2.10.5 FR #5 Participate in the community discussion
 The system shall allow students to post their idea to the community page
 The system shall allow students to post their comments to the community page
about the posted idea
25
 The system shall display all comments on the community page to all users
INSTRUCTOR FUNCTIONALITIES
Instructor is a person who teaches a subject in the institutes
2.10.6 FR #6 Upload files to the group
 The system shall allow instructors upload any educational material

 The system shall display all uploaded files to her/his student
2.10.7 FR #7 Answer any question
 The system should allow instructors answer any question asked by their student
 The system should display Answered questions by the student
2.10.8 FR #8 Announce class event
 The system should allow an instructor to announce class events on his course
2.10.9 FR #9 Create groups
 The system should allow instructor to create a group on their course
 The system should allow instructor to add and remove a course group member
ADMIN OFFICE FUNCTIONALITIES
Admin offices are different offices which provides services to the institutes community.
2.10.10 FR #10 Online chat
 The system shall allow an admin office live chat with the community
 The system should provide admin offices to provide or answer any doubts asked
by a community with online chat
2.10.11 FR #11 Describe services provided
 The system allow an admin office to briefly describe what service they gives
26
2.11 Use Case Models
2.11.1 Actors
The following are the identified Actors in this system.
Student: - represents all students of AAiT in all programs who currently learning.
Instructor:- represents a person who teaches a subject in the institutes.
Office Admin:- represents different offices which provides services to the institutes community.
Admin: - represents the administrator of the web site.
2.11.2 Use Cases

The use cases identified in the system are the following.
1. Register/Create account
2. Update profile
3. Login
4. Password reset
5. Upload file
6. Download file
7. Post announcement
8. View announcement
9. Post ideas in the community
10. Create group
11. Add member to the group
12. Remove member from the group
13. Ask question to the group
14. Answer question in the group
15. Give comment
16. Remove a comment
17. Like posts
27
18. Chat
19. View post
20. Describe services provided
21. Remove users
22. Post Class schedule
23. Post Class announcement
24. Log out
2.11.3 Use Case Diagram

2.11.3.1 Student use case diagram
Figure 7: Student use case diagram
28
2.11.3.2 Admin use case diagram
Figure 8:Admin use case diagram
29
2.11.3.3 Instructor and Office Admin Use Case Diagram
Figure 9: Instructor and Office admin use case diagram
2.11.4 Use Case Description
2.11.4.1 UC #1: Register/Create account

Use Case Name: Register/Create account
Actors: Student, Instructor, Office Admin
Description: enables a user to register to the system
Precondition: the user starts accessing the system

Flow of events:
1. The user wants to create account to the system.

2. The user clicks the “Sign Up” link.
3. The system displays a registration form to submit his/her profile information.
4. The users finishes filling the form and submits it by clicking the “Sign up” button.
30
5. The system checks the validity of the form submitted.
6. The system records the information and displays a confirmation message.
7. The use case ends.
Alternate Case A: The system detects a missing information
A.6 The system determines a missing information.

A.7 The system informs the user to re-enter the missing information.
A.8 The user enters the missing information.
A.9 The use case continues from step 6 of the basic flow event.
Alternate Case B: The user entered an information that is already recorded
B.6 The system finds a username in use by other user.

B.7 The system displays a message telling the username is in use already
B.8 The user change the used information and submit the form.
B.9 The use case continues from step 6 of the basic flow event.
Alternate Case C: The user entered invalid input
C.6 The system determines an invalid information.

C.7 The system displays an error message on the screen.
C.8 The system asks the user to re-enter the information.
C.9 The use case continues from where it have stopped.
Post Condition: The user has successfully registered to the system.
2.11.4.2 UC #2: Update profile

Use Case Name: Update profile
Actors: Student, Instructor
Description: enables the user to update or change his/her profile information.
Precondition: The user have successfully logged into the system with his/her account.
Flow of events:
1. The user wants to update his/her profile.

2. The user clicks the “profile” button.
31
3. The user clicks “edit” link.
4. The user updates his/her profile and clicks save to record the information to the system.
5. The system saves the change and display a message” profile updated successfully” to the
fdfdfdscreen.
Post condition: The user have updated his/her profile successfully.
2.11.4.3 UC #3: Login

Use Case Name: Login
Actors: Student, Instructor, Office Admin and Admin.
Description: enables the user to login to his account.
Precondition: the user is accessing the site.
Flow of Events:
1. The user wants to login to his account.
2. The user clicks the “login” button.
3. The system displays a form asking username and password.
4. The user enters his username and password and enters “login”
5. The system will take him/her to his/her account.
Alternate Case A: The user enters incorrect username or password.
1. The user enters incorrect password or username.
2. The system displays an error message saying “incorrect username or password”.
3. The system will display a form to re-insert his/her correct username and account.
4. The user will insert his/her correct username and password.
5. The use case continues from step 4 of the basic flow of event.
Post condition: The user have successfully logged into his/her account.
2.11.4.4 UC #4: Password reset
Use Case Name: Password reset

Actors: Student, Instructor, Office Admin and Admin
Description: enables the user to reset his/her password
Precondition: the user is accessing the site
Flow of Events:
32
1. The user forgot his/her password.
2. The user will click the “forgot password?” link under the login form.
3. The system will display the users email and ask if the users email is correct and active.
4. The system will send new password to his/her email
5. The user uses that password to login to his/her account.
Post condition: The users have successfully logged into his/her account.
2.11.4.5 UC #5: Upload file

Use Case Name: Upload file
Actors: Admin, Instructor, Office Admin, Student
Description: enables the Admin, Instructor, Office admin, Student to upload file
Precondition: The Admin, Instructor, Office admin, Student is accessing the system
Flow of events:
1. The user wants to upload a pdf and other file.

2. The user clicks the “Upload” button.
3. The system displays the file explorer wizard of the user’s machine.
4. The user chooses a file from his/her machine to upload.
5. The system displays upload completion message.
Post condition: The user has uploaded a file.
2.11.4.6 UC #6: Download file

Use Case Name: Download file
Actors: Student, Admin
Description: enables the user to download a pdf and other file from the site
Precondition: The user is accessing the system
Flow of events:
33
1. The user wants to download a file.
2. The users chooses a file and press the “download” link.
3. The system will start the download process.
4. The system will display a download completion message when finished downloading.
Post condition: The user has downloaded a file.
2.11.4.7 UC #7: Post announcement

Use Case Name: Post announcement
Actors: Admin, Office Admin
Description: enables the Office admin and system admin to post announcements to the
klklklklklkllklcommunity
Precondition: The office admin and system admin is accessing the community page
Flow of events:
1. The office admin and system admin wants to announce events to the community.
2. The office admin and system admin writes on the available text area and press the “Post”
fdfdfdbutton.
3. The system displays a posted announcements to the page.
Post condition: The office admin and system admin post announcements.
2.11.4.8 UC #8: View announcement

Use Case Name: View announcement
Actors: Admin, Student, Instructor, Office admin
Description: enables the user to view announcements posted by either system admin or office
admin on the community
Precondition: the user has logged into the system with his/her account.
Flow of events:
1. The user wants to view announcements.
34
2. The user will go to the home page by logged into the system.
3. The system will display the announcements sorted by time on the home page.
4. The user can read from there.
Post Condition: The user is successfully reading posted announcements.
2.11.4.9 UC #9: Post ideas in the community

Use Case Name: Post ideas in the community
Actors: Student
Description: The students wants to post their ideas to discuss with the community
Precondition: The user is accessing the community page
Flow of events:
1. The user wants to post discussion ideas to the community.

2. The user writes on the available text area on the community page and press the “Post”
lllllllllbutton.
3. The system displays a posted ideas the user posts.
Alternate case A: The system detects the user posts an empty idea
A.2 The system detects the user gives an empty comment

A.3 The system displays a message “u must be write something to answer a question”
A.4 The system gives another chance to the user to answer question.
Post condition: The user have successfully posted his/her idea.
2.11.4.10 UC #10: Create group
Use Case Name: Create group

Actors: Instructor
Description: enables the instructor to create group for his/her course
35
Precondition: the instructor has logged into the system with his/her account
Flow of events:
1. The instructor wants to create groups for his/her course

2. The instructor clicks the “Create Group” link
3. The instructor writes the group name and press the “Create group” button
Post condition: The Instructor have successfully created his/her course group.
2.11.4.11 UC #11: Add member to the group

Use Case Name: Add member to the group
Actor: Instructor
Description: enables the instructor to add members to his/her own course group
Flow of events:
1. The instructor wants to add members to the group.

2. The instructor add new group member by selecting it and clicking “add to group” button.
Post condition: New members will be added to the group.
2.11.4.12 UC #12: Remove member from the group

Use Case Name: Remove member from the group
Actors: Instructor
Description: enables instructor to remove members from the group
Flow of events:
1. The instructor wants to remove group member.

2. The instructor remove users from group by select the user and press “remove” button.
Post condition: The instructor has successfully removed the member.
36
2.11.4.13 UC #13: Ask questions to the group
Use Case Name: Ask question to the group
Actors: Student
Description: enables a student to ask any educational question to their group mate and
dddddddddddInstructor
Precondition: The user is accessing the community page
Flow of events:
1. The user wants to ask questions to the group.

2. The user writes on the available text area and press the “post” button.
3. The system displays a question the user posts.
Post condition: The user has asked question.
2.11.4.14 UC #14: Answer question in the group

Use Case Name: Answer question in the group
Actors: Instructor, Student
Description: enables instructors and students to answer question in the group
Precondition: The user is accessing the system
Flow of events:
1. The user wants to answer a question in the group.

2. The user writes his/her answer on the text box provided under every asked questions.
3. The user clicks the “Post” button to give his/her answer.
4. The system displays the posted answer.
Alternate case A: The system detects the user gives an empty answer
A.4 The system displays a message “u must be write something to answer a question”
A.5 The system gives another chance to the user to answer question.
Post condition: the user successfully answered the asked question he wants.
37
2.11.4.15 UC #15: Give comment
Use Case Give comment
Actors: Student
Description: enables the student to give a comment
Precondition: the student is accessing the system
Flow of events:
1. The user wants to give a comment

2. The user writes his/her comment on the text box provided under every posted ideas and
fffffffannouncements.
3. The user clicks the “Comment” button to post his/her comment.
4. The system displays the posted comment.
Alternate case A: The system detects the user gives an empty comment
A.4 The system displays a message “u must be write something to give comment”
A.5 The system gives another chance to the user to give comment.
Post condition: The user has given a comment.
2.11.4.16 UC #16: Remove a comment

Use Case Name: Remove a comment
Actors: Student
Description: enables the users to remove a comment
Precondition: the user has logged into the system with his/her account
Flow of events:
1. The user wants to remove a comment.

2. The user clicks the “delete” button under the given comment.
3. The comment will be deleted.
Post condition: The user has deleted the comment.
38
2.11.4.17 UC #17: Like posts
Use Case Name: Like posts
Actors: Student
Description: enables the user to like posted ideas
Precondition: the user is accessing the system by logged in with his/her account
Flow of events:
1. The user wants to like posted ideas.

2. The user chooses a posted ideas to like.
3. The user like the posted idea by clicking like button.
Post condition: The user has liked a posted ideas.
2.11.4.18 UC #18: Chat

Use Case Name: Chat
Actors: Student, Office admin, Instructor, Admin
Description: enables the users to chat with other concerned users
Precondition: the user has logged into the system with his/her account
Flow of events:
1. The user wants to chat with other users.

2. The user clicks the “Chat” link to chat with other user.
3. The system displays online available users.
4. The user chat with other users.
Post Condition: The user is chatting with online available users.
2.11.4.19 UC #19: View post

Use Case Name: View post
Actors: Admin, Office admin
39
Description: enables the admin and office admin to view posts which is posted by any other user
the community page
Precondition: the user has logged into the system with his/her account.
Flow of events:
1. The user wants to view.

2. The user will go to the community page by clicking “Community Page” link in the
dfdfdfdffhome page.
3. The system will display the posted ideas sorted by time on the page.
4. The user can view posts from there.
Post Condition: The user is successfully view posted ideas.
2.11.4.20 UC #20: Describe services Provided

Use Case Name: Describe services provided
Actors: Admin, Office Admin
Description: enables the Office admin to describe their service to the community
Precondition: the office admin has logged into the system
Flow of events:
1. The office admin wants to describe what service they provide to the community.
2. The office admin and system admin writes on their pages.
3. The system displays a service given by office to the community on the office page.
Post condition: The office admin describe their service to the community.
2.11.4.21 UC #21: Remove users

Use Case Name: Remove users
Actors: Admin
Description: enables admin remove users from community
Precondition: the admin has logged into the system
40
Flow of events:
1. The admin wants to remove bad users.

2. The admin chooses a user they needs to remove from community.
3. The admin clicks the “remove” button.
4. The system remove users.
Post condition: The instructor/admin has removed bad users.
2.11.4.22 UC #22: Post Class schedule

Use Case Name: Post Class schedule
Actors: Admin
Description: enables admin to post class schedules
Precondition: the admin has logged into the system
Flow of events:
1. The admin wants to post class schedules to the community.

2. The admin either writes class schedule or upload on the available area.
3. The system displays class schedules to the community.
Post condition: The admin published class schedules.
2.11.4.23 UC #23: Post Class announcement
Use Case Name: Post Class announcement

Actors: Instructor
Description: enables instructor to announce class events
Precondition: the instructor has logged into the system
Flow of events:
1. The instructor wants to announce class event to the course group member
41
2. The instructor writes his/her announcement on the text box provided.
3. The user clicks the “Post” button to post his/her announcement.
4. The system displays the posted comment.
Alternate case A: The system detects the instructor writes an empty text
A.3 The system detects the instructor writes an empty text
A.4 The system displays a message “u must be write some text to post new event”
A.5 The system gives another chance to the user to give comment.
Post condition: The instructor announced new events to the course group member.
2.11.4.24 UC #24: Log out
Use Case Name: Log out

Actors: Admin, Instructor, Office admin, Student
Description: enables users logout from the system
Precondition: The admin have logged into the system
Flow of events:
1. The user wants to log out from the system.

2. The user click the “Log out” link at the top edge of a page.
3. The user logged out and exit from the system.
Post condition: The user successfully logged out and exit from the system
2.12 Non-Functional Requirements

2.12.1 Performance
There shall be no immediate delays in between different actions performed by the user.
Opening new windows, clicking buttons and dismissing pop-up messages shall take less than 1
42
second on both the server-side and client-side versions of the software.On the server-side
application, accessing the database; whether it is for adding, removing, or displaying
information; shall take no more than 2 seconds. But the time delay for operation which needs
more internet connection will depend on the network connection of the system.
2.12.2 Reliability
We consider having two servers with identical content on them – a primary server and a
secondary server. And a third server monitors the primary server and detects if there is a
problem. If there is, it will automatically update the DNS records and it will be diverted to the
secondary server. Once the primary server is functioning again, traffic will be routed back to the
primary server.
2.12.3 Availability
The system must operate twenty-four hours a day, seven days a week. If the internet service gets
disrupted while sending information to the server, the information should be sent again
for verification.
2.12.4 Security
Accordance to security and access permission of the system each users has his or her own
username and password to use the system or to access data and upload/download files.so users
can login with his or her account in order to access files and information otherwise it is possible
to see only public posts.so FLUTe has great secure, accessible and usable only in authorized
ways by authorized users.
2.12.5 Maintainability
The system should be flexible enough for changes and be capable of any modifications
that would be applied to it.
2.12.6 Portability
The system is expected to be compatible with all web browsers and devices of various
specifications.
43
2.12.7 Usability
The System’s User interface should be user-friendly. Standard layout and colorings will be
used, and also familiar words will be used for developing the system. so that anyone with
a basic knowledge of computers will be able to use it. No special training is needed to use this
application.
2.13 Inverse Requirements

“Inverse requirements are limitations or things a system is crippled from doing”, any guesses
related to those aren’t really what inverse requirements are about. Anyone who doesn’t know
about inverse requirements would probably assume wrong things about them from how the name
is perceived. Inverse requirements actually clarify and explain whether those assumptions are
correct or just wrongly prejudiced.
One matter that a system isn’t structured to It is designed to serve the AAiT societies meaning
the members are obliged to be an AAiT students, administrator’s It won't accept students from
other college or institutes as a valid member.
2.14 Design Constraints

Design constraints are limitations that occur because of unavailability of another system or a
certain body not providing resources that are required to complete a specific section.one possible
constraint is student grade or students results because this section will need very serious attention
related to security. students grade may not easy to include to this website feature if something
wrong happens for this website automatically there will be a series problem to students grade.
Current website portal.aait.edu.et work students rank.
The other constraint also registration the system does not support for registration purpose
because registrar office may not give a permission for this feature it is a very risky because there
are a lot of issues in registration purpose. For example students may get a chance to learn in
AAiT campus by their grade so this system will directly relate with ministry of education so they
will not willing this feature to our website.
44
2.15 Logical Database Requirements
Database table Attributes description
User accounts - Username This table is used to verify

the
- password
users of flute using the
user name and password.
- Email
- Role
Also it is used to classify the
users using the role column.
User profiles -name On this section the database

holds the basic information of
-age
the users.
-sex
It store users information by
identify their name, age, sex,
-address
address, and id number.
-id
Table 2: Logical Database Requirements
2.16 Other Requirements
Training-related Requirements
No specific training is required to begin using this system.
45
Packaging Requirements
The system is delivered as a web based platform. Thus, no packaging requirement, such as
README file containing a minimal guidance for installing and running the software, is needed.
2.17 Change Management Process

Any requests to change the project scope and requirements shall be discussed by all the members
of the team. A change will be made only when the majority of the team agrees on the change. In
this case, the SRS document shall be updated by the team members in order to reflect the
changes, and a date of change shall be noted in the file. If this change request is made by the
client or anyone outside of the team, he or she will have to contact the team. If a change request
is made by a team member, he can raise it during the weekly team meeting or contact other team
members. During any of these requests, the team will assess the feasibility of the proposed
changes considering the time constraints and structural constraints of the implemented modules
and develop an implementation strategy. A change plan will be created for the implementation of
the change. The team will then continue implementing the new requirements.
46
Chapter 3: SYSTEM DESIGN
3.1 General Overview

This system is a web application platform for the AAiT community and it is mainly aimed at
providing a digital or web based announcements, news feed updates, student and instructor
course group for handling any updates, reschedules and lecture materials sharing within a group
of the students enrolled for that course. In addition, administrators and offices can be able to
create a course group form this web application and announce their updates for the community,
students will also be able to share files, upload or download from the local server shared by their
peers. Chatting with users will also be delivered.
For the development of the system we choose an incremental approach type of called feature-
driven development (FDD) in which a number of dependent phases that are repeated sequentially
with no feedback loops.
Till now we haven’t made any changes or modifications to the previously designated system
design. And from the general point of view the system looks like the context-diagram below.
47
Figure 1.1 Context-Diagram
3.2 Development Methods & Contingencies

For developing this system, we have chosen the incremental approach type of called feature-
driven development (FDD), a software development approach, in which a number of dependent
phases that are repeated sequentially with no feedback loops. With this approach the clear goal
and solutions will be primarily identified, requirements will be splinted for development
purposes and delivered in increments. Complete product evolves over time and therefore
customers do not need to wait for the final deliverable, each incremental releases a partial of
known solution so that they can began to realize business value without having to wait for the
complete solution. The first increment in developing the system is often the core product that is
the basic requirements are addressed and other supplementary features will be delivered
48
incrementally as a module for the basic system. This approach will also enable to provide new
and creative features to be added at any time. This conceptual approach will be used for the
whole system development in order to achieve a scalable solution.
Despite the conceptual design of the system is designed based on an incremental approach, an
object oriented approach will be used for the diagraming and modeling of the system
components and users. The UML modeling will be used for designing the objects class diagrams
and interactions.
While in the process of the design phase if the interface design and the system performance gets
very high with the consideration of the hardware’s capability for handling the systems final
deliverable, there might be an alternative approach to switch the system design to a fully social
network with the addition of video streaming and wiki features in which the users to have an
advantage of publishing articles and stories.
49
3.3 System Architecture
3.3.1 Subsystem decomposition
3.3.1.1 Activity diagram
Figure 2.1 Sign in Activity diagram
 Login: - enables the user to login to the system using his/her account information.
 If registered the system authenticates his account information deny or accept his/her request
and enable access to the system.
 If unregistered the system will notify the user he needs to be authenticated to the system
before logging in and displays a registration form.
 If registered user insert invalid username and/or password the system will notify the user to
insert valid username and password and redirect to the sign in page.
50
Admin Activity diagram
Figure 2.2 Admin activity diagram
 View user: - enables the admin to see the number of users and their activities.
 Control post:-enables the admin to evaluate uploaded files, stories or comments.
 Post Announcement:-The admin can post Announcements.
 The Admin can view posted ideas.
 The admin can deny or allow comments according to the sites policy.
51
 The admin can deny or allow posted ideas according to the sites policy.
View announcement and post idea activity diagram
Figure 2.3 View announcement and post idea activity diagram
 View announcement: - enables users to view public announcements.

 Users can give comment and like on these public announcements.
 Post idea:-enables users to post ideas.
 Users can give comment and like on these posted ideas.
52
Upload/Download files activity diagram
Figure 2.4 Upload/Download files activity diagram
 Upload file:-enable users to upload files.

 If users try to upload invalid files the system will notify the user to select and upload
valid files.
 Download files: - enable users to download files on the file spot.
53
Upload/Download files activity diagram
Figure 2.4 Upload/Download files activity diagram
54
3.3.1.2 UML Component Diagram
Figure 2.5 Component Diagram of FLUTe
3.3.1.3 Hardware/software mapping

3.3.1.3.1 UML Deployment Diagram
Deployment diagram shows the physical nature or topology of the system, and describes what
runs where. Represents the deployment view of the system.
Nodes are nothing but physical hardwares used to deploy the application. The nodes included in
our system are the following
Database Server: - used to store site data, user information and account data.
Web Server: - middle layer between the internet cloud and the database server used to sort and
organize requests and responses between the client and server.
Modem/ Middle layer device: - used to create connection between the user and the internet
cloud or to provide network communication link.
Internet: - the main communication media between the client/user and server/data provider.
End Device: - an end device in the user side for accessing and retrieving data from the site.
End user: - a user accessing the website.
55
Figure 2.6 Deployment diagram
Deployment diagram also describes the topology of the system and configuration of run-time
processing elements and the software components and processes.
3.4 Object Model

3.4.1 Class Diagram
The architectural design has total of 13 classes.
56
Figure 3.1 Class diagram
57
3.4.2 Sequence Diagram
3.2 Sequence Diagram
The system allow users to login
Figure 3.3 Login Sequence Diagram
58
The system should allow users to logout
Figure 3.4 Logout Sequence Diagram
59
The system should allow users to register an account
Figure 3.5 Register Sequence Diagram
Admin Sequence Diagram
60
Figure 3.6 Admin Sequence Diagram
4. Detailed Design
61
Table 4.1: Account class
Account
+Create Account:String
+Login:String
+Logout:String
+getNewAccount()
+getLogint()
Table 4.2: Attributes description for Account class
Attribute Type Visibility Invariant

Create Account String Public Create Account <> NULL and must contain first, middle
and last name and shouldn’t contain special characters
and integers.
Login String Public Login <> NULL must be enter to the system if the user
have valid account.
Logout String Public Address <>NULL and it must be contain to exit from the
system.

Table 4.3: Operation description for Mobile Client class
Operation Visibility Return Argum Pre-Condition Post

type ent Condition
Get New Account Public void . The user personal can get a The user
new account if he never personal can
open account. get a new
account if he
never open
account.
Get Login Public void . The user can logged to the The user can
62
system if he has an account logged to the
already. system if he
has an
account
already.
Table 4.4: User class
User
+full name:String
+last name:String
+Email:String
+Password:String
Table 4.5: Attributes description for user

Full name: String Public Name <> NULL and must contain first, middle
and last name and shouldn’t contain special
characters and integers.
Lname: String Public Name <> NULL and must contain first, middle
and last name and shouldn’t contain special
Password Integer Public Password<>NULL
 Must contain capital letter
 Must contain special character
 Must contain numbers
Email String Private Email <> NULL
 Must contain @
 Must contain. (dot)
 Position of @ >1
63
 Position of (dot)>position of @ + 2
 Position of (dot)+3<= total length of email
address and the total character of the Email
is at least 5 characters
Table 4.6: Update Profile
Update profile
+change fullname:String
+change username:String
+Password:String
Table 4.7: Attributes description for Update Profile

Change full name String Public Change full name <> NULL and must contain first,
middle and last name and shouldn’t contain special
Change username String Public Change username <> NULL and must contain first, last
name and shouldn’t contain special characters and
integers.
Password Integer Public Password<>NULL
 Must contain capital letter
 Must contain special character
 Must contain numbers
Table 4.8: student class
Student
+student id : String
+update profile : String
+Comment : String
+Post : String
+getStudent id()
+getUpdate profile()
Table 4.9: Attributes description for Student Class
64
Student id Integer Public Student id <> NULL and must contain id number and
shouldn’t contain special characters and integers.
Update profile String Public Update profile <> NULL and must contain first, middle
and last name and shouldn’t contain special characters
and integers.
comment Integer Public comment<>NULL
 Doesn’t blank
 Doesn’t contain special character
post String Private post <> NULL
 New ideas
 Suggestions
 Announcements
 messages
Table 4.10: Attributes description for Student Class
Operation Visibility Return Argument Pre-Condition Post

type Condition
Get Student id Public void . The user have his or The user
her own personal id have his
number. or her
own
personal
id
number.
Get Update Profile Public void . The user can update The user
his personal status. can
update
his
personal
status.
Table 4.11: Adminstrator class
65
Adminstrator
+adduser:String
+ removeUser:String
+announcement:String
+post:String
+verify user:String
+announcement()
+post()
Table 4.12: Attributes description for Adminstrator class

+adduser String Public Adduser<> NULL and must contain users profile.
+removeuser Integer Public Remove user <> NULL remove user entirely from the
system.
Post String Public post <>NULL and it must be contain all new
informatioins.
Announcement String Private Announcement <> NULL
 new class schedules
 upcoming events
 seminars
 meetings
Verify user
66
Table 4.13: Operation description for Adminstrator class
Operation Visibility Return type Argument Pre-Condition Post Condition
announcemen Public void . The administrator The administrator can

t can announce new announce new events
events for users and for users and
instructors. instructors.
post Public void . The administrator The administrator can
can post class post class schedules
schedules and other and other related
related things for things for clients.
clients.
Table 4.14: Instructor class
Instructor
+adduser:String
+ removeUser:String
+create page:String
+chat:String
+describe service:String
+getchat()
+getdescribe service()
Table 4.15: Attributes description for Instructor class

+adduser String Public Adduser<> NULL and must contain users profile.
+removeuser Integer Public Remove user <> NULL remove user entirely from the
system.
67
Create page String Public Create page <>NULL and it must be contain instructor
name.profile and files and not contain special
character.
Chat String Private Chat<> NULL clients can talk each other.
Describe service String private Describe service<>NULL describe services that are
belongs for clients.
Table 4.16: Operation description for Instructor class
Operation Visibility Return Argument Pre-Condition Post

type Condition
getChat Public void . To talk clients each To talk
other. clients
each
other.
getDescribeService Public void . Services like office Services
hour give directions like office
for users. hour give
directions
for users..
Table 4.17: chat class
68
Chat
+isonline:String
+isoffline:String
+savechat:String
+saveChat()
Table 4.18: Attributes description for Chat class

isonline String Public isonline<> NULL and must check the users is online.
+isoffline Integer Public Isoffline <> NULL must check the user is offline.
+saveChat String Public saveChat <>NULL and it must be save the chat
conversations.
Describe service String private Describe service<>NULL describe services that are
belongs for clients.
Table 4.19: Operation description for Chat class
Operation Visibility Return type Argument Pre-Condition Post

Condition
saveChat Public void . Save chat conversation Save chat
by date,time and type of conversation
the conversation. by date,time
and type of
the
69
conversation.
Chapter 4: CONCLUSION AND RECOMMENDATION
6.1 Conclusion
This project provides a web platform for the AAiT community, it makes the manually paper
based system accessible through a web application deployed over the campuses LAN, where
users will be able to share files, chat online with peers and checkout for the updates and
announcements within the campus. Instructors create group for the course they teach, add or
remove their students as a member and give updates easily. Instructor can also respond for the
doubts raised by the members. Students already joined the course group have access to the
resources, updates and recommendations provided by the instructor. Offices and Admins creates
a page for announcing what services they provide and what office hours they are available.
As a team we believe that this system will provide a better and flexible way for keeping the
campuses community up-to-date and eliminates many of the paper works with the physical
notice boards.
6.2 Recommendation
To get the most out from this project user should be aware of what functionalities the system
provides. and therefore the developers or concerned system administrators should give a basic
awareness of the applications the system has and how to use it.
For development it will be better to use the stable releases of the programming languages to
avoid dysfunctionalities as of their might be more deprecation from the beta versions, in fact
using the updated releases would be more preferable for better performance and minimal security
holes.
For running this application redundant should be as it adds more reliability through
synchronization whenever the primary server goes down. And it will also keep running when the
application when their need a maintenance or an upgrading of the system.
70
We believe this project could be further expanded as the campuses geeks arena for computing to
build more additional features to systems, like code repository modules, AAiT’s app store for
sharing applications, geeks network and online collaboration to create a more competent
environment among the schools at AAiT. And therefore ITSC should enable this application as
an open for the programmers who would like the system to be more pleasing under a creative
commence of the center.
71
BIBLIOGRAPHY
1) SRS Document template - ITSC graduate committee
2) Document templates for student projects in software engineering, Declan Delaney and
Stephen brown – department of computer science, national university of Ireland, technical report
NUIM-CS-RT2002-05
3) Software requirements specification for project iTest requirement for version 1.3.0 prepared
by Karl E. wagers
4) Generating Software Requirements Specifications(IEEE-Std.830-1998) document with Use

Cases
5) Software Requirement Specification for web based integrated development environment,

TinTin, 2012 6) Software Requirement Specification for nTravel version 1.1 approved prepared
by NAMMP soft Inc. 11.1.2007
 Competitive Counselling System, Software DesignSpecification Version 1 By Saurabh

Singh.
Web resource
 The Complete Guide to UML Diagram Types with Examples

< http://creately.com/blog/diagrams/uml-diagram-types-examples/> Date:29.12.2016
 UML - Deployment Diagrams
< https://www.tutorialspoint.com/uml/uml_deployment_diagram.htm >Date:30.12.2016
 UML - Component Diagrams
< https://www.tutorialspoint.com/uml/uml_component_diagram.htm > Date:13.01.2017
 UML Activity Diagrams: Guidelines
< https://msdn.microsoft.com/en-us/library/dd409465.aspx> Date:07.01.2017
 Lucid Chart-Component Diagram Tutorial
72
< https://www.lucidchart.com/pages/uml/component-diagram> Date:11.01.2017
 The component diagram
< http://www.ibm.com/developerworks/rational/library/dec04/bell/> Date:15.01.2017
APPENDIX
73

FLUTE

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

FLUTE

Uploaded by

Copyright:

Available Formats

ADDIS ABABA INSTITUTE OF

CENTER OF INFORMATION TECHNOLOGY AND

DEPARTMENT OF INFORMATION TECHNOLOGY

1.Abel Kefale ----------------ATR/2462/06

2.Tekleab Hadush -----------ATR/2578/06

3.Yohans Teklewold --------ATR/3032/06

4.Zelalem Molla -------------ATR/4756/06

Advisor: Mr. Eyob Wondimkun

February 12, 2017

Information Technology and Scientific Computing

Project Advised by:

Mr. Eyob Wondimkun

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ _____________

2. __________________ Chairperson _____________ _____________

3. __________________ Examiner _____________ _____________

4. __________________ Examiner _____________ _____________

5. __________________ Examiner _____________ _____________

Name Signature Date

1. Abel Kefale __________________ __________________

2. Tekleab Hadush __________________ __________________

3. Yohans Teklewold __________________ __________________

4. Zelalem Molla __________________ __________________

Advisor Name _________________________

1.2 The Existing System............................................................................................................2

1.3 Statement of the Problem....................................................................................................3

1.4 Objective of the Project.......................................................................................................6

1.4.1 General Objective....................................................................................................6

1.4.2 Specific Objective.....................................................................................................6

1.6.1 Economic Feasibility.....................................................................................................8

1.6.2 Technical Feasibility.....................................................................................................9

1.6.3 Schedule Feasibility......................................................................................................9

1.9 Project Management plan.................................................................................................11

1.9.1. Time Management plan............................................................................................11

1.9.2 Quality Management Plan.........................................................................................11

1.9.3. Communication Management Plan..........................................................................11

Chapter 2: Requirement Analysis..............................................................................................13

2.3 General Description...........................................................................................................15

2.4 Product Perspective...........................................................................................................15

2.7 General Constraints...........................................................................................................17

2.8 Assumptions and Dependencies........................................................................................17

2.9 External Interface Requirements.....................................................................................17

2.9.1 User Interfaces............................................................................................................17

2.9.2 Hardware Interfaces...................................................................................................23

2.9.3 Software Interfaces.....................................................................................................24

2.9.4 Communications Interfaces.......................................................................................24

2.10 Functional Requirements................................................................................................25

2.11 Use Case Models..............................................................................................................27

2.11.2 Use Cases.......................................................................................................................27

2.11.3.3 Instructor and Office Admin Use Case Diagram....................................................30

2.11.4.1 UC #1: Register/Create account...............................................................................30

2.11.4.2 UC #2: Update profile...............................................................................................31

2.11.4.3 UC #3: Login..............................................................................................................32

2.11.4.5 UC #5: Upload file.....................................................................................................33

2.11.4.6 UC #6: Download file.................................................................................................33

2.11.4.7 UC #7: Post announcement.......................................................................................34

2.11.4.8 UC #8: View announcement.....................................................................................34

2.11.4.9 UC #9: Post ideas in the community........................................................................35

2.11.4.11 UC #11: Add member to the group........................................................................36

2.11.4.12 UC #12: Remove member from the group............................................................36

2.11.4.13 UC #13: Ask questions to the group.......................................................................37

2.11.4.14 UC #14: Answer question in the group..................................................................37

2.11.4.16 UC #16: Remove a comment...................................................................................38

1. ____________ Advisor _ _______

2. ____________ Chairperson _ _______

3. ____________ Examiner _ _______

4. ____________ Examiner _ _______

5. ____________ Examiner _ _______

1. Abel Kefale

2. Tekleab Hadush

3. Yohans Teklewold

4. Zelalem Molla