SYSTEM DESIGN SPECIFICATION

DOCUMENT

PROJECT TITLE
Content Management System and Student Business Services
DEFINITION OF TERMS (ACRONYMS)
SDS : System Design Specification
DFD : Data Flow Diagram
REG. NO : Registration Number
O/S BAL : Outstanding Balance
ADM. NO : Admission Number
ADO : Active X Data object
SQL : Sequential Query Language
ERD : Entity Relation Diagram

1
3.0 INTRODUCTION

Conceptually SDS describes how the software is to function in a general way without
being involved in low-level operational details. It involves the translation of the systems
specifications in the Software Requirement Specification document into technical
specifications for implementation. .

This document, describes the design and clear insight of the system concepts and
operations of the final product. It portrays the developers understanding of the stated user
requirements and a foresight of what is expected and any changes necessary before
implementation. The design then serves as a guide to the developers who shall write the
code as expected by the stakeholder.

The SDS discusses how the program is separated into modules, how the modules interact with
each other, and how users see the program. It also looks into several design considerations,
including design tradeoffs and code reusability. The designer provides for effective input to the
information system by using techniques of good form and screen design.

This document will also show how users would visualize the system and detailed description of
input, processes and anticipated outputs of specific sub-processes of the system. Simply SDS is a
description of how the anticipated functional and non-functional system requirements in
Software Requirement Specification are achieved. This includes:
The different aspects of design are captured through the use of:
a) Physical design.
b) Logical Design

3.1PHYSICAL DESIGN
Architecture
The proposed system is a multi tier web-based. Multi tier Architecture is a Client/Server
Architecture in which the user interface, functional process logic (business rules), computer data
storage, and data access are developed and maintained as independent modules, most often in
different platforms.

2
 The Database Layer
The proposed system's database will be implemented using Microsoft SQL Server 2005. This
layer provides high connectivity and availability, plus, it provides system developers with the
ability to manage and administer their databases easily, especially using the Graphical User
Interface (GUI) of its Management Studio. In addition to enabling developers to create their own
stored procedures or use built-in system ones.

The Application Layer

The Application Layer contains the User Interface (UI), Business Rules, and the Data-Access
Components. Dynamic Hypertext Markup Language is an umbrella term for a collection of
technologies i.e. static markup language (such as HTML), a client-side scripting language (such
as JavaScript), a presentation definition language (such as CSS), and the Document Object
Model that will be used together to create interactive and animated web based RIBS content
management system.

Hypertext Preprocessor (the name is a recursive acronym) will be widely used, for general-
purpose scripting web development to produce dynamic web pages.

New features of VB.Net which has the ability to work together will be used even within the same
project with the other languages that use the .Net Framework.

MSQL software will be used to create databases that will be used on desk systems all the way to
Web site applications.

Internet Information Services (IIS) version 5.0 or later must run on the Application Server to
enable the use of ASP.NET across it.

The Client Layer

The simplest client must have a PC, preferably running Windows XP as an operating system,
with Internet Explorer (IE) installed to enable the users to browse the website over the Internet.

3
 As a web-based application, all processing is done on behalf of the users' computers on the
server hosting the system. So, other operating systems such as Linux, UNIX, Mac OS, etc. might
be acceptable as client machines

CLIENT APPLICATION DATABASE

TIER TIER TIER

3.4.1 CONTEXT DIAGRAM

The diagram describes the interaction between different users and other systems and its
environment. It dwells on Inputs, Processes and Outputs of the System.
The diagram with context of RIBS (Ruiru Institute of Business Studies) represents the key
external users and how they interact with the system. In this case the Register registers the
student either directly or indirectly through the admin staffs. He also views the summary of
student registered through online registration. S/he also uploads and downloads registration
forms for offline registration for those students who chose to come to the Institute.

The Student on the other hand is seen here viewing receipt on successful registration. That
withstanding, the student also views his or her exam results as well as viewing the courses that
are available within a semester.
The administrator is seen here uploading various materials including exam timetable, course
materials and various schedules as well as viewing student registration reports

4
 3.4.2 DATA FLOW DIAGRAM
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system. On a DFD, data items flow from an external data source or an internal data
store to an internal data store or an external data sink, via an internal process.
This is a Level 0 data flow diagram that is an exploration of the System Context Diagram. The
main purpose of this diagram is to show various subsystems of RIBS and where they get the data
and which internal process is invoking it.

5
 Faculty
Student Information Faculty Process
Faculty
Process

College
Registration Administration
Information
Information Assignments
Student Process
Information
Course Info
Receipt Payment
Student Administrative
Information Student Course
data Information Information
Data Data
Course Process
Information

Course
Data

College Accounting Schedules

Accounts
Information Invoice
Data
process

Student
Examination
Exam
Process
Schedules

Payment
Information
Account

Student
Librarian

Membership
Registration
Process
Registration Info
Issue membership card

New Member Details

Validity Check Student

Membership data Add/Delete/Update
Info. Data
Member Details

Fig 3.2. Level 1 DFD

3.4.2CLASS DIAGRAM
The class diagram seeks to identify the various objects to be inherent in the system. Objects are
real life entities that have an identity, a state and exhibits some certain form of behavior.

In the case of RIBS, class diagram will show the class modeling the various objects that are
interacting with each other and the association thereby. In this case the main classes are; manage

6
course that shows the category for a given course is in and a use of this class can define new
course Manager as well as assign the same

The next class defines course catalog that shows a course specification. This class enables one to
get the prerequisite list for the selected course as well as defining and assigning the same.

The other major class is the class of student. This is a main class since the Institute revolves
around it. The class defines what each of the student shall possess like requesting for advisor,
advisor, register etc.

The next class is the web class. This represents the attributes of the class and the activity
surrounding it including home, admin, student, download/upload etc. other classes are as
indicated and their respective attribute and responsibilities

7
 CourseCatalog CourseSpecification
ManageCourse
-CourseSpec -Course
-CourseCat
+getPrequisitelist() +GetPrerequisiteList()
+Define()
+Define() +Define()
+Assign()
+Assign() +List()

WebSite Course
-student -Level
-Admin -Prerequisite
-Home
+GetPrerequisiteList()
+Download() +Define()
+Upload() +Assign()
+RegisterStudent()
+EnrolStudent()
+Login()

Student
-Transcipt
-Requests
-Advisor
Admin +CheckRequest()
+CreateRequest()
+SubmitRequest()
+Define()
+Assign()

Transcript
-FinishedCourse

Advisor
-Email
-PhoneNumber
-Number

3.4 .3 STATE CHART DIAGRAM

A state diagram is a type of diagram used in computer science and related fields to describe the
behavior of systems. It is an abstraction of what the system does. In this case, a user starts by
entering the URL. This displays the home page of RIBS. From here the user of visitor can go to
various links hosting the general information about the Institute, specialized content where the
user has to login. Once logged in, the user can register, view exam results, download/upload
materials depending on the kind of the user.

8
The general content contain information about the Institute, Mission and vision, Library,
research and development etc.

3.4 System Home Page

Enter URL(www.ribs.com)

Home Page

Online Registration

Exam Results

General Content Specialized Content Login

Downloads

About Us Vision and Mission Research Library ........

......

3.5LOGICAL DESIGN
3.5.1 USE CASE DIAGRAM
A use case diagram shows a set of system activities and the elements that are players in those
activities called actors and relationships between these activities.
With respect to RIBS, the main actors will be student who carries out the following activities:
login to the system, online registration, viewing report card, download course materials.

The other actor is the Instructor/Lecturer. With regard to RIBS, he does upload course materials
or download the same for editing, select courses to teach, mark and post or submit marked exams
The registrar is another actor logs in to the system, maintain Instructor information and the same
for the student, determines when to open and close registration.
The other actor is the course catalog which keeps detail about the courses.

9
The last actor is the billing system. This produces and indicates the number of courses the
student is taking as well as the amount chargeable.

System
Register For
Courses

Student

View Report card

Course Catalog
Login

Select Courses to
teach

Instructor/Lecturer

Submit Grades

Maintain Professor
Information

Registrar

Maintain student
information

Close Registration

Billing System

10
3.5.2 ACTIVITY DIAGRAM
This shows the coordination and flow of various activities within the use case diagram as shown
below:

3.5.2.1 Web Administrator

The web admin logs into the system, checks uploaded materials which can either be normal or
those that requires approval especially those that touches issues about confidentiality like
publication, address from various heads like the principal etc. the normal materials include
information like checking registered students, and subsequent generation of reports. If the
uploaded materials require approval and the admin have approved it, it is rendered else it is sent
back to the source for editing.

Login Check Uploaded Materials Approve Content Render Content to site

Disapprove Content

Check Registered Student

Generate Reports

Fig 3.5.1: Web Admin Activity Diagram

11
3.5.2.2 Registered Student System Login
When a student logs in, he or she can register for a course, download course materials or check
examination results. This is depicted in the following activity diagram

Course Registration

Login Web Application

Download Course Materials

Check Exam Results

Fig 3.5.2: Registered Student Login

3.5.2.3 Lecturer/Instructor System Login

The lecture/Instructor can log in to the system to enter marks for his or her student. He can also
verify the entered marks on request by the examination officer or can have the activities executed
concurrently. S/He can upload course content or update existing course materials simultaneously.
These are represented in the following activity diagram.

Enter Course Marks

Upload Course Content

Login to Web Application

Verify Marks against Student Registration Update Existing Materials

Fig 3.5.3: Lecturer System Login

12
4 DATABASE DESIGN
This is a design technique by which relational database tables are structured in such a way to
make them invulnerable to certain types of logical inconsistencies and anomalies. This is an
activity that involves eliminating data redundancies in a relational database system.

This is done with the aim of sorting the various attributes into tables in such a way that:
➢ There are no repetitions within tables
➢ There are no partial dependencies on the primary key
➢ There are no transitive dependencies among attributes of a table.

This is illustrated below:

UNF 1NF 2NF 3NF
Stdfname stdFname stdFname tblStudent
Stdsname stdSname stdSname
Address stdAddress stdAddress stdFname
Registration No. stdRegNo. stdRegNo. stdSname
Sponsor stdPhoneNo. stdPhoneNo. stdAddress
AdvisorFname guardian guardian stdRegNo.
AdvisorSname stdAdvisorId stdAdvisorId stdPhoneNo.
AdvisorId guardian
AdvisorAddress advisorId advisorId stdAdvisorId
AdvisorPhoneNo. adFname adFname
CourseID1 adSname adSname tblAdvisor
CourseDescription1 adAddress adAddress advisorId
CourseInstructorId1 adPhoneNo. adPhoneNo. adFname
CourseInstructorName adSname
CourseID2 CourseId CourseId adAddress
CourseDescription2 CourseDesc CourseDesc adPhoneNo.
CourseInstructorId2 CourseInstructor CourseInstructor
CourseInstructorName2 tblCourse

13
 …… InstructorId InstructorId CourseId
InstFname InstFname CourseDesc
InstSname InstSname CourseInstructor
InstAddress InstAddress
InstPhoneNo. InstPhoneNo. tblInstructor
InstSpecialization1 InstSpecialization1 InstructorId
InstSpecialization2 InstSpecialization2 InstFname
InstSname
InstAddress
InstPhoneNo.
InstSpecialization1
InstSpecialization2

4.5 Entity attributes and meaning

Entity Name and Meaning
Attributes
tblStudent Student Table holding information about the student in the
institute
stdFname Student first name
stdSname Student surname
stdAddress Student address
stdRegNo. Student unique registration number
stdPhoneNo. Student Phone number
guardian Student next of kin
stdAdvisorId Student Advisor unique number

tblAdvisor Advisor table that hold information about available counselors

advisorId Unique advisor number
adFname Advisor firstname
adSname Advisor surname
adAddress Advisor address

14
adPhoneNo. Advisor phone number

tblCourse Course table. Hold information about the available courses

CourseId Unique course number
CourseDesc Course description
CourseInstructor Course instructor

tblInstructor Instructor Table. Hold information about the lecturers

InstructorId Unique instructor identifier
InstFname Instructor firstname
InstSname Instructor surname
InstAddress Instructor address
InstPhoneNo. Instructor phone number
InstSpecialization1 Instructor first specialization
InstSpecialization2 Instructor second specialization

4.6 Relational Schema

tblstudent

PK stdRegNo

stdFname
StdSname 1
stdphoneNo
stdguardian
stdadvisorid
courseId

*
*
tblcourse
PK CourseId

CourseDesc
CourseInstructorId

tblsInstructor
*
PK instructid
1 instructorfname
instructorsname
instructorSpecializaion1
stdAdvisor instructorSpecialization2
PK advisorId
1
advisorfname
advisorSname
advisorAddress
advisorPhoneNo

15
The above diagram represents the relationship between relationships of modules in the design
structure. For example one student advisor can mentor many students.

ENTITY RELATIONSHIP DIAGRAM

The above diagram show the interrelationship between different entities e.g. A student can
register for more than one course or an instructor can instructor multiple courses etc.

4.7 DATABASE SCHEMA DESIGN

The following are the main tables for the system
Schema
Student Table
This will hold information about the main customers of the College
Instructor Tables
This table will hold information about the main service providers
Course Table

16
This hold information about the courses offered by the institution.
Advisors Table
This table holds information about advisors of the students
StudentCourse Table
This hold information of students and the courses they are doing

4.7.2 Table Schema

Entity Attribute Data type Size
Student StudentID Varchar 15
StudentName Varchar 45
StudentPhone Integer 13
StudentAddress Integer 15
StudentCity Varchar 25
StudentAdvisorId Varchar 15
Gender Varchar 2

Advisors AdvisorsID Varchar 15

AdvisorsName Varchar 45
AdvisorsPhone Integer 13

Instructors InstructorsID Varchar 15

InstructorsName Varchar 45
InstructorsPhone Integer 13

Course CourseDescription Varchar 35

CourseInstructorID Varchar 15
CourseID Varchar 15

StudentCourse SCStudentID Varchar 15

SCCourseID Varchar 15

17
4.8 User Interface design
4.8.2 Login Dialog
The capture screen depicts the actual system login screen once the system is coded and
implemented

Login Dialog

Enter UserName

Enter Password

Ok Cancel

4.8.3 Student Registration Dialog

The design screen below depicts how the actual student registration login screen will look like
once the system is coded and implemented

Online Registration Dialog

Student Id

Names

Phone Number

Address

City

Advisor Id

Gender

Reset Submit

18
4.8.4 Course Entry Dialog
The design screen below depicts the course entry screen will look like once the system is coded
and implemented

Course Entry Dialog

Course ID

Course Description

Course Instructor ID

Reset Submit

4.8.5 Instructor/Lecturer Dialog

The design screen below depicts the lecturer/ instructor dialog screen as and when the system is
coded and implemented

Instructors Dialog

Instructor ID

Names

Phone Number

Reset Submit

19
4.8.6 Advisors Dialog
The design screen below depicts how the student advisor login dialog screen as and when the
system is coded and implemented

Advisors Dialog

Advisors ID

Names

Phone Number

Reset Submit

4.9 Output Dialogue Screens

4.9.2 Registered Students
Student ID Name Phone Number Address City Course Description
SC01-0085/09 KINYUA B. MATHENGE +25471290900 2993 THIKA BSc. IT
KCA-0200/2011 ERNEST KIMANI +254714909897 0988767 KITUI BCOM

20
4.9.3 Instructors Summary
Instructor ID Name Phone Number Course Specialization
231334454 Edward Njoroge +25471290900 OOAD
235464144 Odero Richard Ongayo +254714909897 Visual Programming

21
5 MINIMUM SYSTEM REQUIREMENTS
After running through the conceptual design, the tables, modules to be developed depict the use
of the following hardware and software

5.5 HARDWARE
The minimum Hardware requirements include:-
✓ Personal Computer (Pentium IV, 1GHz and above, 512MB RAM - Recommended)
✓ Web/internet access.
✓ Printer:- For producing hardcopies.

5.6 SOFTWARE
✓ Operating System: Microsoft Windows XP/Vista/7 or Linux(Fedora)
✓ General Office applications and in addition Adobe reader 5 and above
✓ Internet Explorer/Netscape/Firefox Mozilla

CONCLUSION
In conclusion, Software design is a process of problem-solving and planning for a software
solution. After the purpose and specifications of software is determined, software developer will
design or employ designers to develop a plan for a solution. The system developer is then able to
come up with a successful working system using Context diagrams and flowcharts among others
for the development of a good system.

22
6 REFERENCES

Books
✓ KENDALL & KENDALL, Systems Analysis and Design, International
✓ SOMMERVILLE I., Software Engineering, 7th Edition, 2004, ISBN: 0-321-21026-3, Software
Engineering by Ian Sommerville
✓ Object-Oriented Systems Analysis and Design With UML (Hardcover)~ Robert V. Stumpf
(Author), Lavette C. Teague (Author)
✓ Pressman RS Software Engineering Practitioner Approach (2004)
✓ WIKIPEDIA, The Free Encyclopedia, Multitier Architecture, cited on 29th April 2009,
✓ http://en.wikipedia.org/wiki/multitier_architecture.

Internet
Jacobson, Ivar (1992). Object-Oriented Software Engineering: A Use Case-Driven Approach. Addison-
Wesley. ISBN 0-201-54435-0.

23