SDD - Adeela Bibi Roll# 160701 PDF

APRIL 9, 2018
<STUDENT RESULT MANAGEMNET SYSTEM>

SOFTWARE DESIGN DESCRIPTION DOCUMENT
VERSION: 1.0
<ADEELA BIBI ROLL# 160701>

SESSION: 2016-2018
<THE CITY COLLEGE OF BAHAWAL PUR>
Revision History
Date Description Author Comments
<date> <Version 1> <Adeela BiBi> <First Revision>
Document Approval
The following Software Requirements Specification has been accepted and approved by the following:
Signature Printed Name Title Date

Dr. Supervisor, CSIT 21306 <date>
i
Table of Contents
1. INTRODUCTION....................................................................................................................................................................... 1
1.1 Purpose.................................................................................................................................................................................. 2
1.2 Scope ..................................................................................................................................................................................... 2
1.3 Overview .............................................................................................................................................................................. 2
1.4 Reference Material.............................................................................................................................................................. 3
1.5 Definit ions and Acronyms ................................................................................................................................................. 3
2. SYSTEM OVERVIEW .............................................................................................................................................................. 4
3. SYSTEM A RCHITECTURE.................................................................................................................................................... 5
3.1 Arch itectural Design........................................................................................................................................................... 5
3.2 Deco mposition Description ............................................................................................................................................... 9
3.3 Design Rat ionale ............................................................................................................................................................. 115
4. DATA DESIGN ...................................................................................................................................................................... 356
4.1 Data Description.............................................................................................................................................................. 377
4.2 Data Dict ionary ............................................................................................................................................................... 377
5. COMPONENT DESIGN ......................................................................................................................................................... 47
6. HUMAN INTERFACE DESIGN .......................................................................................................................................... 49
6.1 Overview of User Interface ............................................................................................................................................. 49
6.2 Screen Images .................................................................................................................................................................... 56
6.3 Screen Objects and Actions............................................................................................................................................. 56
7. REQUIREM ENTS MATRIX ................................................................................................................................................. 57
8. APPENDICES ........................................................................................................................................................................... 57
ii
1. INTRODUCTION
Examination is the most important academic activity to examine the student ability and
performance. Student result can be beneficial both for the Educational organization and
students. Students are increasing every year in an Educational institute, so it becomes
more difficult for the Administrator to organize the result on register. The basic issue for
every educational organization or school is to preserve and maintain the student result.
The previous system maintains the record of result on paper or register, which was
difficult to manage. This manual system is tedious when managing a large amount of
result records. Student result is maintained or organizes on register which is error-prone
and time consuming method.
It is essential to develop a system which is time saving, accurate, efficient, reliable, user
friendly, less storage needed and less error contain.
Student Result Management System is web-based, software application that is used to
maintain the student’s monthly test marks and final exam marks.
The main aim of this project is to provide the student result in a simple and accurate way.
The software provides a lot of different modules for different user like Administrator
module, Teacher module, Student module, Parent module etc.
The Whole system is under the control of Administrator. Using the administrator module,
Admin of an institute is able to read, write, update, change and delete the result records.
The Administrator can easily manage the student result.
This software also helps the teachers to update and maintaining class result in different
subjects. Teacher module is also used to analyses the teacher performance.
This SDD document focuses on the developing an application that stores the student’s
results and result can be access by the user or parents anywhere. Students can check their
result by entering their class Roll No. The main object of produce this system is to store
the student result in the form of report card. The report card module allows the user to
print the report card, or school can use the report card module to send the report card to
parents by E-mail.
SDD Document 1.0 Page 1 of 57 04/09/18 f

1.1 Purpose
This manual system contains many drawbacks are follows:
 It is time consuming method when search a specific result.
 Unorganized data is written on these registers.
 These registers occupy more space.
 This manual system contains a lot of errors.
The proposed system is used to overcome the drawbacks of the previous system. This
document defines the functions of Result Management System. The Student Result
Management System is built for maintaining the records of result of an institute such as
school and educational organization. The proposed system has many advantages:
 Maintain academics records of student.
 Student result data is secured.
 Report card generated.
 Easy access for the parents or user.
 Result data can be maintained for longer period of time.
 Less error occur, Saved data cannot lost.
 Simple, easy to access, accurate and efficient.
1.2 Scope
The scope of student result management system is very broad as compared to manual
system for keeping the records of student result.
 Result management system is designed for schools.
 Calculate the marks of monthly or final exam.
 Handles the problems that occur during calculating and maintaining result.
 Flexible system when any changes needed in the result.
 Only authorized user is allow to access the marks sheet.
1.3 Overview
This document focused on creating the automated student result management system.
This document explains the functional and non-functional requirement and also describes
the system and user requirements that represent the characteristics of Student Result
Management System. This is a computerized application used to maintain information
about result .This system will speed up the processing of result.

.
1.4 Reference Material

[1] Software Requirements Specification for project Result management system
[2] Software Requirements Specification for Problem Based Learning Module.
[3] Software Design Specification (SDS) for Result Management system.
[4] IEEE Recommended Practice for Software Requirements Specifications, Software
Engineering Standards Committee of the IEEE Computer Society.
[5] Software Requirements Specification for result management system (CMS)
[6] Software Requirement Specifications, Result Management system.
[7]http://www.freeprojectz.com/uml/result- managemnt-system.
[8] http:// www.scribd.com/doc/33852099/Result-management-system-project-report
[9]http://whatis.techtarget.com/definition/0,,sid9_gci1103696,00.html
[10] www.google.com.
[11] www.wikipedia.com
[12] www.w3schools.com
1.5 Definitions and Acronyms

SRS: Software requirement specification
SQL::Structured Query Language
IEEE: Institute of Electrical and Electronics Engineers
UML: Unified Modeling Language
SDD: Software Design Description

2. SYSTEM OVERVIEW
This document focused on creating the automated student result management system.
This document explains the functional and non-functional requirement and also describes
the system and user requirements that represent the characteristics of Student Result
Management System. This is a computerized application used to maintain information
about result .This system will speed up the processing of result.
We can design the system architecture. The system architecture is consists of ASP.NET,
Web server, Web Application and Database. We can also design Data Flow Diagram,
Use Case Diagram, Sequence Diagram, and Activity Diagram. We can design rational
such as E-R Diagram.
Graphical User Interface provide an interface through which user can interact with the
system to perform different tasks.

3. SYSTEM ARCHITECTURE
3.1 Architectural Design
The System Architecture is used to describe the overall structure of the system, system
components and relationships of the components of the system. The user connects with
the web browser using internet or TCP/IP connection. The web server will connect to the
database server like ADO.NET.
The System architecture section has detailed diagram of the system, server and client
architecture.
Figure 3.1.1: Architecture of the proposed system

Operational Description
The Database:
The database (Student Result Management System) makes available facilities for
administration, computation, documentation, preservation and presentation of students’
academic records.
The Web Server:

The web server accepts the student requests. By getting URL, translates it, send it back
over the internet from local disk, execute it, and send the output of the program back
over the internet to the requesting party.
The Web Browser:

The web browser is an interface through which the students, Parents, Teachers and
administrators retrieve, present, and traverse information resources on database.
ASP.NET 4.5 Architecture:

The ASP.NET 4.5 architecture is the consists of the visual studio 2010, web forms, MVC,
webpage, SPA, web API, signal R, caching, routing, model binding, hosting model,
site/services management, protocol abstraction, security and ASP.NET frame.

Figure 3.1.3: System Architecture

3.1.2 Block Diagram:
The following diagram show the block diagram. The block diagram helps the user to
search and view the student results.
3.1.2: Block Diagram

3.2 Decomposition Description
We define the all diagrams in this section. Data flow diagram, Class diagram, Sequence diagram,
Use case diagram and block diagram. The sequences diagram is the simple diagram the user can
easily understand the project detail and description. In use case diagram we use to component
actor and use case. It is the simple and easy to understand. Data flow diagram shows all
functionality of the project. Class diagram show the relationships. Class diagram describe the
structure of the project. Sequence diagram perform work in sequence way.
3.2.1DATA FLOW DIAGRAM

Figure 3.2.1 DFD Diagram, the data flow diagram represents the relationship between the
components. The data flow diagram is the level 0 the user first the register. The user can view the
account details. The admin control the student result management system.
Figure 3.2.1: Data Flow Diagram

Figure 3.2.2: Level 1 Data Flow Diagram



Figure3.2.5: Level 2 Data Flow Diagram

3. 2.2: Use Case Diagrams:
The use case diagram is for the result management system. The use case diagram for
the user, admin and teacher are as follows:
Figure 3.2.1: Use Case Diagram for Result management System

Use Case Name: Priority:
Login
High
Primary Actor:
Administrator, student, Teacher, Parents
Goal In context:
Gain access to the website
Brief Description:
 This use case is used when the administrator wants to access the website to
enable/disable/update the personal details of the student.
 This use case describes how different user login to the system.
Pre Condition:
The user must be logged onto the website in order for this use case to begin.
Relationships:
None
Basic Flow:
 The Website prompts the user for the user name and password.
 The user enters the user name and password.
 The Website verifies the password and sets the user’s authorization.
 The user is given access to the Website to perform his task.
Alternative Flow:
 The user enters invalid username and password.
 The system displays an error message.
 The user can reenter the name and password or cancel the login.
Post Condition:
If the use case was successful, the user logged into the system, if not, the system status
unchanged

Use Case Diagram for Admin
Figure 3.2.2: Administrator Use Case Diagram

Edit Student Information High
Primary Actor
Administrator
Goal In context
Edit the information of students
Brief Description
This use case is used when the administrator wants to edit the personal details of the
students that are enrolled in class and student data already exists in the database.
Pre Condition
 The Administrator must be logged into the system in order to edit student details.
 The details of the student must pre-exist in the database
Relationships
 Include
 Extend
Basic Flow
 The Administrator logs onto the System.
 The Administrator can edit following keys:
 First/last name
 Father Name
 Gender
 DOB
 Contact No
 Qualification
 City
 Email
 Address
 Description
 The Website updates the database according to edited details
 The student details are edited in the database.
Alternative Flow
 If the student details exist more than once then error message will display.
Post Condition
The student details edited in the database.

Maintain student Information High
Primary Actor:
Administrator
Goal In context:
Maintain the information of students
Brief Description:
 This use case allows the administrator to maintain the student information. This
includes adding, changing and deleting information from the system.
 This use case is used when the administrator wants to maintain the personal details
of the students that are enrolled in class and student data already exists in the
database.
Pre Condition:
 The Administrator must be logged into the system in order to maintain student
details.
 The details of the student must pre-exist in the database
Relationships:
 Include
 Extend
Basic Flow:
This use case starts when the administrator want to update, add or delete student
information from the system.
 The administrator selects the one of the edit operation.
 When administrator select one option then one of the sub flows is executed. If
administrator selects add a student, then the „add a student‟ sub flow is executed. If
administrator selects update student information, then the „update student
information‟ sub flow is executed. If the administrator selects delete a student, then
the „delete a student‟ sub flow is executed.
Add a Student:
 The administrator enters the student Information. This includes:
 First/last name
 Father Name
 Gender
 DOB
 Contact No
 Qualification
 City
 Email
 Address
 Description
 Once the administrator provides the requested information, the system generates
and assigns a unique register number to the student. Now the student is added to

the system database.
 The system provides the administrator to write the new register number.
Update Student Information:
 Administrator enters the Roll No.
 The system retrieves and displays the student information.
 Administrator can make changes to the student information
 The System updates the student information in the database.
Delete a Student:
 Administrator enters the Roll No.
 The system retrieves and displays the information.
 The System prompts administrator to confirm deletion of the student.
 Administrator verifies the deletion.
 The System deletes the student from the database.
Alternative Flow:
i. Student not found:
If the Update Student Information or delete a student sub flow student with
specific Roll No does not exists, then the System displays an error message.
The System administrator can reenter or cancel at which point the use case ends.
ii. Irrelevant data:
If the add a student sub flow invalid information is entered, the system display an
error message so that the administrator can re-enter or cancel.
iii. Delete Cancelled:
The administrator decides not to delete the student.
Post Condition:
The student details are added, updated or deleted in the database.

Use Case Diagram For Teacher:
Figure 3.2.3: Teacher use Case Diagram

Input Marks High
Primary Actor:
Teacher
Goal In context:
Result marks are input in the database
Brief Description:
 This use case allows the administrator to enter the marks into the student table.
Pre Condition:
 The Administrator must be logged into the system in order to maintain student
details.
Relationships:
 Include
 Extend
Basic Flow:
 The administrator wants to enter the marks obtained by the student in
different subjects in the tables of database.
 The system retrieves and displays the student table. If a student table does
not exist, it creates a new one.
 Once the administrator has entered marks, the system saves the table and
adds it to the database.
Alternative Flow:
I. Invalid Marks:
 In Basic flow, if invalid marks are entered, the system displays an error
message and prompts for a valid mark. The faculty must enter a valid mark or
cancel the operation in which case, the use case ends.
II. Marks already entered:
 If in basic flow, the student mark has already been entered, the system
displays the read only copy of marks and informs the faculty that the mark
has already been entered. So, no changes can be made to it. The faculty
acknowledges the message and the use case ends.
III. Fields left empty:
 If in basic flow, the field is left empty, the system prompts the faculty to
correct the error. The faculty can enter the mark or mark the student as
absent.
Post Condition:
The student marks are added in the table of database.

Use Case Diagram For Student:
Figure 3.2.2.4: Student Use Case Diagram

Display Student Information High
Primary Actor:
Administrator, Student, Parents, Teacher
Goal In context:
View student Information that exists in database.
Brief Description:
 This use case is used when different user wants to view the personal details of the
students already existing in the database on the screen.
Pre Condition:
 The Administrator must be logged into the system in order to view student details.
 The student details must be pre-exists in the database.
 The student ID must be entered correctly.
Relationships:
 Include
 Extend
Basic Flow:
 The Administrator logs onto the System.
 The Administrator searches the student from following keys:
 Student ID
 First/last name
 Registration No
 The System prompts for the student detail from one of the above keys.
 The student details are displayed on the screen.
Alternative Flow:
Student Not Found:

 If a student with the specified ID number does not exist, the system
displays an error message.
 The user can then enter a different ID number or cancel the
operation.
Post Condition:
The student details are display on screen.

Display Student Exam Result High
Primary Actor:
Goal In context:
View student result on screen that exists in database.
Brief Description:
 This use case is used when different user wants to view the result details of the
students already existing in the database on the screen.
Pre Condition:
 The Administrator must be logged into the system in order to view result.
 Result data must be pre-exists in the database.
 The student ID must be entered correctly.
Relationships:
 Include
 Extend
Basic Flow:
 The user logs onto the System.

 The user enters the Roll No of student.
 The student result displayed on the screen.
Alternative Flow:
Result Not Found:
 If a student with the specified ID number does not exist, the system
displays an error message.
 The user can then enter a different ID number or cancel the

operation.
Post Condition:
The student Result displays on screen.

Generate report card High
Primary Actor:
Goal In context:
Create a report card based on the annual result of student.
Brief Description:
 This use case allows the user to create an overall class or individual result. The
individual student result, toppers list, and improvement rate for the academic year
report is discussed.
Pre Condition:
 The user must be logged into the system in order to create report card result.
 Result data must be pre-exists in the database.
Relationships:
 Include
 Extend
Basic Flow:
 This use case starts with the actor user wishes to create a report.
 The system requests the user to specify the following report
criteria: Report type (either “Overall class/Department result”,
”Individual Student Result”, ”Toppers List”, and “Improvement
Rate for the academic year”).
 If the user selects the “Overall class/department result” report, the
system retrieves and displays the entire Students marks
information from the database.
 The system then requests the user to enter require information.
 If the user selects “Individual Student Result” report,
 The system requests the user to enter the Roll number.
 The system validates the Roll No and if it is valid, the displays the
report.
 Otherwise displays error message.
Alternative Flow:
 Requested Information Un available :
 If the requested information is unavailable, the system will
display an error message. The user can choose return to begin to
basic flow or cancel it.
 Invalid format or Insufficient Information:
 If the user has not specified sufficient information to create the
report, the system will prompt the user for missing information.
The user can re-enter or cancel the operation.
Post Condition:
The system generates the report card of student result.

3.2.3Sequence Diagrams:
3.2.3.1 Sequence Diagram for User Login:
Sequence Diagram for User login shows the user select role and the
browser validation of the user. The user enters the username and password.
If the username and password correct the message will display welcome and
if the user enter the incorrect username and password the message show
invalid username and password.
Figure 3.2.3.1: Sequence Diagram for Login

3.2.3.2 Sequence Diagram for view result:
Sequence Diagram for view result shows the user select role and the browser validation
of the user. The user accesses the main page, Select the view result form and enter the
student roll no. Then the system displays the student result on screen.
Figure 3.2.3.2: Sequence Diagram for View Result

3.2.3.2 Sequence Diagram for edit student information:
Figure3.2.3.3: Sequence Diagram for edit Student information

Figure3.2.3.4: Diagram for input Student Information

Figure3.2.3.5: Sequence Diagram for Delete Student Information

Fgure3.2.3.6: Sequence Diagram for View Student Information

Figure3.2.3.7: Sequence Diagram for View Result

Figure3.2.3.8: Sequence Diagram for generate report card

3.2.4: Activity Diagrams:
Figure: 3.2.4: Activity Diagram

3.3 Design Rationale
In this design we define the ER diagram and their relationships. Admin is the entity and has
many attributes. User is the entity and has many attributes.
E-R Diagram
Figure: 3.3.1 Entity Relationship Diagram

4. DATA DESIGN
Class Diagram:
Figure4.1: Class Diagram for Result management System

4.1 Data Description
Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed and organized. List
any databases or data storage items.
4.2 Data Dictionary
Admin table:
4.2.1 Admin ID
4.2.1.1 Admin ID
4.2.1.2 It is identify for admin Id
4.2.1.3 Integer
4.2.1.4 4
4.2.1.5 10000
4.2.1.6 It contains only integer value.
4.2.2 Admin Name
4.2.2.1 Admin Name
4.2.2.2 It is identify for admin name
4.2.2.3 Varcher
4.2.2.4 8
4.2.2.5 It contains only character values.
4.2.3 Admin Gender
4.2.3.1 Admin Name
4.2.3.2 It is identify for admin gender
4.2.3.3 Varchar
4.2.3.4 8
4.2.3.5 It contains only characters
4.2.4 Admin DOB
4.2.4.1 Admin DOB
4.2.4.2 It is identify for admin DOB

4.2.4.3 Varcher
4.2.4.4 8
4.2.5 Admin Email
4.2.5.1 Admin Name
4.2.5.2 It is identify for admin Email
4.2.5.3 Varchar
4.2.5.4 8
4.2.6 Address
4.2.6.1 Address
4.2.6.2 It is identify for admin address
4.2.6.3 Varchar
4.2.6.4 20
4.2.7 Phone No
4.2.7.1 Phone No
4.2.7.2 It is identify for admin phone no
4.2.7.3 Integer
4.2.7.4 12
4.2.7.5 It contains only integer values.
Teacher Table:
4.2.8 Teacher ID
4.2.8.1 Teacher ID
4.2.8.2 It is identify for Teacher ID
4.2.8.3 Integer
4.2.8.4 4
4.2.8.5 10000
4.2.8.6 It contains only integer values
4.2.9 Teacher Name

4.2.9.1 Teacher Name
4.2.9.2 It is identify for teacher name
4.2.9.3 Marcher
4.2.9.4 8
4.2.9.4 It contains only character values.
4.2.10 Teacher Email
4.2.10.1 Teacher Email
4.2.10.2 It is identifying for teacher email
4.2.10.3 Marcher
4.2.10.4 15
4.2.11 Phone No
4.2.11.1 Phone No
4.2.11.2 It is identify for teacher phone No
4.2.11.3 Varchar
4.2.11.4 12
4.2.11.5 It contains only integer value.
4.2.12 Appointment Type
4.2.12.1 Appointment Type
4.2.12.2 View appointment type
4.2.12.3 Marcher
4.2.12.4 50
4.2.13 Duration
4.2.13.1 Duration
4.2.13.2 Check time duration
4.2.13.3 Integer
4.2.13.4 5
3. Student Table:
4.2.14 Student Roll No

4.2.14.1 Student Roll No
4.2.14.2 It is identifying for student roll no.
4.2.14.3 Integer
4.2.14.4 4
4.2.14.4 10000
4.2.14.4 It contains only integer values.
4.2.15 Student Name
4.2.15.1 Student Name
4.2.15.2 It is identify for Student name
4.2.15.3 Varchar
4.2.15.4 50
4.2.15.5 It contains character.
4.2.16 Student Father Name
4.2.16.1 Student’s Father Name
4.2.16.2 It is identify for Student Father Name
4.2.16.3 Varchar
4.2.16.4 50
4.2.16.5 It contains characters.
4.2.17 Student DOB
4.2.17.1 Student Date of Birth
4.2.17.2 It Shows the DOB of the student
4.2.17.3 Varchar
4.2.17.4 50
4.2.18 Phone No
4.2.18.1 Phone No
4.2.18.2 It is identify for customer Phone no
4.2.18.3 Integer
4.2.18.4 11
4.2.18.5 It contains integer.
4.2.19 Address

4.2.19.1 Address
4.2.19.2 It is identify for student address
4.2.19.3 Varchar
4.2.19.4 20
4.2.20 Email
4.2.20.1 Email
4.2.20.2 It is identify for student email
4.2.20.3 Varchar
4.2.20.4 15
4.2.21 Caste
4.2.21.1 Caste
4.2.21.2 It is identify for student caste
4.2.21.3 Varchar
4.2.21.4 20
4.2.22 Religion
4.2.22.1 Religion
4.2.22.2 It is identify for student religion
4.2.22.3 Varchar
4.2.22.4 20
4. Exam Table:
Primary key: Exam ID
4.2.23 Exam ID
4.2.23.1 Exam ID
4.2.23.2 It is identify for exam id
4.2.23.3 Integer
4.2.23.4 4
4.2.23.5 10000
4.2.24 Paper Name

4.2.24.1 Paper Name
4.2.24.2 It is identify for paper name
4.2.24.3 Varchar
4.2.24.4 50
4.2.24.5 It contains character.
4.2.25 Exam Type
4.2.25.1 Exam Type
4.2.25.2 It shows the type of exam
4.2.25.3 Varchar
4.2.25.4 50
4.2.26 Date
4.2.26.1 Date
4.2.26.2 It shows the date of exam
4.2.26.3 Integer
4.2.26.4 11
4.2.27 Description
4.2.27.1 Description
4.2.27.2 It is identify the description of exam
4.2.27.3 Varchar
4.2.27.4 20
4.2.28 Student Exam ID
4.2.28.1 Student ID
4.2.28.2 It is identify the student id
4.2.28.3 Integer
4.2.28.4 4
4.2.28.5 10000
5. Result Table:
4.2.29 Result ID
4.2.29.1 Result ID

4.2.29.2 It is identify for result id
4.2.29.3 Integer
4.2.29.4 4
4.2.29.5 10000
4.2.29.6 It contains integer
4.2.30 Exam ID
4.2.30.1 Exam ID
4.2.30.2 It is identify for exam id
4.2.30.3 Integer
4.2.30.4 4
4.2.30.5 10000
4.2.31 Student ID
4.2.31.1 Student ID
4.2.31.2 It shows the id of student
4.2.31.3 Integer
4.2.31.4 4
4.2.23.5 10000
4.3.32 Result type
4.2.32.1 Result type
4.2.32.2 It is identify for result type
4.2.32.3 Varchar
4.2.32.4 20
4.3.33 Result Date
4.2.33.1 Result Date
4.2.33.2 It is identify for Seller email
4.2.33.3 Integer
4.2.33.4 11

5. COMPONENT DESIGN
Two components in component design. User view and Admin view.
User view
The user can find the student result and student information. The user must have basic
concepts about computers and the internet. Users should be able to perform the
following functions using the system.
 View, browse and select a category on the home page.
 The user can view and select student result.
 User can view all list of student result.
 User can search student result from a list and generate report card.
Home Page:
Home page is a good way for welcoming users on system main page. The home page
contains the buttons that display other user interfaces. Home page displays the welcome
message for users. After completing the operations the user can logout to the system.
Administrator can also change the password.
Student Page:
Student page contains different buttons for edit student information. Add button can be
used to new student data using student information form. Edit button used to edit the
existing information or update the student information. Delete button can be used to
delete student information. View button can display the list of students. Search button can
be used to search student information from list.
Result Page:
Result page contains different buttons for edit result information. Add button can be used to
new result data using result form. Edit button can be used to edit the existing result
information or update the result record. Delete button can be used to delete result from database.
View button can display the list of student results. Search button can be used to search
student result from list.

User Page:
User page contains different buttons for edit user information. Add button can be used to
add new user. Edit button can be used to edit the existing user information. Delete button
can be used to delete user data from database. View button can display different users.
Admin view:
Admin is the owner of the student result management system. The administrator is
responsible for maintaining all documents necessary for the all system. The administrator
can perform the following functions:
 Can insert, update, change and delete student record.
 Can view the account and change password.
 Can access all information about student.
 Manage result information.
 Can search a specific result.

6. HUMAN INTERFACE DESIGN
6.1 Overview of User Interface
This section provides the user interfaces in which user can interacts with system and
perform different tasks.
6.1.1 Main Page:
Description:
The main page displays the first page in which user can login to the system. The new user
can also register to the system.

6.1.2: Login Page:
Description:
User login form can be used to input user details. For login user can enter the name in
user name field. Password enters into the password field.

6.1.3: Home Page:
Description:
Home page is a good way for welcoming users on system main page. The home page
contains the buttons that display other user interfaces. Home page displays the welcome message
for users. After completing the operations the user can logout to the system. Administrator can
also change the password.

6.1.4: Student Page:
Description:
Student page contains different buttons for edit student information. Add button can be
used to new student data using student information form. Edit button used to edit the
existing information or update the student information. Delete button can be used to
delete student information. View button can display the list of students. Search button can
be used to search student information from list.

6.1.5: Result Page:
Description:
Result page contains different buttons for edit result information. Add button can be
used to new result data using result form. Edit button can be used to edit the existing
result information or update the result record. Delete button can be used to delete result
from database. View button can display the list of student results. Search button can
be used to search student result from list.

6.1.6: User page:
Description:
User page contains different buttons for edit user information. Add button can be
used to add new user. Edit button can be used to edit the existing user
information. Delete button can be used to delete user data from database. View
button can display different users.

6.1.7:Student information Form:

6.1.8: User information Form:

7. REQUIREMENTS MATRIX
Provide a cross reference that traces components and data structures to the requirements
in your SRS document.
Use a tabular format to show which system components satisfy each of the functional
requirements from the SRS. Refer to the functional requirements by the numbers/codes
that you gave them in the SRS.
8. APPENDICES
This section is optional.
Appendices may be included, either directly or by reference, to provide supporting details
that could aid in the understanding of the Software Design Document.

SDD - Adeela Bibi Roll# 160701 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SDD - Adeela Bibi Roll# 160701 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

APRIL 9, 2018

<STUDENT RESULT MANAGEMNET SYSTEM>

<ADEELA BIBI ROLL# 160701>

Signature Printed Name Title Date

SDD Document 1.0 Page 1 of 57 04/09/18 f

SDD Document 1.0 Page 2 of 57 04/09/18 f

1.4 Reference Material

1.5 Definitions and Acronyms

SDD Document 1.0 Page 3 of 57 04/09/18 f

SDD Document 1.0 Page 4 of 57 04/09/18 f

Figure 3.1.1: Architecture of the proposed system

SDD Document 1.0 Page 5 of 57 04/09/18 f

The Web Server:

The Web Browser:

ASP.NET 4.5 Architecture:

SDD Document 1.0 Page 6 of 57 04/09/18 f

SDD Document 1.0 Page 7 of 57 04/09/18 f

3.1.2: Block Diagram

SDD Document 1.0 Page 8 of 57 04/09/18 f

3.2.1DATA FLOW DIAGRAM

Figure 3.2.1: Data Flow Diagram

SDD Document 1.0 Page 9 of 57 04/09/18 f

SDD Document 1.0 Page 10 of 57 04/09/18 f

SDD Document 1.0 Page 11 of 57 04/09/18 f

SDD Document 1.0 Page 12 of 57 04/09/18 f

SDD Document 1.0 Page 13 of 57 04/09/18 f

Figure 3.2.1: Use Case Diagram for Result management System

SDD Document 1.0 Page 14 of 57 04/09/18 f

 The user enters invalid username and password.

 The system displays an error message.

SDD Document 1.0 Page 15 of 57 04/09/18 f

Figure 3.2.2: Administrator Use Case Diagram

SDD Document 1.0 Page 16 of 57 04/09/18 f

SDD Document 1.0 Page 17 of 57 04/09/18 f

SDD Document 1.0 Page 18 of 57 04/09/18 f

SDD Document 1.0 Page 19 of 57 04/09/18 f

Figure 3.2.3: Teacher use Case Diagram

SDD Document 1.0 Page 20 of 57 04/09/18 f

Input Marks High

SDD Document 1.0 Page 21 of 57 04/09/18 f

Figure 3.2.2.4: Student Use Case Diagram

SDD Document 1.0 Page 22 of 57 04/09/18 f

Student Not Found:

SDD Document 1.0 Page 23 of 57 04/09/18 f

 The user logs onto the System.

Result Not Found:

 The user can then enter a different ID number or cancel the

SDD Document 1.0 Page 24 of 57 04/09/18 f

SDD Document 1.0 Page 25 of 57 04/09/18 f

Figure 3.2.3.1: Sequence Diagram for Login

SDD Document 1.0 Page 26 of 57 04/09/18 f

Figure 3.2.3.2: Sequence Diagram for View Result

SDD Document 1.0 Page 27 of 57 04/09/18 f

Figure3.2.3.3: Sequence Diagram for edit Student information

SDD Document 1.0 Page 28 of 57 04/09/18 f

SDD Document 1.0 Page 29 of 57 04/09/18 f

SDD Document 1.0 Page 30 of 57 04/09/18 f

SDD Document 1.0 Page 31 of 57 04/09/18 f

SDD Document 1.0 Page 32 of 57 04/09/18 f

SDD Document 1.0 Page 33 of 57 04/09/18 f

Figure: 3.2.4: Activity Diagram

SDD Document 1.0 Page 34 of 57 04/09/18 f

Figure: 3.3.1 Entity Relationship Diagram