‫كلية العلوم الحاسوبية والمعلوماتية‬

F a c u l t y o f C S I

PROJECT TITLE

Students:
Name of Student 1 11111111
Name of Student 2 22222222
Name of Student 3 3333333

Supervisor:
Dr. Name of Supervisor

A project report submitted in partial fulfillment of the requirements

for B.Sc. degree in Computer Information System.

Amman - Jordan
2020/2021
 Table of Contents

Certificate-------------------------------------------------------------------------------vi
Dedication-------------------------------------------------------------------------------vii
Acknowledgement---------------------------------------------------------------------viii
Abstract ---------------------------------------------------------------------------------ix
Table of Contents----------------------------------------------------------------------ii
List of Figures--------------------------------------------------------------------------iv
List of Tables---------------------------------------------------------------------------v
List of Definitions, acronyms, and abbreviations

CHAPTER ONE
INTRODUCTION------------------------------------------------------------------------1
1.1 Project Background----------------------------------------------------------1
1.2 Problem Statement-----------------------------------------------------------1
1.3 Project Aim and Objectives-------------------------------------------------1
1.4 Project Motivation
1.5 Project Scope------------------------------------------------------------------1
1.6 Tools and Technologies Used----------------------------------------------1
1.7 Project Limitations and Delimitations-------------------------------------1
1.8 Project Plan and Schedule---------------------------------------------------1
1.9 Outline of the Project--------------------------------------------------------1

CHAPTER TWO
EXISTING AND PROPOSED SYSTEMS----------------------------------------2
2.1 Introduction-------------------------------------------------------------------2
2.2 Existing Systems-------------------------------------------------------------2
2.3 Proposed System-------------------------------------------------------------2
2.3.1 Product Perspective
2.3.2 Product Functions
2.3.3 User Characteristics
2.3.4 Constraints
2.3.5 Assumptions and Dependencies
2.4 Feasibility Study for the Proposed System-------------------------------2
2.4.1 Competition
2.4.2 Intended Market Environment
2.4.3 Possible Solutions
2.4.4 Evaluation Criteria
2.4.5 Identifying the Most Feasible Solution
2.4.6 Critical Risk Factors
2.4.7 Conclusion
2.5 SDLC for the Proposed System--------------------------------------------2
2.5 Others--------------------------------------------------------------------------2
 ii

CHAPTER THREE
SYSTEM ANALYSIS AND DESIGN---------------------------------------------------3
3.1 System Analysis--------------------------------------------------------------3
3.1.1 Requirement Elicitation Techniques---------------------------------3
3.1.2 Specific Requirements
3.1.2.1 External Interfaces
3.1.2.2 Functional Requirements
3.1.2.3 Design Constraints
3.1.2.3 Non-Functional Requirements
3.1.3 DFDs---------------------------------------------------------------------3
3.2 System Design ---------------------------------------------------------------3
For Examples:
3.2.1 ER-Diagram------------------------------------------------------------3
3.2.2 Database Schema (Mapping) for ERD-----------------------------3
3.2.3 Class Diagram
3.2.4 Use Case Diagram ----------------------------------------------------3
3.2.5 Activity Diagram------------------------------------------------------
3.2.6 Sequence Diagram

CHAPTER FOUR:
SYSTEM IMPLEMENTATION---------------------------------------------------------4
4.1 Programming Languages----------------------------------------------------4
4.1.1 Justification for Using (for Example: ASP.net)------------------4
4.1.2 Justification for Using (for Example: SQL Server)--------------4
4.2 Implementation---------------------------------------------------------------4
4.2.1 Sample of Forms------------------------------------------------------4
4.2.2 Sample of Reports-----------------------------------------------------4
4.2.3 Pseudo Codes----------------------------------------------------------4

CHAPTER FIVE:
SYSTEM EVALUATING AND TESTING----------------------------------------------5
5.1 Testing Plans-----------------------------------------------------------------5
5.2 Types and Steps of Testing -----------------------------------------------5
For Examples: (Inspection testing, Desk checking testing, Unit testing,
Integration testing, System testing, …)

CHAPTER SIX:
THE CONCLUSIONS-------------------------------------------------------------------6
6.1 Conclusion---------------------------------------------------------------------6
 iii

6.2 Future Work-------------------------------------------------------------------6

Appendix-------------------------------------------------------------------------------7
A: System Installation -----------------------------------------------------------7
B: if there is any-------------------------------------------------------------------7
References------------------------------------------------------------------------------9
 iv

List of Figures

Figure 1: Title of the figure-----------------------------------------------------------1

Figure 2: Title of the figure-----------------------------------------------------------1
Figure 3: Title of the figure-----------------------------------------------------------1
Figure 4: Title of the figure-----------------------------------------------------------1
Figure 5: Title of the figure-----------------------------------------------------------1
Figure 6: Title of the figure-----------------------------------------------------------1
Figure 7: Title of the figure-----------------------------------------------------------1
Figure 8: Title of the figure-----------------------------------------------------------1
Figure 9: Title of the figure-----------------------------------------------------------1
Figure 10: Title of the figure---------------------------------------------------------1
Figure 11: Title of the figure---------------------------------------------------------1
Figure 12: Title of the figure---------------------------------------------------------1
Figure 13: Title of the figure---------------------------------------------------------1
Figure 14: Title of the figure---------------------------------------------------------1
 v

List of Tables

Table 1: Title of the table-------------------------------------------------------------1

Table 2: Title of the table-------------------------------------------------------------1
Table 3: Title of the table-------------------------------------------------------------1
Table 4: Title of the table-------------------------------------------------------------1
Table 5: Title of the table-------------------------------------------------------------1
Table 6: Title of the table-------------------------------------------------------------1
Table 7: Title of the table-------------------------------------------------------------1
Table 8: Title of the table-------------------------------------------------------------1
Table 9: Title of the table-------------------------------------------------------------1
Table 10: Title of the table-----------------------------------------------------------1
Table 11: Title of the table-----------------------------------------------------------1
Table 12: Title of the table-----------------------------------------------------------1
Table 13: Title of the table-----------------------------------------------------------1
Table 14: Title of the table-----------------------------------------------------------1
 vi

Certificate

It is certified that project report has been prepared and written under my direct
supervision and guidance. The project report is approved for submission for its
evaluation.

Dr. Name of the Supervisor

 vii

Dedication

Dedication Dedication Dedication Dedication Dedication Dedication

Dedication Dedication Dedication Dedication Dedication Dedication
Dedication Dedication .

Dedication Dedication Dedication Dedication Dedication Dedication

Dedication Dedication Dedication .

Names of the Team Project

 viii

Acknowledgement

I would like to thank Mr. A and Mr. B for the efforts that they provided for our
team. I would like to thank Mr. A and Mr. B for the efforts that they provided for
our team. I would like to thank Mr. A and Mr. B for the efforts that they provided
for our team. I would like to thank Mr. A and Mr. B for the efforts that they
provided for our team. I would like to thank Mr. A and Mr. B for the efforts that
they provided for our team.

Names of the Team Project

 ix

Abstract

Abstract is similar to the abstract of a research paper but more thorough

(advisable length is 1-2 pages). It briefly revisits the content of the thesis,
including the motivation for this work, novelty with respect to the previous work,
problem definition, methodology, results and conclusions.
 1

CHAPTER 1

INTRODUCTION

1.1 Project Background

Consider the following before starting up your project:

 Assess the demand for your idea: To see if there’s a good chance to sell
the system you want to develop.
 Assess the competition: To know if there's a demand for your business
idea or service, you also need to know who you are up against.
A general introduction providing an overview of the topic, problem statement
and the project description followed by an adequate scholarly context for
subsequent chapters.

For example:
The purpose of the …is to ….
The system should assist ….

1.2 Problem Statement

One of the most important goals of any problem statement is to define the
problem being addressed in a way that's clear and precise. The 5 'W's - Who,
What, Where, When and Why – Can help you in identifying and writing the
problem statement:
Who - Who does the problem affect? Specific groups, organizations, customers,
etc.
 2

What - What are the boundaries of the problem, e.g. organizational, work flow,
geographic, customer, segments, etc. - What is the issue? - What is the impact of
the issue? - What impact is the issue causing? - What will happen when it is
fixed? - What would happen if we didn’t solve the problem?

When - When does the issue occur? - When does it need to be fixed?

Where - Where is the issue occurring? Only in certain locations, processes,

products, etc.

Why - Why is it important that we fix the problem? - What impact does it have
on the business or customer? - What impact does it have on all stakeholders, e.g.
employees, suppliers, customers, shareholders, etc. Each of the answers will help
to zero in on the specific issue(s) and frame the Issue Statement. Your problem
statement should be solvable. That is, it should take a reasonable amount of time
to formulate, try and deploy a potential solution.

1.3 Project Aim and Objectives

List the project aim as well as objectives.

For example:
This project tries to fulfill the following objectives:
1.4 Project Motivation
Explain why you chose this project. Why is it important for the group? Does it
enhance job skills? Does it satisfy some interests? Your problem statement can
guide you in identifying the specific contribution of your study. You can do this
by observing a one-to-one correspondence between the statement of the problem
and the motivation of the study. Write the significance and motivation of the
project by looking into the general contribution of your project, such as its
importance to the market, then proceed downwards—towards its contribution to
 3

individuals
1.5 Project Scope
In this subsection:
(1) Identify the software product(s) to be produced by name
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified, including
relevant benefits, objectives, and goals
(4) Be consistent with similar statements in higher-level specifications if
they exist

This should be an executive-level summary. Do not enumerate the whole

requirements list here.

For example:
This project applies only to …...
This project is not concerned with …..

1.6 Tools and Technologies Used

This section does not state specific requirements. Instead, it describes the tools
and technologies (hardware and software) you used along with the version and
discuss them later in chapter 4.

1.7 Project Limitations and Delimitations

Limitations are influences that you cannot control.   They are the shortcomings,
conditions or influences that cannot be controlled by the researcher that place
restrictions on your methodology and conclusions. Any limitations that might
influence the results should be mentioned.

When considering what limitations there might be in your investigation, be

thorough.  Consider all of the following:

 your analysis.
 the nature of self-reporting.
 the instruments you utilized.
 The sample
 The available technology
 time constraints.
 Restriction of design options
 Conditions imposed on the development process
 Regulations and imposed standards
 4

Delimitations are choices made by the researcher which should be

mentioned. They describe the boundaries that you have set for the study.
This is the place to explain:

 the things that you are not doing (and why you have chosen not to
do them).
 the literature you will not review (and why not).
 the population you are not studying (and why not).
 the methodological procedures you will not use (and why you will
not use them).

1.8 Project Plan and Schedule

Estimate a schedule for the project. Include major activities (how long),
milestones (when), and deliverables (what).
Estimate the effort required for each deliverable. Schedule time and people for
each deliverable. Produce a task allocation and a personal schedule for each
project member for the remainder of the project. This information could be
presented using Gantt chart and network diagram.

Figures for Gantt and Network Diagram

1.8 Outline of the Project

You should write here a little description for coming chapters and their sub
sections.

This section states verbally without numbering or bullet points the contents of the
following chapters. (The rest of this report is organized as follows … chapter 1
consists of …).
 5

CHAPTER TWO

EXISTING AND PROPOSED SYSTEMS

2.1 Introduction

Write a brief introduction that includes the general structure of this chapter. This
chapter tells the requirements in plain English for the consumption of the
customer. Chapter 3 will contain a specification written for the developers.

2.2 Existing System

You should write here the overall problems, disadvantages, and weakness of
existing systems as well as the advantages.

2.3 Proposed System

The proposed system should provide and overall solution approach. This section
does not state specific requirements. Instead, it provides a background for those
requirements, which are defined in Chapter 3, and makes them easier to
understand. Section 2.3 will give an overview of the whole system. You should
 6

write here the Advantages, disadvantages, and weakness or the proposed system.

For example:

This system allows stakeholders to…..

The system will display…..

The system will help ……

The system provides information about ….

2.3.1 Product Perspective

The system should be explained in its context to show how the system interacts
with other systems.

Put the product into perspective with other related products. If the product is
independent and totally self-contained, it should be so stated here. If you are
building a real system, compare its similarity and differences to other systems in
the marketplace. If you are doing a research-oriented project, what related
research compares to the system you are planning to build.

A block diagram showing the major components of the larger system,

interconnections, and external interfaces can be helpful. This is not a design or
architecture picture. It is more to provide context, especially if your system will
interact with external actors. Let the design chapter presents the internals.
Figure 1, shows an example of block diagram
 7

2.3.2 Product Functions

Provide a summary of the major functions that the system will perform.
For clarity:
(1) The functions should be organized in a way that makes the list of
functions understandable to the customer or to anyone else reading the document
for the first time.
(2) Textual or graphic methods can be used to show the different functions
and their relationships. Such a diagram is not intended to show a design of a
product but simply shows the logical relationships among variables.

Describe the functionality of the system in the language of the customer. What
specifically does the system that will be designed have to do? Drawings are
good, but remember this is a description of what the system needs to do, not how
you are going to build it. (That comes in the design chapter).
2.3.3 User Characteristics
 8

This subsection describes what type of stakeholders that will use the system and
what functionality is available for each type.

Describe those general characteristics of the intended users of the product

including educational level, experience, and technical expertise. Do not state
specific requirements but rather provide the reasons why certain specific
requirements are later specified in section 3.

What is it about your potential user base that will impact the design? Their
experience and comfort with technology will drive UI design. Other
characteristics might actually influence internal design of the system.

For Example:
The users of the system are:
Level of Users’ Computer Knowledge
Level of Users’ Business Knowledge
Frequency of Use

2.3.4 Constraints

In this subsection, the constraints and assumptions for the system should be
presented. This subsection is related to the project scope as well as limitation and
delimitation of the project.
Provide a general description of any other items that will limit the developer's
options. These can include:

(1) Regulatory policies

(2) Hardware limitations (for example, signal timing requirements)
(3) Interface to other applications
(4) Parallel operation
(5) Audit functions
 9

(6) Control functions

(7) Higher-order language requirements
(8) Signal handshake protocols (for example, XON-XOFF, ACK-NACK)
(9) Reliability requirements
(10) Criticality of the application
(11) Safety and security considerations

This section captures non-functional requirements in the customers language. A

more formal presentation of these will occur in Chapter 3.

For example:
The system will support ….
The system will not allow ……

2.3.5 Assumptions and Dependencies

List each of the factors that affect the requirements stated in your project. These
factors are not design constraints on the software but are, rather, any changes to
them that can affect the requirements in the project. For example, an assumption
might be that a specific operating system would be available on the hardware
designated for the software product. If, in fact, the operating system was not
available, the requirements in your project would then have to change
accordingly.
This section is catch-all for everything else that might influence the design of the
system and that did not fit in any of the other categories.

For example:
This system relies on ……
The system must have a satisfactory interface and ……
 10

For example, read this assumption written for an application developed for
mobile:
“One assumption about the product is that it will always be used on mobile
phones that have enough performance. If the phone does not have enough
hardware resources available for the application, for example the users might
have allocated them with other applications, there may be scenarios where the
application does not work as intended or even at all.”

2.4 Feasibility Study for the Proposed System

Based on what you know, you need to draw conclusions about the feasibility of
your project, based on the time and work force available, the level of ambition of
your project (based on project features), and the skill set available in your group.
analyze and justify the project in terms of technical feasibility, business viability
and cost-effectiveness.

2.4.1 Competition
Describe direct and indirect competition. Describe what is unique about your
product/service compared to the competition. Compare the proposed system
similarity and differences to other systems in the marketplace.

2.4.2 Intended Market Environment

Define and describe the target market and be clear how end users and customers
benefit. How and why would they buy the product or service. Estimate the
market size and initial targeted geographic area.

2.4.3 Possible Solutions

You need to perform an alternatives analysis and make a description of possible
solutions for your project. For example, an e-commence project might have the
 11

following solutions description:

“This project can be undertaken by the implementation of the two possible
solutions: 1) Online Shop; 2) Corporate Website. Each of the solutions is
carefully analyzed, and necessary information required for making the final
decision is available for the management team.”
2.4.4 Evaluation Criteria
Set and define evaluation criteria for possible solutions. This step of feasibility
study report writing requires you to investigate the solutions and put them against
a set of evaluation criteria. For example, you could add the following criteria to
your report:
“The possible solutions of this project are evaluated and compared by the
following criteria: 1) Concept Spec.; 2) Content Audit; 3) Technical Design
Spec.; 4) Launch Schedule & Time-frames.”

2.4.5 Identifying the Most Feasible Solution

Once the criteria are used to evaluate the solutions, your next step for writing a
feasibility study report is to determine the most economically reasonable and
technically feasible solution which lets the company 1) keep to optimal use of
project resources and 2) gain the best possible benefit. For example, your report
might include:
“After the evaluation of the possible solutions, the most feasible solution for this
project is identified and selected, so the project turns to be cost-effective, vital
and practical.”

2.4.6 Critical Risk Factors

Describe critical risks faces by your product/ service (currently or in the future).
Be sure to describe how will you mitigate each risk.

2.4.7 Conclusion
Make a conclusion by summarizing the project’s aim and stating the most
feasible solution. For example, the conclusion might be:
 12

“This project’s purpose is to develop a sophisticated and original design of the

website that will contribute to online sales increasing, attract the target
customer’s attention, and be cost-effective. The most feasible solution for the
project has been chosen and approved and now is ready for further elaboration.”

2.5 SDLC of the Proposed System

Describe the development process you followed and the reason behind the
selection of specific SDLC.   To demonstrate your mastery in software
engineering and computer science, your project should follow a standard
software development process, rather than an undefined or ad hoc process.
Generally, a process framed on the agile development philosophy works well for
graduate projects in software engineering and computer science.  If you choose
an agile process, then be sure to describe the process you followed for making
the multiple deliveries and demonstrations to your committee chair or research
group.  Doing an iterative development and making multiple deliveries is a key
practice in any agile process; if you did not do this then the process cannot be
called agile.
Some of the selection criteria or arguments that you may use to select an SDLC
are:

Is the SDLC suitable for the size of our team and their skills?
Is the SDLC suitable for the selected technology we use for implementing the
solution?
Is the SDLC suitable for client and stakeholders concerns and priorities?
Is the SDLC suitable for the geographical situation (distributed team)?
Is the SDLC suitable for the size and complexity of our software?
Is the SDLC suitable for the type of projects we do?
Is the SDLC suitable for our software engineering capability?

Figure 2, can help you in selecting the right SDLC

13
 14

CHAPTER THREE

SYSTEM ANALYSIS AND DESIGN

3.1 System Analysis

This section describes how you did requirements elicitation, conducted the
analysis, and arrived at the specified requirements.  Provide a data flow diagram
(DFD).

3.1.1 Requirement Elicitation Techniques

Explain how did you collect the requirements for your system and which
technique(s) has(have) been used. Hereunder, the most popular techniques:
 Interviews (individual dialog with a stakeholder)
 Questionnaires (a set of questions sent to a larger set of stakeholders)
 Workshops (stakeholders gather for an intensive, focused period)
 Focus Groups
 Brainstorming sessions (presenting ideas during a short, intensive session)
 Storyboarding (using a visual/graphical tool to demonstrate system
behavior)
 Role playing (each member of the group is assigned a role, usually one of
the users)
 Prototyping (developing a prototype to get feedback)
 Analysis of existing documents (extracting information from Microsoft
Word documents, e-mails, and notes)
 15

 Analysis of existing systems (gathering requirements from a system being

replaced or from systems built by the competition)
 Observation and task demonstration (watching users perform a specific
task)
 System Interface Analysis
 User Interface Analysis

3.1.2 Specific Requirements

This section contains all the software requirements at a level of detail sufficient
to enable designers to design a system to satisfy those requirements, and testers
to test that the system satisfies those requirements. Throughout this section,
every stated requirement should be externally perceivable by users, operators, or
other external systems. These requirements should include at a minimum a
description of every input (stimulus) into the system, every output (response)
from the system and all functions performed by the system in response to an
input or in support of an output. The following principles apply:

(1) Specific requirements should be written in an excellent way and should

be:
• correct
• unambiguous
• complete
• consistent
• ranked for importance and/or stability
• verifiable
• modifiable
• traceable
(2) Specific requirements should be cross-referenced to earlier documents that
relate
(3) All requirements should be uniquely identifiable
 16

(4) Careful attention should be given to organizing the requirements to

maximize readability (Several alternative organizations are given at end of
document)

Before examining specific ways of organizing the requirements it is helpful to

understand the various items that comprise requirements as described in the
following subclasses. This section reiterates section 2.3, but is for developers not
the customer. The customer buys in with section 2.3, the designers use section
3.1.2 to design and build the actual application.

Remember this is not design. Do not require specific software packages, etc
unless the customer specifically requires them. Avoid over-constraining your
design. Use proper terminology:
The system shall… A required, must have feature
The system should… A desired feature, but may be deferred til later
The system may… An optional, nice-to-have feature that may never make it to
implementation.

Each requirement should be uniquely identified for traceability. Each

requirement should also be testable. Avoid imprecise statements like, “The
system shall be easy to use” Well no kidding, what does that mean? Avoid
“motherhood and apple pie” type statements, “The system shall be developed
using good software engineering practice”

Avoid examples, This is a specification, a designer should be able to read this

spec and build the system without bothering the customer again. Don’t say
things like, “The system shall accept configuration information such as name and
address.” The designer doesn’t know if that is the only two data elements or if
there are 200. List every piece of information that is required so the designers
can build the right UI and data tables.
 17

3.1.2.1 External Interfaces

This contains a detailed description of all inputs into and outputs from the
software system.
It contains both content and format as follows:

• Name of item
• Description of purpose
• Source of input or destination of output
• Valid range, accuracy and/or tolerance
• Units of measure
• Timing
• Relationships to other inputs/outputs
• Screen formats/organization
• Window formats/organization
• Data formats
• Command formats
• End messages

(a) System Interfaces

List each system interface and identify the functionality of the software to
accomplish the system requirement and the interface description to match the
system. These are external systems that you have to interact with. For instance,
if you are building a business application that interfaces with the existing
employee payroll system, what is the API to that system that designer’s will need
to use?

(b) User Interfaces

Specify:
 18

(1) The logical characteristics of each interface between the software product
and its users.
(2) All the aspects of optimizing the interface with the person who must use
the system

This is a description of how the system will interact with its users. Is there a
GUI, a command line or some other type of interface? Are there special interface
requirements? If you are designing for the general student population for
instance, what is the impact of ADA (American with Disabilities Act) on your
interface?

(NOTE: Low Fidelity Prototype (PaperBased Sketches), Medium Fidelity

Prototype, or even Wireframe can be drawn using special tools such as:
Justmind(https://www.justinmind.com/free-wireframing-tool),
Axure(https://www.axure.com/),
Mockplus(https://www.mockplus.com/?
utm_source=promote&utm_medium=click&utm_campaign=grace)
draw.IO
(c) Hardware Interfaces

Specify the logical characteristics of each interface between the software product
and the hardware components of the system. This includes configuration
characteristics. It also covers such matters as what devices are to be supported,
how they are to be supported and protocols. This is not a description of hardware
requirements in the sense that “This program must run on a Mac with 64M of
RAM”. This section is for detailing the actual hardware devices your application
will interact with and control. For instance, if you are controlling X10 type home
devices, what is the interface to those devices? Designers should be able to look
at this and know what hardware they need to worry about in the design. Many
business type applications will have no hardware interfaces. If none, just state
“The system has no hardware interface requirements” If you just delete sections
 19

that are not applicable, then readers do not know if: a. this does not apply or b.
you forgot to include the section in the first place.

(d) Software Interfaces

Specify the use of other required software products and interfaces with other
application systems. For each required software product, include:
(1) Name
(2) Mnemonic
(3) Specification number
(4) Version number
(5) Source

For each interface, provide:

(1) Discussion of the purpose of the interfacing software as related to this
software product
(2) Definition of the interface in terms of message content and format

Here we document the APIs, versions of software that we do not have to write,
but that our system has to use. For instance if your customer uses SQL Server 7
and you are required to use that, then you need to specify i.e.Microsoft SQL
Server 7. The system must use SQL Server as its database component.
Communication with the DB is through ODBC connections. The system must
provide SQL data table definintions to be provided to the company DBA for
setup.

A key point to remember is that you do NOT want to specify software here that
you think would be good to use. This is only for customer-specified systems that
you have to interact with. Choosing SQL Server 7 as a DB without a customer
requirement is a Design choice, not a requirement. This is a subtle but important
point to writing good requirements and not over-constraining the design.
 20

(e) Communications Interfaces

Specify the various interfaces to communications such as local network

protocols, etc. These are protocols you will need to directly interact with. If you
happen to use web services transparently to your application then do not list it
here. If you are using a custom protocol to communicate between systems, then
document that protocol here so designers know what to design. If it is a standard
protocol, you can reference an existing document or RFC.

3.1.2.2 Functional Requirements

Functional requirements define the fundamental actions that must take place in
the software in accepting and processing the inputs and in processing and
generating the outputs. These are generally listed as “shall” statements starting
with "The system shall…

These include:

• Validity checks on the inputs

• Exact sequence of operations
• Responses to abnormal situation, including
• Overflow
• Communication facilities
• Error handling and recovery
• Effect of parameters
• Relationship of outputs to inputs, including
• Input/Output sequences
• Formulas for input to output conversion
 21

It may be appropriate to partition the functional requirements into sub-functions

or sub-processes. This does not imply that the software design will also be
partitioned that way.
Please refer to IBM Book section 1.4 and 6.2 for writing excellent requirements.
Follow the following for naming the functional requirements: please refer to
slides in chapter 6B (62-64)
For example:
3.2.1 Unit Registration
SRS-001 (3.2.1.1):
The system shall allow the user to register a unit.
SRS-002 (3.2.1.2):
The system shall allow the user to delete a unit if the user has chosen to drop that
unit.

3.1.2.3 Design Constraints

Specify design constraints that can be imposed by other standards, hardware

limitations, etc.
For example:
SRS-031 (3.3.1):
The system shall store and retrieve persistent data.

Note : continue numbering SRS from the last section

3.3.1 Memory Constraints

Specify any applicable characteristics and limits on primary and secondary

memory. Don’t just make up something here. If all the customer’s machines
have only 128K of RAM, then your target design has got to come in under 128K
so there is an actual requirement. You could also cite market research here for
shrink-wrap type applications “Focus groups have determined that our target
market has between 256-512M of RAM, therefore the design footprint should not
 22

exceed 256M.” If there are no memory constraints, so state.

3.1.2.3 Non-Functional Requirements

There are a number of attributes of software that can serve as requirements. It is

important that required attributes by specified so that their achievement can be
objectively verified. The following items provide a partial list of examples.
These are also known as non-functional requirements or quality attributes.

These are characteristics the system must possess, but that pervade (or cross-cut)
the design. These requirements have to be testable just like the functional
requirements. Its easy to start philosophizing here, but keep it specific.

Please refer to IBM Book section 8.2

Follow the following for naming the non- functional requirements:

Continue numbering from the previous section, suppose the last design constrains
stopped at 35 then first non functional requirement will be :

SRS-036:

Note: you do not need to specify all of them and you might need to specify other
non functional requirements.
(a) Usability
Specify the factors required to establish the required usability of the software.
Usability can include the following factors:
 Accessibility
 Aesthetics
 23

 UI Consistency
 Ergonomics
 Ease of Use

(b) Reliability

Specify the factors required to establish the required reliability of the software
system at time of delivery. If you have MTBF requirements, express them here.
This doesn’t refer to just having a program that does not crash. This has a
specific engineering meaning.
Reliability can include the following factors:
 Availability
 Robustness
 Accuracy
 Recoverability
 Fault Tolerance
 Safety
 Correctness

(c) Security

Specify the factors that would protect the software from accidental or malicious
access, use, modification, destruction, or disclosure. Specific requirements in
this area could include the need to:
• Utilize certain cryptographic techniques
• Keep specific log or history data sets
• Assign certain functions to different modules
• Restrict communications between some areas of the program
• Check data integrity for critical variables
 24

(d) Supportability

Specify attributes of software that relate to the software supportability.

Supportability can include the following factors:
 Testability
 Adaptability
 Maintainability
 Compatibility
 Configurability
 Upgradability
 Insatiability
 Scalability
 Portability
 Reusability
 Interoperability
 Compliance
 Replaceability
 Changeability
 Analyzability
 Auditability
 localizability

(e) Performance
Specify attributes of software that relate to the software performance.
Performance can include the following factors:
 Throughput
 Response Time
 Recovery Time
 Startup/Shutdown Time
 25

 Capacity
 Utilization of Resources

3.2 System Design

Describe the architectural design model and the detailed design model. Always,
discuss the alternatives considered and the rationale for the choosing the
solutions you adopted.  Describe the architectural and detailed design models in a
disciplined manner using both text and comprehensive design models, ideally
expressed in UML.  Use of UML is highly recommended over using ad hoc or
older modeling notations.  Suggested UML design model elements are: class
diagrams, interaction diagrams, structured classes, components, subsystems, and
deployment models.  Produce the model diagrams with a modern CASE tool, not
drawing tools.   Provide a comprehensive design model with sufficient design
information, not just one or two top‐ level model diagrams.   Note that to describe
a design adequately you must describe both its static view and the dynamic
view.  The static view includes elements such as: classes with inheritance and
aggregation, structured classes, interfaces, components, subsystems, and
deployment.  The dynamic view includes: activity diagrams, sequence or
communication diagrams, and the state model, when appropriate.   Remember
that, in most projects, the design model is the main aspect of your work, and it
deserves a good deal of your attention.

3.2.1 ER-Diagram

NOTE: ERD is required if your project has a database.

Figure for ER-Diagram.. for DB

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
 26

here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

Figure for Database Schema (mapping of ERD) .. for DB

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

3.2.2 Database Schema (Mapping) for ERD

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.
3.2.3 Class Diagram
Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

3.2.4 Use Case Diagram

Provide use case diagram along with the description then develop scenarios
related to the use cases.
Please refer to this link
(https://www.ibm.com/developerworks/rational/library/content/RationalEdge/
jun01/GeneratingTestCasesFromUseCasesJune01.pdf)
Also you can refer to IBM book section 7.3-7.6
3.2.5 Activity Diagram
Your text here Your text here Your text here Your text here Your text here Your
 27

text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

3.2.6 Sequence Diagram

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.
 28

CHAPTER FOUR

SYSTEM IMPLEMENTATION

Describe the overall strategy for implementation tasks, such as incremental

builds, risk mitigation measures. Discuss the reasons why you chose the specific
programming language, development tools, testing tools, and the implementation
platform.  Discuss strategies for reuse of existing products and components.   Use
of design patterns in the implementation demonstrates sophistication in the
subject matter and is highly encouraged.

4.1 Programming Languages

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

4.1.1 Justification for Using (for Example: ASP.net)

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.
 29

4.1.2 Justification for Using (for Example: SQL Server)

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

4.2 Implementation

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

4.2.1 Sample of Forms

Provide samples of forms after running your system.

4.2.2 Sample of Reports

Provide samples of reports after running your system.

4.2.3 Pseudo Codes

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here.
 30

CHAPTER FIVE

SYSTEM EVALUATING AND TESTING

Describe how testing and validation tasks were performed.  Describe the plans
and strategies used in unit testing, integration testing and system
testing.  Address regression testing.  Describe the test plans and provide test
procedures for testing the critical functions. Describe the test tools you
used.  Whenever possible, involve someone else, such as friends and colleagues,
in the testing and verification process, and include their comments and
observations. Provide test metrics, such as number of defects found, defect
density of the discovered defects, code and branch coverage metrics. Ideally
there should be an analysis describing the defect injection and discovery
characteristics, such as:  types of defects, injection phases and discovery phases.
If your project serves an external customer then you must involve end users,
selected by the customer, in the testing process.  Examples of such projects are:
community service projects, project from your place of work, or projects with an
external sponsor.  For graduate projects involving the end users in the testing
serves as an acceptable validation process.
Note that you should develop test cases based on the scenarios developed from
use cases. For more information please refer to IBM Book section 9.1 and
chapter 10 (develop test cases for non-functional requirements)

5.1 Testing Plans

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.
 31

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here.

5.2 Types and Steps of Testing

For Examples: (Inspection testing, Desk checking testing, Unit testing,

Integration testing, System testing, …)

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here.

Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here Your text
here Your text here Your text here Your text here Your text here Your text here
Your text here Your text here Your text here Your text here Your text here Your
text here Your text here Your text here Your text here Your text here.
 32

CHAPTER SIX

THE CONCLUSIONS

6.1 Conclusion

The conclusion chapter summarizes the problem you set out to solve, describe
what you have achieved, and prospect for future work.
1. Refer back to the problems you encountered and how you overcame those, or
found workarounds.  Always refer back to the main body of the thesis for the
detailed descriptions; the conclusion section should not contain detailed
descriptions of the problems or the solutions.    
2. Address how you have met the original objectives of the project (i.e. proposal
contents).   

6.2 Future Work

Discuss potential future work.

 33

APPENDIX
Use Appendices to present material that will interrupt the flow if included in the
main body of the thesis.  Typical contents of appendices include: Code, data
tables, detailed analysis and design models.  If a user manual is called for, then
provide it in an appendix

A: System Installation:

Write here the appendix if there is any. Write here the appendix if there is any.
Write here the appendix if there is any. Write here the appendix if there is any.
Write here the appendix if there is any. Write here the appendix if there is any.
Write here the appendix if there is any. Write here the appendix if there is any.
Write here the appendix if there is any. Write here the appendix if there is any.
Write here the appendix if there is any.
 34

REFERENCES

For Books:

[1] Author(s) name, “Book Name”, Edition, Publisher name, Year.

Example:

Jeffrey A. Hoffer, “Modern System Analysis and Design”, 6 th edition,

Prentice Hall, 2011.

For Papers:

[2] Author(s) name, “Paper name”, Journal name or Conference Name”, Volume,
Paper pages, Year.

Example:

R. Plamondon, S. N. Srihari, “On-line and Off-line Handwriting

Recognition: A Comprehensive Survey”, IEEE Transactions on Pattern
Analysis and Machine Intelligence, vol. 22, pp. 63–84, 2000.

For Papers URLs:

[3] Author(s) name, “Tutorial name”, Year, Some web URL or PDF URL.

Example:

Zitzewitz, Eric. “How Widespread Was Late Trading in Mutual Funds?”,

2006, http://facultygsb.stanford.edu/zitzewitz.