Project Title

Project Team

Student 1 19I-1234
Student 2 19I-1234
Student 3 19I-1234

Session 2018-2022

Supervised by

Mr./ Ms./ Dr. Supervisor Name

Co-Supervised by

Mr./ Ms./ Dr. Supervisor Name

Department of Computer Science

National University of Computer and Emerging Sciences

Islamabad, Pakistan

June, 2022
Contents

1 Introduction [AS PER SCOPE DOCUMENT] 1

1.1 Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Module 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 Module 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.3 Example: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.3.1 Inventory Management Module . . . . . . . . . . . . . 4
1.5 Work Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Project Requirements [AS PER FYP1 MID REPORT] 5

2.1 Use-case/Event Response Table/Storyboarding . . . . . . . . . . . . . . . 5
2.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Module 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Module 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 System Overview [AS PER FYP1 MID REPORT] 9

3.1 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Data Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Design Models [UPTO THE CURRENT ITERATION ONLY] . . . . . . 11

4 Implementation and Testing [UPTO THE CURRENT ITERATION ONLY] 13

4.1 Algorithm Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 External APIs/SDKs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Testing Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

References 15

2
 CONTENTS

A Appendices 17
A.1 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.1.1 Use Case Diagram example (Online Shopping System) . . . . . . 17
A.1.2 Detail Use Case Example . . . . . . . . . . . . . . . . . . . . . . 18
A.1.3 Event-Response Table for a Highway Intersection . . . . . . . . . 19
A.1.4 Story Board Example For Android App . . . . . . . . . . . . . . 20
A.2 Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2.1 Domain Model Example For Online Shopping . . . . . . . . . . . 21
A.3 Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.3.1 Box And Line Example For Online Shopping . . . . . . . . . . . 22
A.3.2 Architecture Pattern Example For Online Shopping . . . . . . . . 23
A.4 Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.4.1 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.4.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.4.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4.4 State Transition Diagram . . . . . . . . . . . . . . . . . . . . . . 26
A.4.5 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 27

3
List of Figures

4.1 Example Of Algorithm Design . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Example for Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 14

A.1 Use Case Diagram for the Online Shopping System . . . . . . . . . . . . 17

A.2 Detail Use Case Example . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3 Example of Event Response Table . . . . . . . . . . . . . . . . . . . . . 19
A.4 Example of Story Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.5 Domain Model Example For Online Shopping Application . . . . . . . . 21
A.6 Box and Line Diagram For Online Shopping Application . . . . . . . . . 22
A.7 Architecture Pattern For Online Shopping Application . . . . . . . . . . . 23
A.8 Activity Diagram For Online Shopping Application . . . . . . . . . . . . 24
A.9 Class Diagram For Online Shopping Application . . . . . . . . . . . . . 25
A.10 Sequence Diagram For Online Shopping Application . . . . . . . . . . . 26
A.11 State Transition Diagram For Online Shopping Application . . . . . . . . 26

4
List of Tables

1.1 Comparison of Existing Solutions . . . . . . . . . . . . . . . . . . . . . 2

0
Chapter 1

Introduction [AS PER SCOPE

DOCUMENT]

The "Introduction" section sets the foundation for the entire report and should be carefully
crafted to give the reader a clear understanding of the project’s scope, objectives, and
context. Here’s what you can include:
Background:
Begin by providing background information on the broader topic or field your develop-
ment project is related to. Highlight any existing problems, gaps, or opportunities that
led to the motivation for your project. Include relevant references to previous research,
development projects, or technologies. For example, you might want to cite studies or
prior systems that failed to address the issues you’re focusing on. [1].

1.1 Existing Solutions

For the Existing Solutions section, students should research and describe various solu-
tions, methods, or approaches that have been previously developed to solve the problem
they are addressing. This section should include an overview of the different techniques,
technologies, or models that are currently in use or have been applied in the past. Students
should critically assess the strengths and weaknesses of each solution, highlighting any
gaps or limitations that their project aims to address. Additionally, this section should
show an understanding of the state-of-the-art in the field and provide context for why the
proposed solution is necessary or an improvement over existing ones.

1
1. Introduction [AS PER SCOPE DOCUMENT]

Table 1.1: Comparison of Existing Solutions

System Name System Overview System Limitations
System 1 Brief description of what Sys- Highlight the shortcomings or
tem 1 does and its primary issues with System 1.
features.
System 2 Brief description of what Sys- Highlight the shortcomings or
tem 2 does and its primary issues with System 2.
features.
System 3 Brief description of what Sys- Highlight the shortcomings or
tem 3 does and its primary issues with System 3.
features.

1.2 Problem Statement

Clearly define the specific problem your project aims to solve. Explain why this problem
is important and how solving it will contribute to the field. This section is critical as it sets
the context for your work. This can include technical challenges, system inefficiencies,
or user experience problems. Why you are developing this system? What problem does
your software solve? (Usually in 10-16 sentences)
Example:
In recent years, the surge in online shopping has resulted in a significant increase in
the demand for e-commerce platforms. However, most small to medium-sized businesses
struggle to adopt sophisticated e-commerce systems due to high costs, complexity, and
lack of customization. Current available solutions either require substantial financial
investment or offer limited functionality, leading to inefficiencies in managing product
inventories, processing orders, and handling customer interactions.
This project aims to address this issue by developing a cost-effective, customizable, and
user-friendly e-commerce platform tailored specifically for small to medium-sized enter-
prises (SMEs). The platform will integrate key functionalities such as inventory manage-
ment, order tracking, and customer relationship management into a single, unified system
that can be easily deployed with minimal technical expertise.

1.3 Scope

The scope of this project defines what will be included and excluded, helping to set clear
expectations for the reader. This section outlines the boundaries and limitations of the

2
 1.4 Modules

development project.
This can include:

• What the project will cover: You define the main features and functionality that the
project will focus on, including the specific tools, systems, and technologies to be
developed.

• What the project will not cover: This outlines the limitations, clarifying any ar-
eas that the project will not address (e.g., advanced features or post-deployment
support).

(Usually in 14-18 sentences)

1.4 Modules

This section describes the key functional units or modules of the project, each designed
to perform a specific task. The breakdown of the project into modules ensures that each
part of the system is manageable and addresses specific objectives. Each module should
be described in terms of its functionality and how it interacts with other modules in the
system.

The modules should be logically organized to reflect the overall system workflow, ensur-
ing that each module description is comprehensive but concise.

1.4.1 Module 1

[2-4 lines description of the module]

1. Feature 1

2. Feature 2

1.4.2 Module 2

[2-4 lines description of the module]

1. Feature 1

2. Feature 2

3
1. Introduction [AS PER SCOPE DOCUMENT]

1.4.3 Example:

1.4.3.1 Inventory Management Module

This module focuses on inventory management, allowing businesses to efficiently track

and manage their product stock levels. It integrates features for adding new products,
updating stock information, and generating low-stock alerts.

1. Ability to add, update, and remove products from inventory.

2. Automated alerts for low stock levels to aid in restocking decisions.

1.5 Work Division

4
Chapter 2

Project Requirements [AS PER FYP1

MID REPORT]

This section outlines the necessary requirements for the successful completion of the
project. Project requirements can be divided into two main categories: functional require-
ments, which describe the system’s core operations, and non-functional requirements,
which specify performance, security, and usability standards.

2.1 Use-case/Event Response Table/Storyboarding

This section describes how users will interact with the system through various scenarios,
often referred to as use cases or event responses.
A use case represents a specific interaction between the user and the system, detailing the
steps involved and the expected system responses. Each use case typically includes key
components such as a unique identifier, a description of the interaction, the user or system
actor involved, preconditions, the main flow of events, and postconditions.
Additionally, storyboarding can be used as a visual aid to depict the sequence of actions,
illustrating how the user progresses through the system step by step. Storyboards are help-
ful for capturing the user experience and ensuring that the design aligns with the intended
functionality.

Depending on the project, use cases, storyboarding or Event-response table can be cho-
sen as appropriate methodologies to illustrate user interactions. Examples of all the ap-
proaches are provided in Appendix A.

5
2. Project Requirements [AS PER FYP1 MID REPORT]

2.2 Functional Requirements

This section describes the functional requirements of the system expressed in the natural
language style. This section is typically organized by feature as a system feature name
and specific functional requirements associated with this feature.

2.2.1 Module 1

Following are the requirements for module 1:

1. FR1

2. FR2

2.2.2 Module 2

Following are the requirements for module 2:

1. FR1

2. FR2

2.3 Non-Functional Requirements

This section specifies nonfunctional requirements. These quality requirements should be

specific, quantitative, and verifiable. The following are some examples of documenting
guidelines.

2.3.1 Usability

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

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

6
 2.3 Non-Functional Requirements

2.3.2 Performance

State specific performance requirements for various system operations. If different func-
tional 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 con-
nection.

7
Chapter 3

System Overview [AS PER FYP1 MID

REPORT]

Give a general description of the functionality, context, and design of your project. Pro-
vide any background information if necessary.

3.1 Architectural Design

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 the initial design stage, create a Box and Line Diagram for a simpler representa-
tion of the systems.

• After finalizing the architecture style/pattern diagram (MVC, Client-Server, Lay-

ered, Multi-tiered), create a detailed mapping of modules/components to each part
of the architecture.

To view examples of box and line diagrams and architecture styles, see Appendix C.

9
3. System Overview [AS PER FYP1 MID REPORT]

3.2 Data Design

Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed, and organized.
List any databases or data storage items.

3.3 Domain Model

The domain model is a conceptual representation of the various entities, their attributes,
and the relationships between them within the system. It serves as a bridge between
the requirements and the design of the software, providing a clear understanding of the
business domain and how it interacts with the system being developed.
A domain model typically includes key components such as:

• Entities: These are the primary objects within the domain that hold data and repre-
sent real-world concepts. Each entity is defined by its attributes and behaviors.

• Attributes: Characteristics or properties of the entities that define their state. For
example, a "Customer" entity might have attributes such as customerID, name,
email, and address.

• Relationships: These illustrate how different entities interact with each other. Re-
lationships can be one-to-one, one-to-many, or many-to-many, depending on how
entities are associated.

• Associations: Connections between entities that help clarify their interdependen-

cies. For instance, a "Product" may be associated with a "Category," indicating the
type of product it belongs to.

By constructing a domain model, developers can better understand the system’s require-
ments, facilitate communication among stakeholders, and guide the subsequent design
and implementation phases. It also aids in identifying potential issues early in the devel-
opment process, ensuring a more robust architecture.
An example of a domain model for an online shopping system is provided in Appendix
B.

10
 3.4 Design Models [UPTO THE CURRENT ITERATION ONLY]

3.4 Design Models [UPTO THE CURRENT ITERATION

ONLY]

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
• Class Diagram
• Class-level Sequence Diagram
• [OPTIONAL] State Transition Diagram (for the projects which include event handling
and backend processes)

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/sinks and data stores.)
• System-level Sequence Diagram
• [OPTIONAL] State Transition Diagram (for the projects which include event handling
and backend processes)

Examples of above diagrams are given in Appendix D.

11
Chapter 4

Implementation and Testing [UPTO

THE CURRENT ITERATION ONLY]

Give a general description of the functionality, context, and design of your project. Pro-
vide any background information if necessary.

4.1 Algorithm Design

Mention the algorithm(s) used in your project to get the work done with regards to major
modules. Provide a pseudocode explanation regarding the functioning of the core fea-
tures. Following are few examples of algorithms/pseudocode.

Example:

Figure 4.1: Example Of Algorithm Design

13
4. Implementation and Testing [UPTO THE CURRENT ITERATION ONLY]

4.2 External APIs/SDKs

Describe the third-party APIs/SDKs used in the project implementation in the following
table. Few examples of APIs are provided in the table.
API and version Description Purpose of usage API endpoint/function/class used
Stripe (version 2020-08-27) Credit Card payment integration Sandbox used orders payment stripe.paymentMethods.create
Cloudinary Image and Video management Uploading Product Images https://api.cloudinary.com/v1

4.3 Testing Details

Once the system has been successfully developed, testing has to be performed to ensure
that the system working as intended.

4.3.1 Unit Testing

Each unit test is designed to test a specific function or method independently from other
components, helping to identify issues directly related to the functionality being tested.
Following is the example of Unit testing:

Figure 4.2: Example for Unit Testing

14
Bibliography

[1] A Kolyshkin and S Nazarovs. Stability of slowly diverging flows in shallow water.
Mathematical Modeling and Analysis, 2007.

15
Appendix A

Appendices

A.1 Appendix A

A.1.1 Use Case Diagram example (Online Shopping System)

Figure A.1: Use Case Diagram for the Online Shopping System

17
A. Appendices

A.1.2 Detail Use Case Example

Figure A.2: Detail Use Case Example

18
 A.1 Appendix A

A.1.3 Event-Response Table for a Highway Intersection

Figure A.3: Example of Event Response Table

19
A. Appendices

A.1.4 Story Board Example For Android App

Figure A.4: Example of Story Board

20
 A.2 Appendix B

A.2 Appendix B

A.2.1 Domain Model Example For Online Shopping

Figure A.5: Domain Model Example For Online Shopping Application

21
A. Appendices

A.3 Appendix C

A.3.1 Box And Line Example For Online Shopping

Figure A.6: Box and Line Diagram For Online Shopping Application

22
 A.3 Appendix C

A.3.2 Architecture Pattern Example For Online Shopping

Figure A.7: Architecture Pattern For Online Shopping Application

23
A. Appendices

A.4 Appendix D

A.4.1 Activity Diagram

Figure A.8: Activity Diagram For Online Shopping Application

24
 A.4 Appendix D

A.4.2 Class Diagram

Figure A.9: Class Diagram For Online Shopping Application

25
A. Appendices

A.4.3 Sequence Diagram

Figure A.10: Sequence Diagram For Online Shopping Application

A.4.4 State Transition Diagram

Figure A.11: State Transition Diagram For Online Shopping Application

26
 A.4 Appendix D

A.4.5 Data Flow Diagram

Software Design Description for <Project> Page 21

Data Flow Diagram

Data flow diagram symbols, symbol names, and examples

Figure B-5 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.

Example

Figure B-6 Context diagram DFD for an order system.

27
A. Appendices

Software Design Description for <Project> Page 22

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.
Example

Figure B-7 Diagram 0 DFD for the order system.

Step 3: Draw the Lower-Level Diagrams:

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.
Leveling Example

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

28