NGO MANAGEMENT

SOFTWARE
SOFTWARE ANALYSIS AND DESIGN (SA/SD) DOCUMENT

BUDDHA PRAKASH (12CS30043)

A GOPI
(12CS30029)

23rd
1

V<1.0>
March , 2014

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
Architecture..9
3.2
Software
.........9

Platform

System

...

3.3
Hardware
Platform10
3.4
Communication
Platform.10
3.5
Database
..10

Design.

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.4)

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

Maintaining the list of students who are currently supported by the NGO.
Information regarding the amount of money needed by the NGO to continue its operation
in the coming year.

Maintaining the data about the performance of students in exams.

Contact the donors for money.
Receiving donations like bags,dresses,books etc.
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

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

Software Configurations

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

LANGUAGE : PHP.
DATABASE: MySQL
3.3) HARDWARE PLATFORM
Minimum hardware
requirements are:
Processor : Pentium 3
630 MHz RAM : 128 Mb
Hard Disk : 20 GB
Display screen : 15
color monitor Mouse ,
keyboard : 122 keys.

Modem, WAN LAN, Ethernet Cross-Cable.

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

The SASD document extended

upon

the

NMS

SRS

and

discussed the various functions

in the form of DFD and Structure
Charts.
T
h
e
d
es
ig
n
of
th
e
d
at
a
b
as
e
w
as
d
et
ail
e
d
in
th
e
fo

r
m
of
E
R
di
a
gr
a
m
.
E
xt
er
n
al
e
nv
ir
o
n
m
e
nt
a
n
d
so
ft
w
ar
e
w
er

e
sp
ec
ifi
e
d.