[Project Name] [Document Name] [Version]

GIFT University Gujranwala

Project Final Report

For
<Project Name>
(Valid Title reflecting scope and objectives)

Submitted By:
Student Name 1 FA24-BCS-xxx
Student Name 2 FA24-BCS-xxx

Supervisor
<Supervisor Name>

Submission Date: (Day-Month-Year)

Original Version 1.0

Bachelor of Science in Computer Science (2024-2028)

The candidate confirms that the work submitted is their own and appropriate
credit has been given where reference has been made to the work of others.

i
September 23, 2024
[Project Name] [Document Name] [Version]

GIFT University Gujranwala

Project Name

A project presented to
GIFT University, Gujranwala

In partial fulfillment
of the requirement for the degree of

Bachelors of Science in Computer Science (20xx-20xx)

By

Student Name 1 SP09-BCS-xxx

Student Name 2 SP09-BCS-xxx

ii
September 23, 2024
[Project Name] [Document Name] [Version]

DECLARATION
We hereby declare that this software, neither in whole nor as a part has been copied from any source.
It is further declared that we have developed this software and accompanied report entirely on the
basis of our personal efforts. If any part of this project is proved to be copied from any source or
found to be reproduction of someone else's work, we will stand by the consequences. No portion of
the work presented has been submitted of any application for any other degree or qualification at this
or any other university or institute of learning.

Student Name 1 Student Name 2

--------------------------- ---------------------------

iii
September 23, 2024
[Project Name] [Document Name] [Version]

Executive Summary
In public places, there is often need for monitoring people and different activities going on, which
can be referred to many reasons later, including security. Appointing humans for this task involves
many problems, such as increased employee hiring, accuracy issues, trust concerns, no proof for later
use, and also the fact that a human can remember things till a certain time limit. Talking about the
current security system, they use dumb still cameras with a continuous recording facility irrespective
of whether any event may happen or not. Moreover, they are usually pointing at specific user-defined
locations, so more than one camera is required to cover the entire region.

To prevent all these problems from prevailing, the CSCS was developed. It is a surveillance system
that provides solutions to many of these problems. It is a standalone application that doesn’t require
any computer to operate. It monitors different situations using a camera that is able to rotate
intelligently based on sensor messages and captures the scene in the form of video or photos for later
reference as well.

The Customizable Surveillance Control System (CSCS) is a surveillance system that can be assigned
a sensor type; in our case, a heat sensor is used. It works accordingly, rotates the camera upon event
detection, and performs user-defined actions like capturing videos and storing them for future use.

It is an embedded system consisting of a Linux Fox kit with an embedded running server application.
Also, a camera, USB storage device, and a sensor node base station are attached to the Fox kit. LAN
communication is used by the user to download the videos and operate the system manually.

iv
September 23, 2024
[Project Name] [Document Name] [Version]

Acknowledgement
All praise is to Almighty Allah who bestowed upon us a minute portion of His boundless knowledge
by virtue of which we were able to accomplish this challenging task.

We are greatly indebted to our project supervisor “Supervisor’s Name”. Without his personal
supervision, advice and valuable guidance, completion of this project would have been doubtful. We
are deeply indebted to them for their encouragement and continual help during this work.

We are also thankful to our parents and family who have been a constant source of encouragement
for us and brought us the values of honesty & hard work.

Student Name 1 Student Name 2

--------------------------- ---------------------------

v
September 23, 2024
[Project Name] [Document Name] [Version]

Abbreviations
SRS Software Require Specification

PC Personal Computer

vi
September 23, 2024
[Project Name] [Document Name] [Version]

Table of Contents
1 Introduction ............................................................................................................................. 1

1.1 Project Background .......................................................................................................................1

1.2 Comparative Analysis....................................................................................................................1
1.3 Advantages/Benefits of Proposed System .....................................................................................2
1.4 Project Scope .................................................................................................................................2
1.5 Modules .........................................................................................................................................3
1.5.1 Module 1: Module Name ........................................................................................................3
1.5.2 Module 2: Module Name ........................................................................................................4
1.6 System Limitations/Constraints .....................................................................................................4
1.7 Tools and Technologies .................................................................................................................4
1.8 Team Members Individual Tasks/Work Division .........................................................................5
1.9 WBS and Gantt Chart ....................................................................................................................5
1.9.1 WBS with Gantt Chart .............................................................................................................7
1.10 Cost of Project ...............................................................................................................................7
2 Problem Definition .................................................................................................................. 8

2.1 Problem Statement .........................................................................................................................8

2.2 Proposed Solution ..........................................................................................................................8
2.3 Current System (if applicable to your project) ..............................................................................9
3 Requirement Analysis ........................................................................................................... 10

3.1 Requirement Elicitation Techniques............................................................................................10

3.2 Use Cases Diagram(s) .................................................................................................................10
3.3 Detailed Use Case (Tabular- Module Wise) ................................................................................11
3.3.1 Use Case Name ......................................................................................................................11
3.4 Functional Requirements (Tabular FR- Module Wise) ...............................................................13
3.4.1 Functional Requirement One .................................................................................................13
3.5 Non-Functional Requirements .....................................................................................................14
3.5.1 Reliability ..............................................................................................................................14
3.5.2 Usability .................................................................................................................................14
3.5.3 Performance ...........................................................................................................................15
3.5.4 Security ..................................................................................................................................15
3.5.5 Supportability ........................................................................................................................15
3.6 External Interface Requirements .................................................................................................15
3.6.1 User Interface Requirements .................................................................................................15
3.6.2 Software Interface ..................................................................................................................16
3.6.3 Hardware Interfaces ...............................................................................................................16
3.6.4 Communication Interfaces .....................................................................................................16
4 Architecture and Design ........................................................................................................ 17

4.1 System Architecture ....................................................................................................................17

4.2 Design Methodology ...................................................................................................................17
4.3 Data Representation [Diagram + Description] (ERD, JSON SCHEMA) ...................................17
4.4 Design Models [along with descriptions] ....................................................................................17
5 Human Interface Design ........................................................................................................ 18

5.1 Screen Images ..............................................................................................................................18

vii
September 23, 2024
[Project Name] [Document Name] [Version]

5.2 Models and Animations ...............................................................................................................19

5.3 Screen Objects and Actions .........................................................................................................19
6 Implementation...................................................................................................................... 20

6.1 User Interface/ Front End ............................................................................................................20

6.2 Brief Overview of the Proposed System .....................................................................................20
6.3 External APIs...............................................................................................................................20
7 Testing and Evaluation .......................................................................................................... 21

7.1 Test Plan ......................................................................................................................................21

7.2 Product Scope ..............................................................................................................................21
7.3 Intended Audience .......................................................................................................................22
7.4 Definitions, Acronyms and Abbreviations ..................................................................................22
7.5 Test Pass/ Fail Criteria .................................................................................................................22
7.6 Verification ..................................................................................................................................23
7.7 Validation ....................................................................................................................................23
7.8 Usability Testing..........................................................................................................................23
7.9 Module / Unit Testing..................................................................................................................23
7.10 Integration Testing.......................................................................................................................23
7.11 System Testing ............................................................................................................................23
7.12 Acceptance Testing......................................................................................................................23
7.13 Manual Testing ............................................................................................................................24
7.14 Test Cases ....................................................................................................................................24
7.14.1 Unit Testing (Test Cases) ......................................................................................................25
7.14.2 Functional Testing .................................................................................................................25
7.14.3 Integration Testing .................................................................................................................26
7.14.4 Automated Testing.................................................................................................................27
7.15 Environmental Needs ..................................................................................................................27
7.16 Responsibilities............................................................................................................................27
8 Requirement Traceability Matric .......................................................................................... 28

9 Conclusion and Future Work ................................................................................................ 29

9.1 Conclusion ...................................................................................................................................29

9.2 Future Work.................................................................................................................................29
10 Work Summary and Reviews ................................................................................................ 30

10.1 Lesson Learnt ..............................................................................................................................30

10.2 Work Break Down .......................................................................................................................30
10.3 Reviews Details ...........................................................................................................................31
11 References ............................................................................................................................. 32

12 Plagiarism Report .................................................................................................................. 33

13 Appendix A ........................................................................................................................... 34

13.1 WBS and Gantt chart: ..................................................................................................................34

13.2 Cost of project with WBS ............................................................................................................36
13.3 WBS with Gantt Chart .................................................................................................................37
13.4 Example: Context Diagram .........................................................................................................38
13.5 Example: User Classes and Characteristics .................................................................................39

viii
September 23, 2024
[Project Name] [Document Name] [Version]

14 Appendix B ........................................................................................................................... 40

14.1 Example: Use case Diagram ........................................................................................................40

14.2 Event-Response Tables................................................................................................................44
14.3 Story Boarding.............................................................................................................................45
14.4 Box-and-line diagram ..................................................................................................................47
14.5 Example of Architecture Pattern: ................................................................................................47
14.6 Design Models .............................................................................................................................49
14.7 Activity Diagram .........................................................................................................................49
14.8 Class Diagram..............................................................................................................................51
14.9 Sequence Diagram .......................................................................................................................53
14.10 Behavioral State Machine Diagram .........................................................................................55
14.11 Data Flow Diagram .................................................................................................................57
14.12 Screen objects and actions .......................................................................................................63
14.13 Screen Images/Mockups ..........................................................................................................63
14.14 Example Data Design ..............................................................................................................64
14.15 Example ERD ..........................................................................................................................66
14.17 Requirement Traceability Matrix ............................................................................................69
15 Appendix C ........................................................................................................................... 70

15.1 Deliverable Details for Capstone 1 ..............................................................................................70

15.2 Deliverable Details for Capstone 2 ..............................................................................................72
16 Style Guide lines ................................................................................................................... 74

16.1 Styles in Word .............................................................................................................................74

16.2 Page Layout & Size .....................................................................................................................76
17 Headings ................................................................................................................................ 76

17.1 Second Level Headings ...............................................................................................................76

17.1.1 Third Level Headings ............................................................................................................77
17.2 Figures and Charts .......................................................................................................................77
17.3 Program Code ..............................................................................................................................77
17.4 Table of Contents.........................................................................................................................77

ix
September 23, 2024
[Project Name] [Document Name] [Version]

List of Figures
Figure 1: Context Diagram of the System ............................................................................................ 3
Figure 2: WBS with Gantt Chart .......................................................................................................... 7
Figure 3: Current System ..................................................................................................................... 9
Figure 4: Use Case Diagram .............................................................................................................. 11
Figure 5: Selecting the Heading 1 style from the Word style menu .................................................. 75
Figure 6: The report style toolbar provides easy access to the approved styles. ................................ 75
Figure 7: Page settings defined for this document ............................................................................. 76

Figure A- 1: Basic Structure of WBS ................................................................................................. 34

Figure A- 2: WBS and Gantt Chart .................................................................................................... 37
Figure A- 3: Context diagram of the Cafeteria Ordering System ...................................................... 38

Figure B- 1:Use Case Diagram of an Appointment System .............................................................. 40

Figure B- 2 Box-and-Line Diagram for an Online Shopping Business ............................................. 47
Figure B- 3: Component-based Layered Architecture ....................................................................... 48
Figure B- 4: Activity Diagram for Make an Appointment Process ................................................... 49
Figure B- 5: Class Diagram for an Appointment System .................................................................. 51
Figure B- 6: Make Appointment Use Case ........................................................................................ 53
Figure B- 7: Sample Behavioral State Machine Diagram .................................................................. 55
Figure B- 8: Data flow diagram symbols, symbol names, and examples of the Gane and Sarson and
Yourdon symbol sets. ......................................................................................................................... 57
Figure B- 9: Context diagram DFD for an order system.................................................................... 58
Figure B- 10: Diagram 0 DFD for the order system .......................................................................... 59
Figure B- 11: Diagram 1 DFD shows details of the FILL ORDER process in the order system. ..... 60
Figure B- 12: ERD Example .............................................................................................................. 66

x
September 23, 2024
[Project Name] [Document Name] [Version]

List of Tables
Table 1: Related System Analysis ........................................................................................................ 2
Table 2: Tools and Technologies ......................................................................................................... 4
Table 3: Team Member Work Division ............................................................................................... 5
Table 4: WBS for software development project ................................................................................. 6
Table 5: List of modules in current system .......................................................................................... 9
Table 6: Show the detail use case template and example .................................................................. 11
Table 7: Description of FR-1 ............................................................................................................. 13
Table 8: Details of APIs used in the project ....................................................................................... 21
Table 9: Test Case Template (Module) .............................................................................................. 24
Table 10: Test Case Template (Unit 1) .............................................................................................. 25
Table 11: Test Case Template (Unit 2) .............................................................................................. 25
Table 12: Test Case Template (Functional) ....................................................................................... 26
Table 13: Test Case Template (Integration) ....................................................................................... 26
Table 14: Automated Testing ............................................................................................................. 27
Table 15: Lesson Learnt for the course project .................................................................................. 30
Table 16: Work Break down of individual Student for each milestone ............................................. 30
Table 17: Reviewer Comments .......................................................................................................... 31

Table A- 1:Example of a WBS for software development project .................................................... 35

Table A- 2: WBS with work progress ................................................................................................ 36
Table A- 3: Shows user classes and characteristic for Cafeteria ordering system ............................. 39

Table- B 1: Syntax for Use case Diagram .......................................................................................... 41

Table- B 2: Show the detail use case template and example ............................................................. 42
Table- B 3: Partial Event-Response Table for a Highway Intersection ............................................. 44
Table- B 4: Activity Diagram Syntax ................................................................................................ 50
Table- B 5: Class Diagram Syntax ..................................................................................................... 52
Table- B 6: Sequence Diagram Syntax .............................................................................................. 54
Table- B 7: Behavioral State Machine Diagram Syntax .................................................................... 56
Table- B 8: ERD Syntax..................................................................................................................... 66

xi
September 23, 2024
[Project Name] [Document Name] [Version]

Project Category: (Select all the major domains of proposed project)

 A-Desktop Application/Information System  B-Web Application/Web Application based Information System

 C-Problem Solving and Artificial Intelligence  D-Simulation and Modeling  E-Smartphone Application
 F-Smartphone Game  G-Networks  H-Image Processing
 Other (specify category) ________________

1 Introduction
This chapter provides the overview of the project. The first paragraph of every chapter should provide the
chapter summary.

Write a one paragraph abstract keeping in view the following guideline:

Rational: Provide the reason why you are creating the proposed software/project. [1 sentence]
Existing system: Discuss the current state of the world. [2 sentences]
Targeted challenges: Problems/opportunities the proposed project is going to resolve. [2 sentences]
Grey area: Identify the gap that will be addressed by the proposed project. [1 sentence]
Objectives: Discuss the goals that the proposed project is going to achieve. [3 sentences]
Significance of this project: Discuss the key benefits of the proposed project in terms of product. [1
sentence]

1.1 Project Background

It includes explanation of the idea behind the project. For example, if the project is related to AI then
this section describes that what is Artificial Intelligence & how it works.

1.2 Comparative Analysis

This section discusses about the existing/similar systems related to the proposed project. At least three
existing systems should be discussed. However, there might be only one or no existing system. In this
situation the related system should be discussed accordingly. Briefly explain the analysis of the related
system, which help to explicitly specify the contribution of the proposed project. You may use a single
paragraph to explain a similar (related) single system/application. However, the explanation for a
similar single system/application should not be more than 5 sentences. Note that the Research-based
projects may provide literature review instead of related system analysis. You must cite the Tables/
Figures as presented in this document. For example, Table 1 presents the related system with the
targeted project solution. This section describes current trends/ research/ products etc. related to your
project.

1
September 23, 2024
[Project Name] [Document Name] [Version]

Table 1: Related System Analysis

Application Name Weakness Proposed Project Solution

• The name of related • Weaknesses may • The way the proposed
application(s). include limited features, project mitigates the
low quality weaknesses.
functionality and
processes.
1.3 Advantages/Benefits of Proposed System
This section explicitly mentions the advantages and benefits of the proposed system. In other words,
it is required to discuss advantage of the proposed solution to the existing problem. Generally, 5-7
advantages need to be mentioned.

1.4 Project Scope

Write down the scope of the targeted project in a paragraph. Briefly define the main functionalities
of the proposed project. Scope defines the boundaries and range of the proposed solution, i.e. what
would be the part of the targeted project and what will be not. Write down in logical flow with
consistency. Usually, 14-18 sentences are enough to succinctly discuss the scope of the proposed
system.

Context diagram is widely used to define and clarify the boundaries of the software system. Therefore,
presenting a context diagram can help model the scope of the targeted project. Figure 1 depicts the
context diagram of a cafeteria ordering system.

2
September 23, 2024
[Project Name] [Document Name] [Version]

Figure 1: Context Diagram of the System

1.5 Modules
Write down the modules of the targeted project. Do not forget to mention special/new features.
Briefly explain the identified module using 6 to 8 sentences.

Note that for a group of 4 student’s project, usually 6-8 Modules are expected. Similarly, 9-11
modules are expected for a 5 student’s project.

Explanation of a Module: Module is a section of a program that performs a task. Programs consist of
modules, each of which contains one or more routines. The term routine is synonymous
with procedure, function, and subroutine.

Example:
Enterprise resource planning (ERP) software - is comprised of several large modules (for example,
finance, supply chain and payroll, etc.), which may be implemented with little or no customization.

Briefly explain each of the modules of the targeted project with respect to major functionality in a
user context.

1.5.1 Module 1: Module Name

FE-1: Order and pay for meals from the cafeteria menu to be picked up or delivered.
FE-2: Order and pay for meals from local restaurants to be delivered.

3
September 23, 2024
 [Project Name] [Document Name] [Version]

1.5.2 Module 2: Module Name

FE-1: Create, view, modify, and cancel meal subscriptions for standing or recurring meal
orders, or for daily special meals.
FE-2: Create, view, modify, delete, and archive cafeteria menus.
FE-3: View ingredient lists and nutritional information for cafeteria menu items.

1.6 System Limitations/Constraints

Write down the main limitations and constraints of the targeted project. Generally, 2-4 constraints
need to be mentioned.
Example:

LI-1: Some food items that are available from the cafeteria will not be suitable for delivery, so the
delivery menus available to Persons of the COS must be a subset of the full cafeteria menus.
LI-2: The COS shall be used only for the cafeteria at the Process Impact campus in Clackamas,
Oregon.

1.7 Tools and Technologies

Explicitly mention the hardware/software tools and technologies with version number, which will be
used in the implementation. It is also expected to mention about the APIs, language(s), SDK(s) etc.
which will be used for implementation of the targeted project. After briefly discussing the used
tools/technologies, present the information using a tabular format, as shown in the example.

Table 2: Tools and Technologies

Tools Version Rationale Paid/Free

Visual Studio Code 1.59 IDE Free
MongoDB 5.0 DBMS Free
Firebase 9.12.1 DBMS Free
Adobe Illustrator CSC 6 Design Work Free
AR Core 1.24.0 AR SDK Free
MS Project 2016 Project Management Free
MS Word 365 Documentation Free
MS Power Point 365 Presentation Free
Tools and MS Visio 2013 Diagram Creation Free
Technologies Figma 1.7 Mockups Creation Free
Technology Version Rationale Paid/Free
Python 3.9.0 Programming language Free
JavaScript 2.2.0 Programming language Free
Flutter 2.5 Framework Free
TensorFlow 2.7.0 Library Free
OpenCV 4.3.0 Library Free
Node JS 14.17.4 Runtime Environment Free
Express JS 4.17.3 Framework Free
React React 17 Library Free

4
September 23, 2024
[Project Name] [Document Name] [Version]

1.8 Team Members Individual Tasks/Work Division

Explicitly discuss the work division among the team members. Optionally, you may provide the
reasoning of the task allocation between/among the team members.

Table 3: Team Member Work Division

Student Name Student Registration Responsibility/ Modules

Number
• Student 1 Name • Registration • Describe the work division of each
Number (Student 1) student along with modules
E.g.
Mr. Ali (Module1-Module3)
Augmented reality and Database
tasks.

1.9 WBS and Gantt Chart

Create the WBS and Grant Chart and provide estimated start and end dates of all proposed modules/tasks for
each team member. Expand WBS to level 3 so each task becomes a work package.
Identify the dependencies (which tasks cannot be started/completed, until the dependent task is completed).
WBS and Gantt chart can be created using MS Project.
Example is given in Appendix A.

5
September 23, 2024
 [Project Name] [Document Name] [Version]

Table 4: WBS for software development project

ID Task Start Date End Date Duration Dependency Resources Progress %

Rita; William;
1 Analysis Mon 6/10/24 Thu 6/20/24 9d Tyler; Wenger; 88
Steve
Requirement 100
2 Mon 6/10/24 Thu 6/13/24 4d Rita; William
Meetings
Communication 2 Rita; William; 96
3 with Fri 6/14/24 Mon 6/17/24 2d Tyler; Wenger;
Stakeholders Steve
Document 3 100
4 Tue 6/18/24 Wed 6/19/24 2d William
Current System
Analysis 4 0
5 Thu 6/20/24 Thu 6/20/24 1d
Finished

6 Design Fri 6/21/24 Mon 7/22/24 22 d Steve; Yvette; Zoe 14

7 Design Database Fri 6/21/24 Thu 6/27/24 5d 5 Steve 62

8 Software Design Fri 6/28/24 Fri 7/5/24 6d 7 Yvette 0
9 Interface Design Mon 7/8/24 Wed 7/10/24 3d 8 Zoe 0
Create Design 9 0
10 Thu 7/11/24 Fri 7/19/24 7d Steve
Specifications
11 Design Finished Mon 7/22/24 Mon 7/22/24 1d 10 21

12 Development Tue 7/23/24 Thu 8/22/24 23 d Tyler; Wenger 21

Develop System 11 41
13 Tue 7/23/24 Wed 8/7/24 12 d Tyler; Wenger
Module
Integrate System 13 0
14 Thu 8/8/24 Fri 8/16/24 7d Tyler
Module
Perform Initial 14 0
15 Mon 8/19/24 Wed 8/21/24 3d Wenger
Testing
Development 14 0
16 Thu 8/22/24 Thu 8/22/24 1d
Finished

17 Testing Fri 8/23/24 Thu 9/12/24 15 d Vicky; Mike 28

Perform System 16 63
18 Fri 8/23/24 Tue 9/3/24 8d Vicky
Testing
Document Issues 18 0
19 Wed 9/4/24 Fri 9/6/24 6d Mike
Found
Correct Issues 18 0
20 Wed 9/4/24 Wed 9/11/24 3d Mike
Found
21 Testing Finished Thu 9/12/24 Thu 9/12/24 1d 20 0

22 Implementation Fri 9/13/24 Fri 10/4/24 16 d Tyler; Mike 0

On-Site 21 0
23 Fri 9/13/24 Fri 9/13/24 1d Tyler
Installation

6
September 23, 2024
 [Project Name] [Document Name] [Version]

ID Task Start Date End Date Duration Dependency Resources Progress %

Support Plan for 23 0

24 Mon 9/16/24 Fri 10/4/24 15 d Mike
the System
25 Completion Mon 10/7/24 Thu 10/17/24 9d Rita; William 0
System 24 0
26 Mon 10/7/24 Thu 10/17/24 9d Rita
Maintenance
27 Evaluation Mon 10/7/24 Thu 10/17/24 9d 24 William 0

1.9.1 WBS with Gantt Chart

Figure 2: WBS with Gantt Chart

1.10 Cost of Project

Calculate the cost of the entire project, including the estimated cost of all possible tasks for each
module. You can use any technique COCOMO, FP, Expert Judgement, Pert Analysis, Analogous
technique. You are expected to mention the overall project cost including the names of the modules
in a paragraph. Additionally, explain the budget release timeline if possible.

Example is given in Appendix A.

7
September 23, 2024
[Project Name] [Document Name] [Version]

2 Problem Definition
This chapter discusses the specific problem to be solved and should also elaborate on the expected
outcome.

2.1 Problem Statement

Problem statement goes here. This is core section of the scope document. It mainly focuses on
identifying the core targeted problem that drives the development of the project. The Capston-1
student may focus on the following questions to write an effective problem:
• What problem does the proposed system solve?
• Why you are developing this system?
• Does the same system already exist? If yes, how will a re-implementation aid your learning?
• What skills do you expect to learn from this project?

It is suggested to check it online that how to write a quality problem statement. At the same time,
students may consult the previous FYP final reports to refine their problem statement.
Example:

Employees at the company Process Impact presently spend an average of 65 minutes per day going to the
cafeteria to select, purchase, and eat lunch. About 20 minutes of this time is spent walking to and from the
cafeteria, selecting their meals, and paying by cash or credit card. When employees go out for lunch, they
spend an average of 90 minutes off-site. Some employees phone the cafeteria in advance to order a meal to be
ready for them to pick up. Employees don‘t always pet the selections they want because the cafeteria runs out
of certain items. The cafeteria wastes a significant quantity of food that is not purchased and must be thrown
away. These same issues apply to breakfast and supper, although far fewer employees use the cafeteria for
those meals than for lunch.

2.2 Proposed Solution

Briefly explain how your proposed system solves the problems as mentioned in the Problem
Statement. Maybe, the proposed system provides a more cost-effective solution than the existing
systems. Therefore, it is required to explicitly mention the logic of the proposed system, which
provides additional benefits in contrast to the existing systems. The problem solution can be usually
described in 14-16 sentences.
Example:

8
September 23, 2024
[Project Name] [Document Name] [Version]

Many employees have requested a system that would permit a cafeteria user to order meals (defined as a set
of one or more food items selected from the cafeteria menu) online, to be picked up at the cafeteria or delivered
to a company location at a specified time and date. Such a system would save employees time, and it would
increase their chance of getting the items they prefer. Knowing what food items customers want in advance
would reduce waste in the cafeteria and would improve the efficiency of cafeteria staff. The future ability for
employees to order meals for delivery from local restaurants would make a wide range of choices available to
employees and provide the possibility of cost savings through volume discount agreements with the
restaurants.

Objectives
Example:
BO-1: Reduce the cost of cafeteria food wastage by 40%.
BO-2: Reduce cafeteria operating costs by 15%.
BO-3: Increase average effective work time by 15 minutes per cafeteria-using employee per day.

2.3 Current System (if applicable to your project)

A brief description of an existing system, along with pictures of existing system and modules.

The following figure is a sample figure of existing system, Figure 3

Figure 3: Current System

Table 5: List of modules in current system

Name of Modules Sub Module Sub Module

Text Text Text

9
September 23, 2024
[Project Name] [Document Name] [Version]

3 Requirement Analysis
The following parts of Software Requirements Specification (SRS) report should be included in this
chapter.

3.1 Requirement Elicitation Techniques

Write down the techniques you have selected for requirement gathering approach along with reasons.
Commonly used techniques are: Brainstorming, Document Analysis, Focus Groups, Interface Analysis,
Interviews, Observation, Prototyping, and Requirements Workshops.

3.2 Use Cases Diagram(s)

Create Use Case Diagrams of your system.
Create diagrams as per actor Role.
Create Use Case Diagram Using MS VISIO as per UML standard notations

A use case describes a sequence of actions a system performs that yields an observable result of
value to an actor.

(System) Use case diagrams are used to specify:

• (external) requirements, required usages of a system under design or analysis (subject) -
to capture what the system is supposed to do;
• the functionality offered by a subject – what the system can do;
• Requirements the specified subject poses on its environment - by defining how
environment should interact with the subject so that it will be able to perform its services.

Major elements of the UML use case diagram are shown on the picture below.

10
September 23, 2024
[Project Name] [Document Name] [Version]

Figure 4: Use Case Diagram

To view detail of all above notations, see Appendix B

3.3 Detailed Use Case (Tabular- Module Wise)
This section of the SRS should contain all the details that the software developer needs to create a
design. This is typically the largest and most important part of the SRS. This section contains an
overview of the use-case model or the subset of the use-case model that is applicable for this
subsystem or feature. This includes a list of names and brief descriptions of all use cases and
actors, along with their applicable relationships.

3.3.1 Use Case Name

Table 6: Show the detail use case template and example

Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1
Use Case Name: Enter a short name for the Use Case using an active verb phrase. e.g.
Order a Meal
Actors: [An actor is a person or other entity external to the software system being specified
who interacts with the system and performs use cases to accomplish tasks.] e.g.
Primary Actor: Person Secondary Actors: Cafeteria Inventory System
Description: [Provide a brief description of the reason for and outcome of this use case.] e.g.
A Person accesses the Cafeteria Ordering System from either the corporate intranet
or external Internet, views the menu for a specific date, selects food items, and
places an order for a meal to be picked up in the cafeteria or delivered to a specified
location within a specified 15-minute time window.
Trigger: [Identify the event that initiates the use case.]e.g.
A person indicates that he wants to order a meal.
11
September 23, 2024
[Project Name] [Document Name] [Version]

Level: Enter Use Case Goal Level here: High/Medium/Low

Preconditions: [List any activities that must take place, or any conditions that must be true before
the use case can be started.
PRE-1. Person is logged into COS.
PRE-2. Person is registered for meal payments by payroll deduction.
Post conditions: [Describe the state of the system at the conclusion of the use case execution.
POST-1. Meal order is stored in COS with a status of “Accepted.”
POST-2. Inventory of available food items is updated to reflect items in this order.
POST-3. Remaining delivery capacity for the requested time window is updated.
Normal Flow: [Provide a detailed description of the user actions and system responses that will
take place during execution of the use case under normal, expected conditions.
1.0 Order a Single Meal
1. Person asks to view menu for a specific date. (refer 1.0. E1, 1.0.E2)
2. COS displays menu of available food items and the daily special.
3. Person selects one or more food items from menu. (refer 1.1)
4. Person indicates that meal order is complete. (refer 1.2)
5. COS displays ordered menu items, individual prices, and total price, including
taxes and delivery charge.
6. Person either confirms meal order (continue normal flow) or requests to modify
meal order (return to step 2).
7. COS displays available delivery times for the delivery date.
8. Person selects a delivery time and specifies the delivery location.
9. Person specifies payment method.
10. COS confirms acceptance of the order.
11. COS sends Person an email message confirming order details, price, and
delivery instructions.
12. COS stores order, sends food item information to Cafeteria Inventory System,
and updates available delivery times.
Alternative [Document legitimate branches from the main flow to handle special conditions
Flows: (also known as extensions). For each alternative flow reference the branching step
number of the normal flow and the condition which must be true for this extension
to be executed. e.g.
1.1 Order multiple identical meals
1. Person requests a specified number of identical meals. (refer 1.1. E1)
2. Return to step 4 of normal flow.
1.2 Order multiple meals
1. Person asks to order another meal.
2. Return to step 1 of normal flow.
Note: Insert a new row for each distinctive alternative flow. ]
Exceptions: 1.0. E1 Requested date is today and current time is after today’s order cutoff time
1. COS informs Person that it’s too late to place an order for today.
2a. If Person cancels the meal ordering process, then COS terminates use case.
2b. Else if Person requests another date, then COS restarts use case.
1.0. E2 No delivery times left
1. COS informs Person that no delivery times are available for the meal date.

12
September 23, 2024
[Project Name] [Document Name] [Version]

2a. If Person cancels the meal ordering process, then COS terminates use case.
2b. Else if Person requests to pick the order up at the cafeteria, then continue with
normal flow, but skip steps 7 and 8.
1.1. E1 Insufficient inventory to fulfill multiple meal order
1. COS informs Person of the maximum number of identical meals he can order
based on current available inventory.
2a. If Person modifies number of meals ordered, then return to step 4 of normal
flow.
2b. Else if Person cancels the meal ordering process, then COS terminates use case.
Business Rules Use cases and business rules are intertwined. Some business rules constrain which
roles can perform all or parts of a use case. Perhaps only users who have certain
privilege levels can perform specific alternative flows. That is, the rule might
impose preconditions that the system must test before letting the user proceed.
Business rules can influence specific steps in the normal flow by defining valid input
values or dictating how computations are to be performed e.g.
BR-1 Delivery time windows are 15 minutes, beginning on each quarter hour.
BR-2 Deliveries must be completed between 11:00 A.M. and 2:00 P.M. local time,
inclusive.

Note: If you are maintaining the business rule in a separate table in SRS then only
mention their IDs here.
Assumptions: [List any assumptions.
1. e.g. Assume that 15 percent of Persons will order the daily special (Source:
previous 6 months of cafeteria data).

Write all the use cases as per given tabular format w.r.t each module

3.4 Functional Requirements (Tabular FR- Module Wise)

Itemize the specific functional requirements associated with each feature. These are the software
capabilities that must be implemented for the user to carry out the feature’s services or to perform a
use case. Describe how the product should respond to anticipated error conditions and to invalid
inputs and actions. Uniquely label each functional requirement, as described earlier. You can create
multiple attributes for each functional requirement, such as rationale, source, dependencies, etc. The
following template is required to write functional requirements.

3.4.1 Functional Requirement One

Table 7: Description of FR-1

Identifier FR-1
Title Title of requirement
Requirement Description of requirement which may be written either from the user or
system perspective e.g.

13
September 23, 2024
[Project Name] [Document Name] [Version]

If written in a user perspective

The [user class or actor name] shall be able to [do something] [to some
object] [qualifying conditions, response time, or quality statement].
If written in a system perspective
[optional precondition] [optional trigger event] the system shall [expected
system response]
Source Where this requirement comes from (who originate it)
Rationale The motivation behind the requirement
Business Rule Any restriction, policy, or rule that the particular requirement must fulfil
(if required) through this functional behavior
Dependencies Requirements ID that is dependent on this requirement
Priority High/Medium/Low

3.5 Non-Functional Requirements

This section specifies nonfunctional requirements other than constraints, and external interface
requirements, which will appear in section 3.6. These quality requirements should be specific,
quantitative, and verifiable. The following are some examples of documentation guidelines.
Write down all non-functional requirements which will be applicable to your proposed system and
that which will be used for project development. Also quantify these non-functional requirements
properly.
(Usually in 3-5 sentences)

3.5.1 Reliability
These cover requirements about how often the software fails. The measurement is often expressed in
MTBF (mean time between failures). The definition of a failure must be clear. Also, don't confuse
reliability with availability which is a different kind of requirement. Be sure to specify the
consequences of software failure, how to protect from failure, a strategy for error detection, and a
strategy for correction.

3.5.2 Usability
Usability requirements deal with ease of learning, ease of use, error avoidance and recovery, the
efficiency of interactions, and accessibility. The usability requirements specified here will help the
user interface designer create the optimal user experience.
Example:

USE-1: The COS shall allow a user to retrieve the previous meal ordered with a single interaction.

14
September 23, 2024
[Project Name] [Document Name] [Version]

3.5.3 Performance
State specific performance requirements for various system operations. If different functional
requirements or features have different performance requirements, it’s appropriate to specify those
performance goals right with the corresponding functional requirements, rather than collecting them
in this section.
Example:

PER-1: 95% of webpages generated by the COS shall download completely within 4 seconds from
the time the user requests the page over a 20 Mbps or faster Internet connection.

3.5.4 Security
There should be one or more requirements about protection of your system and its data. The
measurement can be expressed in a variety of ways (effort, skill level, time, ...) to break into the
system. Do not discuss solutions (e.g. passwords) in a requirements document.

3.5.5 Supportability
Supportability refers to the ease with which a system can be maintained, repaired, and supported over
its operational life.

Example:

SUR-1: The system shall achieve an average response time of less than 2 seconds under peak load
conditions.

3.6 External Interface Requirements

This section provides information to ensure that the system will communicate properly with users and
with external hardware or software elements. A complex system with multiple subcomponents should
create a separate interface specification or system architecture specification. The interface
documentation could incorporate material from other documents by reference. For instance, it could
refer to a hardware device manual that lists the error codes the device could send to the software.

3.6.1 User Interface Requirements

Describe the logical characteristics of each user interface that the system needs. Some possible items
to include are:
• References to GUI standards or product family style guides that are to be followed.
• Standards for fonts, icons, button labels, images, color schemes, field tabbing sequences,
and commonly used controls.

15
September 23, 2024
[Project Name] [Document Name] [Version]

• Screen layout or resolution constraints.

• Standard buttons, functions, or navigation links that will appear on every screen, such as a
help button.
• Shortcut keys.
• Message display conventions.
• Layout standards to facilitate software localization.
• Accommodations for visually impaired users.

Document the user interface design details, such as specific dialog box layouts, in a separate user
interface specification, not in the SRS. Including screen mock-ups in the SRS to convey an additional
perspective of the requirements is helpful, but ensure it's clear that the mock-ups do not represent
finalized screen designs. If the SRS specifies enhancements to an existing system, it may be practical
to include screen displays exactly as they are to be implemented. Developers are already constrained
by the current reality of the existing system, making it possible to determine upfront what the
modified, and possibly new, screens should look like.

3.6.2 Software Interface

Describe the connections between this product and other software components (identified by name
and version), including other applications, databases, operating systems, tools, libraries, websites, and
integrated commercial components (If any).
Example:
SI-1.1: The COS shall transmit the quantities of food items ordered to the Cafeteria Inventory System
through a programmatic interface. (Plugin/API)

3.6.3 Hardware Interfaces

Describe the characteristics of each interface between the software components and hardware
components, if applicable, of the system. This description might include the supported device types,
the data and control interactions between the software and the hardware, and the communication
protocols to be used. “Embedded and other real-time systems projects.”

3.6.4 Communication Interfaces

State the requirements for any communication functions the product will use, including email, web
browser, network protocols, and electronic forms.

Example:

CI-1: The COS shall send an email or text message (based on user account settings) to the Person
to confirm acceptance of an order, price, and delivery instructions.

16
September 23, 2024
[Project Name] [Document Name] [Version]

4 Architecture and Design

The following parts of Software Design Description (SDD) report should be included in this chapter.

4.1 System Architecture

Develop a modular program structure and explain the relationships between the modules
to achieve the complete functionality of the system. This is a high-level overview of how the system’s
modules collaborate with each other to achieve the desired functionality.

Don’t go into too much detail about the individual subsystems. The main purpose is to gain
a general understanding of how and why the system was decomposed, and how the individual parts
work together.

Provide a diagram showing the major subsystems and their connections.

• In initial design stage create Box and Line Diagram for simpler representation of the
systems
• After finalizing architecture style/pattern diagram (MVC, Client-Server, Layered,
Multi-tiered) create a detailed mapping modules/components to each part of the
architecture

4.2 Design Methodology

Explain and justify the choice of design methodology being followed. (OOP or procedural).

4.3 Data Representation [Diagram + Description] (ERD, JSON SCHEMA)

• ERD with description (Database conceptual schema)
• JSON schema of developed Modules storage.

4.4 Design Models [along with descriptions]

Create design models as are applicable to your system. Provide detailed descriptions with each
of the models that you add. Also ensure visibility of all diagrams.

Design Models for Object Oriented Development Approach

The applicable models for the project using object-oriented development approach may include:

• Activity Diagram (Total 10 to 12 Diagrams based on use cases, considering 1-2 diagrams
from each module major use cases, best is to create for all use cases)
• Class Diagram (Total 1 class diagram for overall system)

17
September 23, 2024
[Project Name] [Document Name] [Version]

• Sequence Diagram (Total 10 to 12 Diagrams, considering 1-2 diagrams from each

module, best is to create for all use cases)
• State Transition Diagram (for the projects which include event handling and back-end
processes)
• Sketches of Models, Terrain(Map) (for the projects which include 3D/2D models and/or
ground maps)
• Animation Sketches (for the projects which include 3D/2D models)
To view examples of all above models, see Appendix B

Design Models for Procedural Approach

The applicable models for the project using procedural approach may include:

• Activity Diagram
• Data Flow Diagram (data flow diagram should be extended to 2-3 levels. It should clearly
list all processes, their sources/Links, and data stores.)
• State Transition Diagram (for the projects which include event handling and backend
processes)

To view examples of all above models, see Appendix B

5 Human Interface Design

Describe the functionality of the system from the user’s perspective. Explain how the user will
be able to use your system to complete all the expected features and the feedback information
that will be displayed to the user.

5.1 Screen Images

Insert minimum mockups (Usually 10-15 mockups) which show the major modules mentioned in the
scope section of the document. Do not include mockups for Login, Signup, Forgot Password, Contact
Us, About Us etc. If the project is a Web or a Smartphone Application, then include at-least ten
mockups from each part of the project.
Each mockup must give explanation about the screen.

NOTE: You can design mockup in any design tool for example pencil tool
(https://pencil.evolus.vn/) or Balsamiq (https://balsamiq.com/)
To view examples of all above models, see Appendix B

18
September 23, 2024
[Project Name] [Document Name] [Version]

5.2 Models and Animations

• Models, Terrain(Map) (for the projects which include 3D/2D models and earth maps)
• Animation (for the projects which include 3D/2D models)

5.3 Screen Objects and Actions

A discussion of screen objects and actions associated with those objects
To view examples of all above models, see Appendix B

19
September 23, 2024
[Project Name] [Document Name] [Version]

6 Implementation
This chapter will discuss implementation details supported by UML diagrams (if applicable). You
will not put your source code here. Any of the following sections may be included based on your
project.

6.1 User Interface/ Front End

Display screenshots showing the interface from the user’s perspective. These images should be the
complete front end of your project also add a video link of your system/product have complete demo
to be accessible by the reader.

6.2 Brief Overview of the Proposed System

Mention the algorithm(s) used in your project to complete the work across major modules. Provide
pseudocode OR a natural language explanation regarding the functioning of the main features. Ensure
correct syntax and semantics for algorithm representations. Include information on the dataset used,
along with references and links.

6.3 External APIs

Students often leverage various external APIs to enhance their applications and provide additional
functionalities. These APIs can be categorized based on their functionality and use case.
Describe the APIs used in the Table 8.
o Mapping and Geolocation APIs
o Google Maps API: Used for integrating maps, geolocation, route planning, and places
data into applications.
o OpenStreetMap API: An open-source alternative to Google Maps for embedding
maps and location data.
o Social Media APIs
o Facebook Graph API: Enables integration with Facebook, allowing applications to
post on behalf of users, access user data, and interact with Facebook services.
o Twitter API: Used for accessing and interacting with Twitter data, such as posting
tweets, reading timelines, and searching for tweets.
o Payment APIs
o JazzCash API: Facilitates online payments, allowing applications to process
transactions securely.
o Stripe API: Another popular payment processing API that supports various payment
methods and currencies.
o Weather APIs
o OpenWeatherMap API: Provides current weather data, forecasts, and historical data.
o Weatherstack API: Offers real-time weather information and weather forecasts.
o Machine Learning and AI APIs
o Google Cloud Vision API: Enables image recognition capabilities, including object
detection, label detection, and text extraction from images.
o IBM Watson API: Provides various AI services such as natural language processing,
visual recognition, and speech-to-text.

20
September 23, 2024
[Project Name] [Document Name] [Version]

o Cloud Storage and Database APIs

o Firebase Realtime Database API: A NoSQL cloud database for storing and syncing
data in real-time across all clients.
o Authentication and Authorization APIs.
o OAuth 2.0: A protocol used for authorization, commonly implemented with services
like Google, Facebook, and GitHub to allow users to log in using their existing
accounts.

Table 8: Details of APIs used in the project

Name of Description of Purpose of List down the function/class Free/Open
API API usage name in which it is used source/Paid
Google Used for To download Class Satellite_Images Paid
Maps API integrating maps, satellite
geolocation, images
route planning,
and places data
into applications.

7 Testing and Evaluation

This chapter may include the following sections. (Students are required to perform the testing both
manually and automatically).

7.1 Test Plan

Specify the purpose of this Test Plan. Describe the scope of the product that is covered by this Test
Plan, particularly if this Test Pan describes only part of the system or a single subsystem.
(Usually in 1-2 paragraphs describing the purpose of this document as explained above)

7.2 Product Scope

Write down the scope of your project in a paragraph. Briefly define the main functionalities of the
proposed project.
This subsection should:
1.2.1. Provide a brief description of the software system to be produced by name along with its
purpose, For example, Host DBMS, Report Generator, etc
1.2.2. Explain what the software product(s) will, the feature or other subsystem grouping and, if
necessary, will not do
1.2.3. Describe the application of the software being specified. As a portion of this, it should:
a) Describe all relevant benefits, objectives, and goals as precisely as possible. For example, to
say that one goal is to provide effective reporting capabilities is not as good as saying parameter-
driven, user-definable reports with a 2h turnaround and on-line entry of user parameters.

21
September 23, 2024
[Project Name] [Document Name] [Version]

b) Be consistent with similar statements in higher-level specifications (For example, the

System Requirement Specification), if they exist.
(Usually in 1-2 paragraphs describing the scope of the product. Make sure to describe the benefits
associated with the product.)

7.3 Intended Audience

Describe the different types of reader that the document is intended for, such as developers, project
managers, marketing staff, users, testers, and documentation writers (In your case it would probably
be the “client” and the professor, project committee members.
(Usually in 1 paragraph.)

7.4 Definitions, Acronyms and Abbreviations

This subsection should provide the definitions of all terms, acronyms, and abbreviations required to
properly interpret the Test Plan. This information may be provided by reference to the project
Glossary. Please provide a list of all abbreviations and acronyms used in this document sorted in
alphabetical order.

7.5 Test Pass/ Fail Criteria

What is the Completion criteria for this plan? This is a critical aspect of any test plan and should be
appropriate to the level of the plan. The goal is to identify whether a test item has passed the test
process.
• At the Unit test level this could be items such as:
o All test cases completed.
▪ A specified percentage of cases completed with a percentage containing some
number of minor defects.
• Code coverage tool indicates all codes are covered.

• At the Master test plan level this could be items such as:
▪ All lower level plans completed.
• A specified number of plans completed without errors and a
percentage with minor defects.
o This could be an individual test case level criterion or a unit level plan or it can be
general functional requirements for higher level plans.
o What is the number and severity of defects located?
o Is it possible to compare this to the total number of defects? This may be impossible,
as some defects are never detected.
o A defect is something that may cause a failure, and may be acceptable to leave in the
application.
o A failure is the result of a defect as seen by the User, the system crashes, etc.

22
September 23, 2024
[Project Name] [Document Name] [Version]

7.6 Verification
Verification evaluates software artifacts (such as requirements, design, code, etc.) to ensure
they meet the specified requirements and standards. It ensures the software is built according
to the needs and design specifications.

7.7 Validation
Validation evaluates software to meet the user’s needs and requirements. It ensures the software
fits its intended purpose and meets the user’s expectations.

7.8 Usability Testing

This type of testing assesses the ease of use of an application. Usability testing may be
accomplished in a variety of ways, including direct observation of people using web
applications, usability surveys, and beta tests. The main objective of usability testing is to
ensure that an application is easy to understand and navigate by the user. Add video link of your
useability testing or report of your useability surveys.

7.9 Module / Unit Testing

This includes testing at the object, component, page, or applet level. Unit testing is the lowest
level of testing in terms of detail. During unit testing, the structure of languages, such as HTML
and Java, can be verified. Edits and calculations can also be tested at the unit level.

7.10 Integration Testing

Integration is the passing of data and/or control between units or components, which includes
testing navigation (i.e., the paths the test data will follow). In web-based applications, this
includes testing links, data exchanges, and flow of control in an application.
7.11 System Testing
System testing examines the web application as a whole and with other systems. The classic
definition of system testing is that it validates that a computing system functions according
to written requirements and specifications. This is also true in web-based applications. The
difference apply in how the system is defined. System testing typically includes hardware,
software, data, procedures, and people.
In corporate web-based applications, a system might interface with Internet web pages, data
warehouses, back-end processing systems, and reporting systems.

7.12 Acceptance Testing

This includes testing that the web application supports business needs and processes. The
main idea in user acceptance testing (or business process validation) is to ensure that the end
product supports the users’ needs. For business applications, this means testing that the system
allows the user to conduct business correctly and efficiently. For personal applications, this
means that users are able to get the information or service they need from a web site efficiently.

23
September 23, 2024
[Project Name] [Document Name] [Version]

In a corporate web page, the end-user testers may be from end-user groups, management, or an
independent test team that takes the role of end users. In public web applications, the end-user
testers may be beta testers, who receive a prototype or early release of the new web application,
or independent testers who take the role of public web users.

7.13 Manual Testing

Manual testing is a software testing approach where testers manually evaluate software or
application quality without the help of automated testing tools or test scripts. Testers interact
with the system like how an end user would to identify bugs, defects, and issues in the software
that create friction in user experience.

When a developer manually runs their application and tries out the features they have coded,
they are doing manual testing. Its simplicity makes manual testing great for small-scale testing
of personal projects. Even for large-scale testing where there are thousands and millions of
items and features to test, manual testing is still needed to some degree.

.
7.14 Test Cases

Write the test cases of your project as per module wise. A sample test cases with format is mentioned.

Table 9: Test Case Template (Module)

Test Id: TC-01 Test Case Designed Shamim
by:
Test Case Title: Open Alphabets image Test Case Executed Ali
slider by:
Module Name: Teaching Pakistani sign Test Case Execution 13-11-2019
language (PSL). Date:
Test Data: Text and Images of Priority: High
alphabets in PSL
Precondition: System has images of alphabets of PSL.
Steps /Action System Response

1. Click on SLV .apk 1. System start working

2. System display “Home” Screen 2. System display “Home” screen successfully
3. Click on “Navigation Menu” 3. System display “Navigation Menu”
4. Click on “Learning Mode” successfully
5. Click on “Learning Alphabets” 4. System display “Learning Mode” screen
6. Click on “Learning Alphabets by images” successfully
5. System display “Learning Alphabets” screen
successfully
6. System will load and display PSL alphabets
image slider successfully.

24
September 23, 2024
[Project Name] [Document Name] [Version]

Expected Result: After execution, SLV should load text along with
images of PSL alphabets and display image slider.
Actual Result: After execution, SLV has loaded text along with
images of PSL alphabets and displayed image
slider.
Status: Pass

7.14.1 Unit Testing (Test Cases)

Unit Testing 1: Login as FYP Committee

Testing Objective: To ensure the login form is working correctly

Table 10: Test Case Template (Unit 1)

No. Test case/Test script Attribute and value Expected result Result

1. Verify user login after Username: Successfully log Pass

click on the ‘Login’ L001 into the main page
button on login form with Password: of the system as
correct input data 1234 FYP Committee
member.

2.

Unit Testing 2: Edit Profile

Testing Objective: To ensure the edit profile form is working properly.

Table 11: Test Case Template (Unit 2)

No. Test case/Test script Attribute and value Expected result Result

1.
2.

7.14.2 Functional Testing

The functional testing will take place after the unit testing. In this functional testing, the functionality
of each of the module is tested. This is to ensure that the system produced meets the specifications
and requirements.

Functional Testing 1: Login with different roles

25
September 23, 2024
[Project Name] [Document Name] [Version]

Objective: To ensure that the correct page with the correct navigation bar is loaded.

Table 12: Test Case Template (Functional)

No. Test case/Test script Attribute and value Expected result Result

1. Login as a ‘FYP Username: L001 Main page for the Pass

Committee’ member. Password: 1234 FYP Committee
member is loaded
with the FYP
Committee
navigation bar

2.

7.14.3 Integration Testing

Table 13: Test Case Template (Integration)

No. Test case/Test script Attribute and Expected result Result

value

1. Login as “FYP Username: L001 Login successful Pass

Committee” member Password: 1234 and the FYP
Committee page
with its navigation
bar is loaded and in
the view profile
page

2. Upload student record for - File successfully Pass

Project 1 uploaded and
returned to the
upload page.
Student records are
updated.

3. View supervising student - The list of Pass

supervisees shown
on the screen.

26
September 23, 2024
[Project Name] [Document Name] [Version]

7.14.4 Automated Testing

7.14.4.1 Tools Used

Table 14: Automated Testing

Tool Name Tool Description Applied on [list of Results

related test cases / FR /
NFR]
Selenium Selenium is an open- FR-01, FR-02, NFR-01 Pass
source, automated
testing tool used to test
web applications across
various browsers.
Selenium can only test
web applications,
unfortunately, so
desktop and mobile apps
can't be tested.

7.15 Environmental Needs

Are there any special requirements for this test plan, such as:
• Special hardware such as simulators, static generators etc.
• How will test data be provided? Are there special collection requirements or specific ranges of
data that must be provided.
• How much testing will be done on each component of a multi-part feature?
• Special power requirements.
• Specific versions of other supporting software.
• Restricted use of the system during testing.
• Tools (both purchased and created).
• Communications
o Web
o Client/Server
o Network
▪ Topology
▪ External
▪ Internal
▪ Bridges/Routers
• Security

7.16 Responsibilities
Who is in charge? There should be a responsible person for each aspect of the testing and the test
process. Each test task identified should also have a responsible person assigned.

27
September 23, 2024
[Project Name] [Document Name] [Version]

8 Requirement Traceability Matric

RTM consists of all the features of the codes and is traced against the measures that require testing.
Once this is developed it is maintained throughout the testing phase until the completed code goes to
release and gets deployed in production. It can be developed using Microsoft Excel.
(Note: See Appendix B for detailed example.)

28
September 23, 2024
[Project Name] [Document Name] [Version]

9 Conclusion and Future Work

This chapter concludes the project and highlights future work.

9.1 Conclusion
Conclude this document.
(Usually 4-5 sentences)

Example “To conclude we can say Smart Diabetolog application helps diabetes patient
maintain their lifestyle in a balanced way by tracking their health factors and providing customized
diet and exercise plans. It also maintains their medication and allergic reaction history to make the
plans more efficient and customizable. It also keeps a check on diabetes patient eyes disease by
checking his fundus images for retinopathy. Moreover, it also provides awareness to patients about
diabetes, so, we can say that our application Smart Diabetolog is a full package for maintaining a
diabetes patients lifestyle.”

9.2 Future Work

Possible future of the project.
(Usually 4-5 sentences)
Example “In future work we can scrape more websites for recipes and exercises to make our
system more efficient and can also train our systems with better and new datasets. In this way we can
also enhance our system accuracy and efficiency.”

29
September 23, 2024
[Project Name] [Document Name] [Version]

10 Work Summary and Reviews

10.1 Lesson Learnt

• Write all lessons that your learnt while doing this semester project
• Write both aspects Technical and Non-Technical.
• Each Group Member write its own lesson learn as well.

Table 15: Lesson Learnt for the course project

Lesson Learned
Student 1 Name:
Student 1 Registration Number:

Student 2 Name:
Student 2 Registration Number:

10.2 Work Break Down

Table 16: Work Break down of individual Student for each milestone
Milestones Student 1 Name Student 1 Student 2 Name
Registration Number Student 2 Registration Number
1- SCOPE Document and .
SCOPE presentation
2- SRS Document and
SRS Presentation
3- SDS Document and
SDS Presentation
4- Project Design (Figma
and Implementation)
5- Project Test Plan and
Presentation
6- Project Final Report
and Presentation

30
September 23, 2024
[Project Name] [Document Name] [Version]

10.3 Reviews Details

Review Given By: Write group number
Table 17: Reviewer Comments
Milestones Reviewer -1 Comments Reviewer -2- Comments
(Student-1 name and details) (Student-2 name and details)
1- SCOPE Document and .
SCOPE presentation
2- SRS Document and
SRS Presentation
3- SDS Document and
SDS Presentation
4- Project Design (Figma
and Implementation)
5- Project Test Plan and
Presentation
6- Project Final Report
and Presentation
Feedback and Acceptance status of Reviewer Comments

31
September 23, 2024
[Project Name] [Document Name] [Version]

11 References
Mention the books, research papers, web links etc. (Usually 3-5 References)
Mention the books, research papers, web links by following given guideline.

Book
Author(s). Book title. Location: publishing Company, year, pp.
Example:
W.K. Chen. Linear Networks and Systems. Belmont, CA: Wadsworth, 1993, pp. 123-35.

Article in a Journal
Author(s). “Article title”. Journal title, vol., pp, date.
Example:
G. Pevere. “Infrared Nation.” The International Journal of Infrared Design, vol. 33, pp. 56-99, Jan. 1979.

Articles from Conference Proceedings (published)

Author(s). “Article title.” Conference proceedings, year, pp.
Example:
D.B. Payne and H.G. Gunhold. “Digital sundials and broadband technology,” in Proc. IOOC-ECOC, 1986,
pp. 557-998.

World Wide Web

Author(s)*. “Title.” Internet: complete URL, date updated* [date accessed].
M. Duncan. “Engineering Concepts on Ice. Internet: www.iceengg.edu/staff.html, Oct. 25, 2000 [Nov. 29,
2003].

• How to design using UML (OOP): For guidance please follow the instructions mentioned in
the link: http://agilemodeling.com/artifacts/

• How and when to design ER diagrams: For guidance please follow the instructions mentioned
in the link:
http://people.inf.elte.hu/nikovits/DB2/Ullman_The_Complete_Book.pdf

• Data flow diagrams: For guidance please follow the instructions mentioned in the link and
book:
o http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
o Software Engineering –A Practitioner’s approach by Roger Pressman
• Architecture diagram: For guidance please follow the instructions mentioned in the link and
book:
o Ian Sommerville – Software Engineering 9th Edition– Chapter 6
• Software Testing
o https://dahlan.unimal.ac.id/files/ebooks/2006%20[William_E._Perry]_Effective_Met
hods_for_Software_SANGAT_BAGUS.pdf
o Effective Methods for Software Testing Third Edition

32
September 23, 2024
[Project Name] [Document Name] [Version]

12 Plagiarism Report
Attach the Plagiarism report of your project requirement document from library staff of Turnitin
tool (http://turnitin.com) (Research Based projects only)

33
September 23, 2024
[Project Name] [Document Name] [Version]

13 Appendix A

13.1 WBS and Gantt chart:

A Work Breakdown Structure is a method of organizing and completing work in a project. With each
increasing level, more details are added. Basic structure is given in Figure A- 1, while detailed
example is provided in Table A- 1.

Figure A- 1: Basic Structure of WBS

34
September 23, 2024
[Project Name] [Document Name] [Version]

Table A- 1:Example of a WBS for software development project

ID Task Duration Resources
1 Analysis 8d Rita; William; Tyler; Wenger
2 Requirement Meetings 4d Rita; William
3 Communication with Stakeholders 2d Rita; William
4 Document Current System 2d William
5 Analysis Finished 1d Tyler
6 Design 18 d Steve; Yvette; Zoe
7 Design Database 5d Steve
8 Software Design 6d Yvette
9 Interface Design 3d Zoe
10 Create Design Specifications 7d Steve
11 Design Finished 1d Zoe
12 Development 22 d Tyler; Wenger
13 Develop System Module 12 d Tyler; Wenger
14 Integrate System Module 7d Tyler
15 Perform Initial Testing 3d Wenger
16 Development Finished 1d Tyler
17 Testing 17 d Vicky; Mike
18 Perform System Testing 8d Vicky
19 Document Issues Found 6d Mike
20 Correct Issues Found 3d Mike
21 Testing Finished 1d Vicky
22 Implementation 15 d Tyler; Mike
23 On-Site Installation 1d Tyler
24 Support Plan for the System 15 d Mike
25 Completion 9d Rita; William
26 System Maintenance 9d Rita
27 Evaluation 9d William

35
September 23, 2024
 [Project Name] [Document Name] [Version]

13.2 Cost of project with WBS

Table A- 2: WBS with work progress

Resource % Work
Task Name Duration Start Finish Predecessors
Names Complete
Analysis 9 days Mon 6/10/24 Thu 6/20/24 88%
Requirement Meetings 4 days Mon 6/10/24 Thu 6/13/24 Rita; William 100%
Rita; William;
Communication with
2 days Fri 6/14/24 Mon 6/17/24 2 Tyler; Wenger; 96%
Stakeholders
Steve
Document Current
2 days Tue 6/18/24 Wed 6/19/24 3 William 100%
System
Analysis Finished 1 day Thu 6/20/24 Thu 6/20/24 4 Wenger 0%
Design 22 days Fri 6/21/24 Mon 7/22/24 14%
Design Database 5 days Fri 6/21/24 Thu 6/27/24 5 Steve 62%
Software Design 6 days Fri 6/28/24 Fri 7/5/24 7 Yvette 0%
Interface Design 3 days Mon 7/8/24 Wed 7/10/24 8 Zoe 0%
Create Design
7 days Thu 7/11/24 Fri 7/19/24 9 Steve 0%
Specifications
Design Finished 1 day Mon 7/22/24 Mon 7/22/24 10 Wenger 0%
Development 23 days Tue 7/23/24 Thu 8/22/24 21%
Develop System Module 12 days Tue 7/23/24 Wed 8/7/24 11 Tyler; Wenger 41%
Integrate System Module 7 days Thu 8/8/24 Fri 8/16/24 13 Tyler 0%
Perform Initial Testing 3 days Mon 8/19/24 Wed 8/21/24 14 Wenger 0%
Development Finished 1 day Thu 8/22/24 Thu 8/22/24 15 Wenger 0%
Testing 15 days Fri 8/23/24 Thu 9/12/24 28%
Perform System Testing 8 days Fri 8/23/24 Tue 9/3/24 16 Vicky 63%
Document Issues Found 3 days Wed 9/4/24 Fri 9/6/24 18 Mike 0%
Correct Issues Found 6 days Wed 9/4/24 Wed 9/11/24 18 Vicky 0%
Testing Finished 1 day Thu 9/12/24 Thu 9/12/24 20 Wenger 0%
Deployment 16 days Fri 9/13/24 Fri 10/4/24 0%
On-Site Installation 1 day Fri 9/13/24 Fri 9/13/24 21 Tyler 0%
Support Plan for the
15 days Mon 9/16/24 Fri 10/4/24 23 Mike 0%
System
Completion 9 days Mon 10/7/24 Thu 10/17/24 0%
System Maintenance 9 days Mon 10/7/24 Thu 10/17/24 24 Rita 0%
Evaluation 9 days Mon 10/7/24 Thu 10/17/24 24 William 0%

36
September 23, 2024
[Project Name] [Document Name] [Version]

13.3 WBS with Gantt Chart

Figure A- 2: WBS and Gantt Chart

37
September 23, 2024
[Project Name] [Document Name] [Version]

13.4 Example: Context Diagram

The Cafeteria Ordering System is a new software system that replaces the current manual and telephone
processes for ordering and picking up meals in the Process Impact cafeteria. The context diagram in Figure
A- 3.

Figure A- 3: Context diagram of the Cafeteria Ordering System

38
September 23, 2024
[Project Name] [Document Name] [Version]

13.5 Example: User Classes and Characteristics

Table A- 3: Shows user classes and characteristic for Cafeteria ordering system

User class Description

Person A Person is a Process Impact employee who wants to order meals to be delivered
from the company cafeteria. There are about 600 potential Persons, of which 300 are
expected to use the COS an average of 5 times per week each. Persons will sometimes
order multiple meals for group events or guests. An estimated 60 percent of orders
will be placed using the corporate intranet, with 40 percent of orders being placed
from home or by smartphone or tablet apps.

Cafeteria The Process Impact cafeteria employs about 20 Cafeteria Staff who will receive
Staff orders from the COS, prepare meals, package them for delivery, and request delivery.
Most of the Cafeteria Staff will need training in the use of the hardware and software
for the COS.

Menu The Menu Manager is a cafeteria employee who establishes and maintains daily
Manager menus of the food items available from the cafeteria. Some menu items may not be
available for delivery. The Menu Manager will also define the cafeteria’s daily
specials. The Menu Manager will need to edit existing menus periodically.

Meal As the Cafeteria Staff prepare orders for delivery, they will issue delivery requests to
Deliverer a Meal Deliverer’s smartphone. The Meal Deliverer will pick up the food and deliver
it to the Person. A Meal Deliverer's other interactions with the COS will be to confirm
that a meal was (or was not) delivered.

39
September 23, 2024
[Project Name] [Document Name] [Version]

14 Appendix B

14.1 Example: Use case Diagram

Following use case diagram is of an appointment system in which all the use case diagram relationships
are presented. In further in Table- B 1 to the detail of use case diagram syntax is provided.

Figure B- 1:Use Case Diagram of an Appointment System

40
September 23, 2024
[Project Name] [Document Name] [Version]

Syntax for Use case Diagram

Table- B 1: Syntax for Use case Diagram

An actor:
■ A person or system that derives benefit from, and is external to, the
subject.
■ Is depicted as either a stick figure (default) or, if a nonhuman actor is
involved, a rectangle with <<actor>> in it (alternative).
■ Is labeled with its role.
■ Can be associated with other actors using a specialization/superclass
association, denoted by an arrow with a hollow arrowhead.
■ Is placed outside the subject boundary.

A use case:
■ Represents a major piece of system functionality.
■ Can extend another use case.
■ Can include another use case.
■ Is placed inside the system boundary.
■ Is labeled with a descriptive verb–noun phrase.
subject boundary:
■ Includes the name of the subject inside or on top.
■ Represents the scope of the subject, e.g., a system or an individual
business process.
An association relationship:
■ Links an actor with the use case(s) with which it interacts.

An include relationship:
■ Represents the inclusion of the functionality of one use case within
another.
■ Has an arrow drawn from the base use case to the used use case.
An extend relationship:
■ Represents the extension of the use case to include optional behavior.
■ Has an arrow drawn from the extension use case to the base use case.

A generalization relationship:
■ Represents a specialized use case to a more generalized one.
■ Has an arrow drawn from the specialized use case to the base use
case.

41
September 23, 2024
[Project Name] [Document Name] [Version]

Detail Use Case Example

The Table- B 2 below indicate a comprehensive use case template filled in with an example drawn from
the Cafeteria ordering system (COS).
Table- B 2: Show the detail use case template and example

Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1
Use Case Name: Enter a short name for the Use Case using an active verb phrase. e.g.
Order a Meal
Actors: [An actor is a person or other entity external to the software system being specified
who interacts with the system and performs use cases to accomplish tasks.] e.g.
Primary Actor: Person Secondary Actors: Cafeteria Inventory System
Description: [Provide a brief description of the reason for and outcome of this use case.] e.g.
A Person accesses the Cafeteria Ordering System from either the corporate intranet
or external Internet, views the menu for a specific date, selects food items, and
places an order for a meal to be picked up in the cafeteria or delivered to a specified
location within a specified 15-minute time window.
Trigger: [Identify the event that initiates the use case.]e.g.
A Person indicates that he wants to order a meal.
Preconditions: [List any activities that must take place, or any conditions that must be true, before
the use case can be started.
PRE-1. Person is logged into COS.
PRE-2. Person is registered for meal payments by payroll deduction.
Post conditions: [Describe the state of the system at the conclusion of the use case execution.
POST-1. Meal order is stored in COS with a status of “Accepted.”
POST-2. Inventory of available food items is updated to reflect items in this order.
POST-3. Remaining delivery capacity for the requested time window is updated.
Normal Flow: [Provide a detailed description of the user actions and system responses that will
take place during execution of the use case under normal, expected conditions.
1.0 Order a Single Meal
1. Person asks to view menu for a specific date. (refer 1.0. E1, 1.0.E2)
2. COS displays menu of available food items and the daily special.
3. Person selects one or more food items from menu. (refer 1.1)
4. Person indicates that meal order is complete. (refer 1.2)
5. COS displays ordered menu items, individual prices, and total price, including
taxes and delivery charge.
6. Person either confirms meal order (continue normal flow) or requests to modify
meal order (return to step 2).
7. COS displays available delivery times for the delivery date.
8. Person selects a delivery time and specifies the delivery location.
9. Person specifies payment method.
10. COS confirms acceptance of the order.
11. COS sends Person an email message confirming order details, price, and
delivery instructions.
12. COS stores order, sends food item information to Cafeteria Inventory System,
and updates available delivery times.
42
September 23, 2024
[Project Name] [Document Name] [Version]
Alternative [Document legitimate branches from the main flow to handle special conditions
Flows: (also known as extensions). For each alternative flow reference the branching step
number of the normal flow and the condition which must be true for this extension
to be executed. e.g.
1.1 Order multiple identical meals
1. Person requests a specified number of identical meals. (refer 1.1. E1)
2. Return to step 4 of normal flow.
1.2 Order multiple meals
1. Person asks to order another meal.
2. Return to step 1 of normal flow.
Note: Insert a new row for each distinctive alternative flow. ]
Exceptions: 1.0. E1 Requested date is today and current time is after today’s order cutoff time
1. COS informs Person that it’s too late to place an order for today.
2a. If Person cancels the meal ordering process, then COS terminates use case.
2b. Else if Person requests another date, then COS restarts use case.
1.0. E2 No delivery times left
1. COS informs Person that no delivery times are available for the meal date.
2a. If Person cancels the meal ordering process, then COS terminates use case.
2b. Else if Person requests to pick the order up at the cafeteria, then continue with
normal flow, but skip steps 7 and 8.
1.1. E1 Insufficient inventory to fulfill multiple meal order
1. COS informs Person of the maximum number of identical meals he can order,
based on current available inventory.
2a. If Person modifies number of meals ordered, then return to step 4 of normal
flow.
2b. Else if Person cancels the meal ordering process, then COS terminates use case.
Business Rules Use cases and business rules are intertwined. Some business rules constrain which
roles can perform all or parts of a use case. Perhaps only users who have certain
privilege levels can perform specific alternative flows. That is, the rule might
impose preconditions that the system must test before letting the user proceed.
Business rules can influence specific steps in the normal flow by defining valid input
values or dictating how computations are to be performed e.g.
BR-1 Delivery time windows are 15 minutes, beginning on each quarter hour.
BR-2 Deliveries must be completed between 11:00 A.M. and 2:00 P.M. local time,
inclusive.

Note: If you are maintaining the business rule in a separate table in SRS then only
mention here their IDs.
Assumptions: [List any assumptions.
2. e.g. Assume that 15 percent of Persons will order the daily special (Source:
previous 6 months of cafeteria data).

43
September 23, 2024
[Project Name] [Document Name] [Version]

14.2 Event-Response Tables

In order to develop Event Response table it is required to identify all possible events. Following is an
example of events list and event-response table of highway intersection system.

The highway intersection system described earlier has to deal with various events, including these:
• A sensor detects a car approaching in one of the through lanes.
• A sensor detects a car approaching in a left-turn lane.
• A pedestrian presses a button to request to cross a street.
• One of many timers counts down to zero.

Table- B 3 presents a fragment of what an event-response table might look like for such a system. Each
expected system behavior consists of a combination of event, system state, and response.
Note: You may add more information to event-response table in order to perform detail requirement
analysis which includes:
• The event frequency (how many times the event takes place in a given time period, or a limit to
how many times it can occur).
• Data elements that are needed to process the event.
• The state of the system after the event responses are executed.

Table- B 3: Partial Event-Response Table for a Highway Intersection

Event System State Response

Road sensor detects Left-turn signal is red. Cross- Start green-to-amber
vehicle entering left-turn traffic signal is green. countdown timer for cross-traffic signal.
lane.
Green-to-amber countdown Cross-traffic signal is green. 1. Turn cross-traffic signal amber.
timer reaches zero. 2. Start amber-to-red countdown timer.
Amber-to-red Cross-traffic signal is amber. 1. Turn cross-traffic signal red.
countdown timer reaches 2. Wait 1 second.
zero. 3. Turn left-turn signal green.
4. Start left-turn-signal countdown timer.
Pedestrian presses a Pedestrian sign is solid Don’t Start walk-request countdown timer.
specific walk-request Walk.
button. Walk-request countdown
timer is not activated.
Pedestrian presses walk- Pedestrian sign is solid Don’t Do nothing.
request button. Walk.
Walk-request countdown
timer is activated.
Walk-request Traffic signal in walk Change all green traffic signals to amber.
countdown timer reaches direction is green.
zero plus the amber display
time.
Walk-request Traffic signal in walk 1. Change all amber traffic signals to red.
countdown timer reaches direction is amber. 2. Wait 1 second.
zero. 3. Set pedestrian sign to Walk.
44
September 23, 2024
[Project Name] [Document Name] [Version]
4. Start don’t-walk countdown timer.

14.3 Story Boarding

Following is an example of story boarding which is used to identify and analyze graphically intensive
applications.

45
September 23, 2024
[Project Name] [Document Name] [Version]

46
September 23, 2024
[Project Name] [Document Name] [Version]

14.4 Box-and-line diagram

Box-and-line diagrams are often used to describe the business concepts and processes during the analysis
phase of the software development lifecycle. These diagrams come with descriptions of components and
connectors, as well as other descriptions that provide common inherent interpretations.

Example:
Lines in the box-and-line diagrams indicate the relationship among components
• The semantic of lines may refer dependency, control flow, data flow, etc.
• Lines may be associated with arrows to indicate the process direction and sequence.
• A box-and-line diagram can be used as a business concept diagram describing its application domain
and process concepts

Figure B- 2 Box-and-Line Diagram for an Online Shopping Business

14.5 Example of Architecture Pattern:

The Table- B 3 shows an example of the logical package organization of the layered architecture. The top-
level deals with user interface, the next level is for utilities, and the one below utility provides core services.
Each layer gets support from its lower adjacent layer by an interface implementation and from the related
classes in the same layer.
47
September 23, 2024
[Project Name] [Document Name] [Version]

A simple software system may consist of two layers: an interaction layer and a processing layer:
• The interaction layer provides user interfaces to clients, takes requests, validates, and forwards
requests to the processing layer for processing, and responds to clients.
• The processing layer receives the forwarded requests and performs the business logic process,
accesses the database, returns the results to its upper layer, and lets the upper layer respond to clients
since the upper layer has the GUI interface responsibility.

Figure B- 3: Component-based Layered Architecture

Note: The Architecture pattern shall be selected according to the targeted system’s requirements and quality
attributes. Above example is provided to demonstrate that how the system architecture is required to be
presented.

48
September 23, 2024
[Project Name] [Document Name] [Version]

14.6 Design Models

14.7 Activity Diagram

Following activity diagram is of an appointment system presenting make an appointment process in which
all diagram’s elements are presented. In further in Table- B 4 to the detail of activity diagram syntax is
provided.

Example

Figure B- 4: Activity Diagram for Make an Appointment Process

49
September 23, 2024
[Project Name] [Document Name] [Version]

Activity Diagram Syntax

Table- B 4: Activity Diagram Syntax

Term and definition Symbol

An action:
▪ Is a simple, non-decomposable piece of behavior.
▪ Is labeled by its name.
An activity:
▪ Is used to represent a set of actions.
▪ Is labeled by its name.
An object node:
▪ Is used to represent an object that is connected to a set of object
flows.
▪ Is labeled by its class name.
A control flow:
▪ Shows the sequence of execution.
An object flow:
▪ Shows the flow of an object from one activity (or action) to
another activity (or action).
An initial node:
▪ Portrays the beginning of a set of actions or activities.
A final-activity node:
▪ Is used to stop all control flows and object flows in an activity
(or action).
A final-flow node:
▪ Is used to stop a specific control flow or object flow.
A decision node:
▪ Is used to represent a test condition to ensure that the control
flow or object flow only goes down one path.
▪ Is labeled with the decision criteria to continue down the
specific path.
A merge node:
▪ Is used to bring back together different decision paths that were
created using a decision node.

A fork node:
▪ Is used to split behavior into a set of parallel or concurrent
flows of activities (or action)
A join node:
▪ Is used to bring back together a set of parallel or concurrent
flows of activities (or action)

50
September 23, 2024
[Project Name] [Document Name] [Version]
A swimlane:
▪ Is used to break up an activity diagram into rows and columns
to assign the individual activities (or actions) to the individuals
or objects that are responsible for executing the activity (or
action)
▪ Is labeled with the name of the individual or object responsible

14.8 Class Diagram

Following class diagram is of an appointment system in which all class diagrams elements are presented. In
further in Table- B 5 to the detail of class diagram syntax is provided.

Example

Figure B- 5: Class Diagram for an Appointment System

51
September 23, 2024
[Project Name] [Document Name] [Version]

Class Diagram Syntax

Table- B 5: Class Diagram Syntax

Term and definition Symbol

A class:
▪ Has a name typed in bold and centered in its top compartment.
▪ Has a list of attributes in its middle compartment.
▪ Represents a kind of person, place, or thing about which the
system will need to capture and store information.
▪ Has a list of operations in its bottom compartment.
▪ Does not explicitly show operations that are available to all
classes.
An attribute:
▪ Represents properties that describe the state of an object. attribute name
▪ Can be derived from other attributes, shown by placing a slash /derived attribute name
before the attribute’s name.
An operation:
▪ Represents the actions or functions that a class can perform.
▪ Can be classified as a constructor, query, or update operation.
▪ Includes parentheses that may contain parameters or
information needed to perform the operation.
operation name ()
An association:
▪ Represents a relationship between multiple classes or a class
and itself.
▪ Is labeled using a verb phrase or a role name, whichever better
represents the relationship.
▪ Can exist between one or more classes.
▪ Contains multiplicity symbols, which represent the minimum
and maximum times a class instance can be associated with the
related class instance.

A generalization:
▪ Represents a-kind-of relationship between multiple classes.

An aggregation:
▪ Represents a logical a-part-of relationship between multiple
classes or a class and itself.
▪ It is a special form of an association
A composition:
▪ Represents a physical a-part-of relationship between multiple
classes or a class and itself
▪ It is a special form of an association
52
September 23, 2024
[Project Name] [Document Name] [Version]

14.9 Sequence Diagram

Following example shows an instance sequence diagram that depicts the objects and messages for the Make
Old Patient Appointment use case, which describes the process by which an existing patient creates a new
appointment or cancels or reschedules an appointment. In further in Table- B 6 to the detail of class diagram
syntax is provided.

Example

Figure B- 6: Make Appointment Use Case

53
September 23, 2024
[Project Name] [Document Name] [Version]

Sequence diagram Syntax

Table- B 6: Sequence Diagram Syntax

Term and definition Symbol

An actor:
▪ Is a person or system that derives benefit from and is external to
the system.
▪ Participates in a sequence by sending and/or receiving
messages.
▪ Is placed across the top of the diagram.
▪ Is depicted either as a stick figure (default) or, if a nonhuman
actor is involved, as a rectangle with <<actor>> in it
(alternative).
An object:
▪ Participates in a sequence by sending and/or receiving
messages.
▪ Is placed across the top of the diagram.
A lifeline:
▪ Denotes the life of an object during a sequence.
▪ Contains an X at the point at which the class no longer
interacts.

An execution occurrence:
▪ Is a long narrow rectangle placed atop a lifeline
▪ Denotes when an object is sending or receiving messages.

A message:
▪ Conveys information from one object to another one.
▪ An operation call is labeled with the message being sent and a
solid arrow, whereas a return is labeled with the value being
returned and shown as a dashed arrow.

A guard condition:
▪ Represents a test that must be met for the message to be sent.

For object destruction:

▪ An X is placed at the end of an object’s lifeline to show that it
is going out of existence.
A frame:
▪ Indicates the context of the sequence diagram.

54
September 23, 2024
[Project Name] [Document Name] [Version]

14.10 Behavioral State Machine Diagram

Following example of a behavioral state machine representing the patient class in the context of a hospital
environment. From this diagram, we can tell that a patient enters a hospital and is admitted after checking
in. If a doctor finds the patient to be healthy, he or she is released and is no longer considered a patient after
two weeks elapse. If a patient is found to be unhealthy, he or she remains under observation until the
diagnosis changes.

Example

Figure B- 7: Sample Behavioral State Machine Diagram

55
September 23, 2024
[Project Name] [Document Name] [Version]

Behavioral State Machine Diagram Syntax

Table- B 7: Behavioral State Machine Diagram Syntax

Term and definition Symbol

A state:
▪ Is shown as a rectangle with rounded corners.
▪ Has a name that represents the state of an object.

An initial state:
▪ Is shown as a small, filled-in circle.
▪ Represents the point at which an object begins to exist.

A final state:
▪ Is shown as a circle surrounding a small, filled-in circle
(bull's-eye).
▪ Represents the completion of activity.
An event:
▪ It’s a noteworthy occurrence that triggers a change in state.
▪ Can be a designated condition becoming true, the receipt of
an explicit signal from one object to another, or the passage
of a designated period of time.
▪ Is used to label a transition.
A transition:
▪ Indicates that an object in the first state will enter the second
state.
▪ Is triggered by the occurrence of the event labeling the
transition.
▪ Is shown as a solid arrow from one state to another, labeled
by the event name.
A frame:
▪ Indicates the context of the behavioral state machine.

56
September 23, 2024
[Project Name] [Document Name] [Version]

14.11 Data Flow Diagram

Data flow diagram symbols, symbol names, and examples

Figure B- 8: Data flow diagram symbols, symbol names, and examples of the Gane and
Sarson and Yourdon symbol sets.

Guidelines for Drawing DFDs

Step 1: Draw a Context Diagram: The first step in constructing a set of DFDs is to draw a context diagram.
A context diagram is a top-level view of an information system that shows the system’s boundaries and
scope. Data stores are not shown in the context diagram because they are contained within the system and
remain hidden until more detailed diagrams are created.

57
September 23, 2024
[Project Name] [Document Name] [Version]

Example

Figure B- 9: Context diagram DFD for an order system.

Step 2: Draw a Diagram 0 DFD: To show the detail inside the black box, you create DFD diagram 0.
Diagram 0 zooms in on the system and shows major internal processes, data flows, and data stores. Diagram
0 also repeats the entities and data flows that appear in the context diagram. When you expand the context
diagram into DFD diagram 0, you must retain all the connections that flow into and out of process 0.

58
September 23, 2024
[Project Name] [Document Name] [Version]
Example

Figure B- 10: Diagram 0 DFD for the order system

Step 3: Draw the Lower-Level Diagrams:

59
September 23, 2024
[Project Name] [Document Name] [Version]
To create lower-level diagrams, you must use leveling and balancing techniques. Leveling is the process
of drawing a series of increasingly detailed diagrams, until all functional primitives are identified.

Figure B- 11: Diagram 1 DFD shows details of the FILL ORDER process in the order system.

Leveling Example

Balancing maintains consistency among a set of DFDs by ensuring that input and output data flows
align properly.

60
September 23, 2024
[Project Name] [Document Name] [Version]

Balancing Example

Order System Diagram 0 DFD

61
September 23, 2024
[Project Name] [Document Name] [Version]
The order system diagram 0 is shown at the top of the figure and exploded diagram 3 DFD (for the APPLY
PAYMENT process) is shown at the bottom. The two DFDs are balanced, because child diagram at the
bottom has the same input and output flows as the parent process 3 shown at the top.

Order System Diagram 3 DFD

62
September 23, 2024
[Project Name] [Document Name] [Version]

14.12 Screen objects and actions

A discussion of screen objects and actions associated with those objects.

Register screen: The register button registers the user with the given details into the system.
Login screen: The login button signs the user into the system.
Home: The medications, allergic reaction, diet, exercise, chat buttons directs the user to the main screen of
those modules.
Medicine: The diabetic medications directs the user to the diabetic medication screen.
Medicine: The non-diabetic medications directs the user to the non-diabetic medication screen.
Physical activity: The start button initiates the physical activity plan for the day.
Allergic Reaction Screen: The diabetic medication displays all the diabetic allergic reactions stored in the
system.
Non-diabetic Medication: The non-diabetic medication displays all the non-diabetic allergic reactions stored
in the system.
Allergic Reaction Screen: The insulin displays all the insulin allergic reactions stored in the system.
Allergic Reaction Screen: The food displays all the food allergic reactions stored in the system.
Meal Plan Screen: The view recipe button displays the recipe of the food.
Meal Plan Screen: The add to favorite button add the recipe to the favorite
Meal Plan Screen: The view favorite list button displays the list of the user’s favorite recipes.
Tracker Main Screen: The blood glucose displays all blood glucose instances of the day stored by user.
Tracker Main Screen: The blood pressure displays all blood pressure instances of the eek stored by user.
Tracker Main Screen: The cholesterol displays all cholesterol instances of 6 months stored by user.
Blood Sugar Statics Screen: The today button displays the statistics of all today’s blood sugar instances.
Blood Sugar Statics Screen: The week button displays the statistics of all blood sugar instances of the week.
Blood Sugar Statics Screen: The month button displays the statistics of all blood sugar instances of the
month.
Blood Sugar Statics Screen: The year button displays the statistics of all blood sugar instances of the year.

14.13 Screen Images/Mockups

63
September 23, 2024
[Project Name] [Document Name] [Version]

Description: This screen shows the admins’ home page containing options for profile setting. To change setting user
shall select the ‘settings’ link and account details will be opened in editable mode.

Description: This displays the home page of website with navigable links for ‘About us’, ‘News’.

14.14 Example Data Design

The database used for our project would be MongoDB. It is a non-relational database. MongoDB will be used
to store the data with it being hosted on MongoDB Atlas.

Data Dictionary
Allergic Reaction
This scheme saves the allergic reaction details of the patient.
allergicReaction_id: String
name:String
type: String
symptoms:String[]
description:String
user_id: String 200

Blood Pressure
This schema saves the blood pressure details of the patient.
bloodPressure_id : String
systolic: Integer
diastolic: Integer
date: Date
description: String
user_id: String

64
September 23, 2024
[Project Name] [Document Name] [Version]
Blood Sugar
This schema saves the blood glucose concentration of the patient.
bloodSugar_id : String
concentration: Integer
unit: Enum[mmol/L, mg/dL]
description: String
time: Time
date: Date
event: String
description: String
creationDate: Date
creationTime: Time
user_id: String

Cholesterol
This schema saves the cholesterol details of the patient.
cholesterol_id: String
cholesterol: Integer
ldl: Integer
hdl: Integer
triglycerides: Integer
description: String
user_id: String

65
September 23, 2024
[Project Name] [Document Name] [Version]

14.15 Example ERD

Example

Figure B- 12: ERD Example

ERD Syntax

Table- B 8: ERD Syntax

Term and definition Symbol

An entity:
▪ An entity is a representation of a class of object. It can be a
person, place, thing, etc. Entities usually have attributes that
describe them.
▪
▪ In crow’s foot notation, an entity is represented by a
rectangle, with its name on the top. The name is singular
(entity) rather than plural (entities).

66
September 23, 2024
[Project Name] [Document Name] [Version]
Attribute:
▪ An attribute is a property that describes a particular entity.
▪ The attribute(s) that uniquely distinguishes an instance of
the entity is the identifier. Usually, this type of attribute is
marked with an asterisk.

Relationships:
▪ Relationships illustrate the association between two entities.
They are presented as a straight line. Usually, each
relationship has a name, expressed as a verb, written on the
relationship line. This describes what kind of relationship
connects the objects.
▪ Note that the mentioned type of relationship is binary. In
the Entity-Relationship model, representing a ternary or
higher order of relationship is problematic.
▪ Relationships have two indicators. These are shown on both
sides of the line.

The first one (often called multiplicity) refers to the maximum

number of times that an instance of one entity can be associated
with instances in the related entity. It can be one or many.

Multiplicity of One:

Multiplicity of One:

The second describes the minimum number of times one

instance can be related to others. It can be zero or one, and
accordingly describes the relationship as optional or
mandatory.
Mandatory

Optional

Zero or many

One or many

67
September 23, 2024
[Project Name] [Document Name] [Version]
One or one

Zero or one

68
September 23, 2024
[Project Name] [Document Name] [Version]

14.17 Requirement Traceability Matrix

Project Name <Project name Here> Created On <5-Oct-23> Reviewed on <7-Oct-23>

Release No <Project release> Created by <Creator Name> Reviewed by Reviewed Name
Version <Doc version>

ID Requirement ID Requirement Description Use Case Sequence Test Case ID UI ID Tested on/Verified Tested By
ID Diagram
1 FR-1 Description here, should be in 2 3 UC-01 1 TC-001 UI-1 Verified Member 1, 2
lines
2 FR-2 Description here, should be in 2 3 UC-02 2 TC-002 UI-2 Not Verified Member 2
lines
3 FR-3 Description here, should be in 2 3 UC-03 3 TC-003 UI-3 In Progress Member 3
lines
4 FR-4 Description here, should be in 2 3 UC-04 4 TC-004 UI-4 Pending Member 4
lines

69
September 23, 2024
[Project Name] [Document Name] [Version]

15 Appendix C
15.1 Deliverable Details for Capstone 1
Deliverable No. Due Time Deliverable Name Report Section to Be Complete
1 Week 1 Proposal Submission 1. Introduction
2. Project Background
3. Comparative Analysis
4. Advantages/Benefits of Proposed System
5. Project Scope
6. Modules
7. System Limitations/Constraints
8. Tools and Technologies
9. Problem Definition

2 Week 2 Proposal Defense 1. Introduction

2. Project Background
3. Comparative Analysis
4. Advantages/Benefits of Proposed System
5. Project Scope
6. Modules
7. System Limitations/Constraints
8. Tools and Technologies
9. Problem Definition

3 Week 4 Project Plan + Initial 1. Team Members Individual Tasks/Work Division

WBS 2. WBS and Gantt Chart
3. Cost of Project

4 Week 6 SRS 1. Requirement Analysis

2. Requirement Elicitation Techniques
3. Use Cases Diagram(s)
4. Detailed Use Case (Tabular- Module Wise)

70
September 23, 2024
[Project Name] [Document Name] [Version]
5. Functional Requirements (Tabular FR- Module Wise)
6. Non-Functional Requirements
7. External Interface Requirements

5 Week 9 Design Document 1. Architecture and Design

2. System Architecture
3. Design Methodology
4. Data Representation [Diagram + Description] (ERD, JSON
SCHEMA)
5. Design Models [along with descriptions]
6. Human Interface Design
7. Screen Images
8. Models and Animations
9. Screen Objects and Actions

6 Week 12 Partial 1. WBS and Gantt Chart

Implementation + 2. Cost of Project
WBS Update 3. Implementation
4. User Interface/ Front End
5. Brief Overview of the Proposed System
6. External APIs

7 Week 14 Code Review as per 1. WBS and Gantt Chart

SRS/Mid 2. Cost of Project
Presentation 3. Implementation
4. User Interface/ Front End
5. Brief Overview of the Proposed System
6. External APIs

8 Week 15 Capstone 1 Final Partial project with Document

Presentation

71
September 23, 2024
[Project Name] [Document Name] [Version]
15.2 Deliverable Details for Capstone 2
Deliverable No. Due Time Deliverable Name Report Section To Be Complete
1 Week 2 Test Cases 1. Testing and Evaluation
2. Test Plan
3. Product Scope
4. Intended Audience
5. Definitions, Acronyms and Abbreviations
6. Test Pass/ Fail Criteria
7. Verification
8. Validation
9. Usability Testing
10. Module / Unit Testing
11. Integration Testing
12. System Testing
13. Acceptance Testing
14. Manual Testing
15. Test Cases

2 Week 6 50% Implementation 1. WBS and Gantt Chart

+ WBS Update 2. Cost of Project
3. Human Interface Design
4. Screen Images
5. Models and Animations
6. Screen Objects and Actions
7. Implementation
8. User Interface/ Front End
9. Brief Overview of the Proposed System
10. External APIs

3 Week 12 100% Coomplete Document and Project Along with following tasks
Implementation
1. Human Interface Design
2. Screen Images
3. Models and Animations
72
September 23, 2024
[Project Name] [Document Name] [Version]
4. Screen Objects and Actions
5. Implementation
6. User Interface/ Front End
7. Brief Overview of the Proposed System
8. External APIs
9. Requirement Traceability Matric
10. Conclusion and Future Work
11. Conclusion
12. Future Work
13. Work Summary and Reviews
14. Lesson Learnt
15. Work Break Down
16. Reviews Details
17. References
18. Plagiarism Report

4 Week 14 Test Reports 1. Testing and Evaluation

2. Test Cases
3. Environmental Needs
4. Responsibilities

5 Week 14 Code Review/Pre- Complete project work along with its Complete Documentation
Final Evaluation
6 Week 15 Capstone 2 Final Complete project work along with its Complete Documentation
Presentation

73
September 23, 2024
[Project Name] [Document Name] [Version]

16 Style Guide lines

This is a style guide for final year project reports. These styles should be used without modification or
replacement.
While this may well sound like a rather prescriptive approach to report writing, it is introduced for the
following reasons.
1. The style guide allows students to focus on the critical task of producing clear and concise content,
instead of being distracted by font settings and paragraph spacing.

2. By providing a comprehensive style guide the students to benefits to from a consistent and
professional look to its internal project reports.

3. The style guide also allows the students to properly control the size restrictions that are placed on
reports.

The remainder of this document briefly outlines the main components and suggested use of this style guide.

16.1 Styles in Word

Every style defined in this document is essentially a collection of formatting commands (font commands,
paragraph controls etc.) for each of the common types of components that are likely to make up your
project report.
As such the following standard styles have been defined:
● Normal – the style for the basic text of the document.

● Title – the main title style.

● Subtitle – the subtitle style.

● Author – the style used for the author’s name on the front page.

● H1, H2, H3 – styles for different levels of section headings.

● Figure – the style for a figure or table caption.

● Code – the style for program source code.

● Bulleted List – the style for a standard bulleted list such as this one.

● Numbered List – similar to the bulleted list style except that the list is numbered.

74
September 23, 2024
[Project Name] [Document Name] [Version]
Normally, styles are selected from the Word style menu, which is located on the main Word toolbar (see
following Figure 1.

Figure 5: Selecting the Heading 1 style from the Word style menu
To help you with the standard styles, a new toolbar has been added to the top left of this document;
if you cannot see it then select the toolbar called Report in the Toolbar menu within the View menu.
This new toolbar displays a set of buttons for each of the main standard styles used in this document.
Just click on a style button to activate the corresponding style (see Following Figure).

Figure 6: The report style toolbar provides easy access to the approved styles.
It is important to emphasise that the above styles are the only styles that are approved for use in your
report. Word comes with an expanded set of pre-defined styles and of course you can, in theory,
define your own styles. However, we strongly suggest that you to stick to the approved styles. Of
course, you may have a genuine need for a new style during the preparation of your report. However,
we suggest that you consider whether one of the approved styles can be used before you rush to
create a new style. For example, we have not defined a specific style for the bibliographic entries
that you will need at the end of your report.

75
September 23, 2024
[Project Name] [Document Name] [Version]

16.2 Page Layout & Size

The page size and margins have been set in this document (see Figure 7). These should not be changed or
adjusted. The page size, fonts and spacing have been chosen to allow for approximately 700 - 800 words
per page of text or approximately 25,000 – 28,000 per 35-page document.

Figure 7: Page settings defined for this document

In addition, page headers and footers have been included. The footer should not be edited as it contains page
number and date information that is always updated automatically. Similarly, the header is designed to
update automatically once the appropriate field data (title and author have been provided); see Section 8 for
information about how to do this.

17 Headings
Your report will be structured as a collection of number sections at different levels of detail. For example,
the heading to this section is a first-level heading (it’s called Heading 1) and has been defined with a
particular set of font and spacing characteristics. At the start of a new section, you need to select the
appropriate heading style, Heading 1 in this case, by clicking H1 on the new style toolbar.

17.1 Second Level Headings

Second and third level headings have also been defined and can be accessed as H2 and H3 styles. For
example, the heading in this subsection is a second-level heading.

76
September 23, 2024
[Project Name] [Document Name] [Version]
17.1.1 Third Level Headings
The heading for this subsection is a third level heading. In general, it is unlikely that fourth of fifth level
headings will be required in your final report. Indeed it is more likely that if you do find yourself needing
them, then your document structure is probably not ideal. So, try to stick to three levels of heading provided.

17.2 Figures and Charts

Most final reports will contain a mixture of figures and charts along with the main body of text. In this
document a style called figure (accessed as usual from the new report style toolbar) has been defined for the
figure caption and should appear directly after the figure as seen in Figures 6 and 7 above. Once again, time
has been spent defining this style to handle figure numbering but care needs to be taken to ensure that extra
lines are not carelessly created in this style or else the numbering will not be correct.
Inserting and aligning figures and charts in Word can be a hit and miss affair at the best of times. As a tip,
a fairly reliable way of inserting graphics and charts that have been copied to the clipboard is to use the
“paste special” option in word and select a “picture” option, rather than pasting directly.
Figures, charts and tables should always be centered horizontally. This can be achieved by right-clicking
the graphic, selecting the Format Picture option and then selecting the Layout tab to find various alignment
options.

17.3 Program Code

A Code style has been prepared for formatting short excerpts of source code. It is a simple indented, single-
spaced style using a fixed font (Courier New) to produce code that appears like the following:
static public void main(String[] args) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
}
catch(Exception e) {
e.printStackTrace();
}
new WelcomeApp();
}

17.4 Table of Contents

A table of contents (TOC) page has also been included in this report template and can be created using the
TOC generator in Word. Ordinarily this is accessed via Index and Tables option in the in the Insert menu.
However, to avoid the need to set certain TOC features, the best way to insert a new table of contents is to
use the TOC macro defined in this document. This macro can be run by clicking on the TOC button on the
report style toolbar to position a new table of contents at the current cursor position. Notice that you can
update your existing table of contents by simply right clicking it and selecting the update field option.
A word of warning on this feature – the table of contents is automatically generated by compiling a table of
all of the level 1, 2 and 3 headings in your document. This means that every line with one of these styles
will appear in the table. If you use these styles for non-headings (of course you should not do this) then
these non-headings will also appear in the table.

77
September 23, 2024