NGO MANAGEMENT

SOFTWARE
SOFTWARE ANALYSIS AND DESIGN (SA/SD) DOCUMENT

BUDDHA PRAKASH (12CS30043)

A GOPI

23

rd

V<1.0>
March , 2014
1

Table of Contents
1.) Introduction3
1.1) Purpose...3
1.2) Scope ..3
1.3) Glossary .3
1.4) References. .3
1.5) Feasibility Study..4
2.) Requirements Specification....5
2.1 Functional Requirements.5
2.3 Non functional Requirements...8
3.) Detailed Design....9
3.1

Global System Architecture..9

3.2

Software Platform ............9

3.3

Hardware Platform10

3.4

Communication Platform.10

3.5

Database Design...10

3.6

User Interface.. .11

3.7

Class Design.12

3.8 Sequence Diagrams.......................................................................13

3.9

Collaboration Diagrams.17

4.) Concluding Report ...18

1. Introduction
1.1) Purpose
The purpose of the document is to provide detailed design specifications for the NGO Management Software
(NMS). It analyzes the stakeholders and identifies the problem and feasibility of software. It then explains
different design viewpoints using various diagrams thus elaborating on the planned implementation.

1.2) Scope
NMS is intended as a tool for simplifying the task of management of a NGO. It automates the
functioning of the NGO.
It does not build upon any previously existing similar software and is not a part of a larger
project in itself. Apache WebServer and MySQL constitute its software dependencies.
For a more detailed description of the design goals and a brief of the overall functions, refer to
Section 1.2, NMS SRS.

1.3) Glossary
Term
Definition
1
2
3
4
5
6

NMS : NGO Management Software

User : Donor/Manager.
SRS : Software Requirement Specification
API : Application Programming Interface.
Database: Collection of similar data.
Server: Link which handles user request and provide them with relevant data.

1.4) REFERENCES.

[IEEE] The applicable IEEE standards are published in IEEE

Standards Collection, 2001 edition.
Fundamentals of Software Engineering by Rajib
Mall. www.wikipedia.org
1.5) FEASIBILITY STUDY:

1.5.1) Problem and its Scope

The software designed here is NGO management Software (NMS) . This software
basically registers few problem described here:
1 Maintaining the list of students who are currently supported by the NGO.
2 Information regarding the amount of money needed by the NGO to continue its
operation in the coming year.
3 Maintaining the data about the performance of students in exams.
4 Contact the donors for money.
5 Receiving donations like bags,dresses,books etc.
6 Maintaining a record of all the expenditure made in the present year.
Stakeholders: The major stakeholder is the manager of the NGO.NMS will be mainly
used by the manager of the NGO to conduct the various work of the NGO.

1.5.2) TECHNICAL FEASIBILITY

1
2
3
4

NMS requires a web server for its functioning which can be easily arranged for.
NMS would generate the outputs at desired time.
NMS can process data of large number of students at a fair speed.
TMS is smoothly connected to email system and can send request to email system via server
to send messages to executives. Thus , the TMS is technically feasible to a large extent.

1.5.3) ECONOMIC FEASIBILITY

The benefits that we receive from NMS include reduction in human labor. By automating all
the tasks we remove the need of having volunteers doing the functions of NGO.

1.5.4) OPERATIONAL FEASIBILITY

NMS is very easy to operate and user friendly software which dont require any special skill
set. It just require to create ID and enter the details of appointment to schedule on request ,
for which a simple form is to be filled. Thus NMS has great operational feasibility.

2.) REQUIREMENT SPECIFICATION

Functional Requirements: There are certain use cases depicted in use case diagram and their
functionalities. These form the basic requirement and processes while operating the software.

2.2) Non- Functional Requirements.

2.2.1) Error handling
NMS product shall handle expected and non-expected errors in ways that prevent loss in
information and long downtime period.

2.2.2) Performance Requirements

Responses to view information shall take no longer than 5 seconds to appear on the screen.
2.2.3) Safety Requirements
System uses the system memory and resources in an controlled manner So the software
won't have any safety issues.
2.2.4) Security Requirements
System will use secured database
Normal volunteers can just read information but they cannot edit or modify anything
except their personal and some other information.
System will have different types of users and every user has access constraints.
3.) DETAILED DESIGN

3.1) Global System architecture

A 3 tier architecture is chosen for NMS . Stakeholders form the 1 st tier which sends requests
to the software (2nd tier ) which process the data and stores it in data base (3 rd tier) , and is
connected to web server which receives and sends request back to stakeholder.

Database
Web
Server

3.2) SOFTWARE PLATFORM

The overall software is best modeled in Object-oriented architecture. In this way, the individual

w
methods may be implemented and
encapsulated to prevent interference. It
also provides abstraction so

two sets of entities may interact with

each other with ease.
Also, the software must broadly a
event based design and therefore
it is best to use a language which
supports event handling.
For this and other purposes
described above, PHP is one
of the best candidates to
implement the software.
1 Software Configurations

a
r
e
r
e
q
u
i
r
e
m
e

OPERATING SYSTEM :
WINDOWS 98, XP AND
ABOVE ,LINUX.

LANGUAGE : PHP.

DATABASE: MySQL
3.3) HARDWARE PLATFORM

i
m

o
c

M
b

:
Hard Disk : 20 GB
P

s
c

e
n

M
H

z
1

A
M

:
c

o
r

a
m

n
i

t
o

2
2

M
o

s
.

Modem, WAN LAN, Ethernet CrossCable.

e
y
b
o

3.4) COMMUNICATION PLATFORM

TMS would be internally connected to email
server and would send request to send email to
executives.

3.6) USER INTERFACE I/O

Few User interfaces are depicted below.
1)Login:

Update Expenditure:

3.7) Class Diagram

4.) CONCLUDING REPORT

o
f
The
SASD

docume h
e
nt
extende
upon d
a
the
d

NMS

SRS

and

discusse a
d

the s

various e
function
s in the w
form of
a
DFD
s
and
Structur
e
Charts.

d
e
t

l
e

e
s

g
n

i
r

e
n

f
a
E

r
n

e
c

i
e
d