Embed Size (px)
Citation preview
Functional Requirement Specification (FRS)
CARE BANGLADESH
RAOWA Complex, VIP Road, Dhaka-1206
JANUARY 11, 2017
Page 1 of 22
TABLE OF CONTENTS
FUNCTIONAL REQUIREMENT: Online Applications .................................................................. 3
User Login ............................................................................................................................................... 3
Personal Dashboard ................................................................................................................................ 3
Apps Module ........................................................................................................................................... 3
1. ADMINISTRATION........................................................................................................................ 4
1.1. User Management ............................................................................................................... 5
a. Super user Management systems ............................................................................................ 5
b. Organization user maangement .............................................................................................. 5
c. User Group Management ....................................................................................................... 5
1.2. Organizational Staff Information ......................................................................................... 5
1.3. Period/Period Type and Operational Months .................................................................... 5
1.4. System Parameters and System Administrative Management ............................................ 5
1.5. Authorization setting module ............................................................................................. 6
2. CATCHMENT AREA/GEO LOCATION COVERAGE ................................................................. 6
2.1 Catchment Area .................................................................................................................. 6
2.1.1 Service Point Management .................................................................................................. 6
2.2 Organization Information and Group ................................................................................. 7
3. PROGRAM, COMPONENT AND ACTIVITY DESIGN ............................................................... 7
3.1 Program Information Systems ............................................................................................. 7
3.2 Trainer Information Management ....................................................................................... 7
3.3 Group Management ............................................................................................................ 7
3.4 Data Element & Options Attribute ..................................................................................... 8
3.5 Purpose/ Program wise Validation ruls Managements ........................................................ 8
3.6 Smart Card Management .................................................................................................... 8
4 CENSUS & PARTICIPANT ENROLLMENT .................................................................................. 9
4.1 Household Census .............................................................................................................. 9
4.2 Participant Enrollment ........................................................................................................ 9
4.3 Participants/ Household members Validation Rules management ................................... 10
4.4 Individual Participants Enrollments different program/purpose ....................................... 10
4.5 Participants Dashboard ..................................................................................................... 11
5. CAPACITY BUILDING ACTIVITY EVENT DELIVERY ............................................................... 12
5.1 Event Schedule .................................................................................................................. 12
Page 2 of 22
5.2 Event Dashboard ............................................................................................................... 13
5.3 Event Authorization .......................................................................................................... 13
5.4 Budget Management .......................................................................................................... 13
6. SERVICE DELIVERY MODULE..................................................................................................... 13
7. TRANSFER .................................................................................................................................... 14
7.1 Distribution of Items Without Voucher ........................................................................... 14
7.2 e-Voucher ......................................................................................................................... 15
7.3 Cash Transfer .................................................................................................................... 15
7.4 Instrument Installation module. ........................................................................................ 16
7.5 Adoption/Practices ............................................................................................................ 16
8. COMMODITY ACCOUNTING & INVENTORY ....................................................................... 16
8.1 Commodity Distribution ...................................................................................................... 17
9. SURVEY MODULE ....................................................................................................................... 18
9.1 Survey module design ....................................................................................................... 18
9.2 Survey Module .................................................................................................................. 19
10. INDICATOR MODULE ............................................................................................................ 19
11. PERFORMANCE DASHBOARD .............................................................................................. 19
12. REPORT GENERATION MODULES ....................................................................................... 20
12.1 Static Reporting Module ................................................................................................... 20
12.4 Graphical reporting module .............................................................................................. 20
12.5 GIS reporting module ....................................................................................................... 20
12.6 Users Dashboard module ................................................................................................. 20
13. IMPORT AND EXPORT META DATA AND DATA.............................................................. 20
14. DATA SYNCRONIZATION BETWEEN SYSTEMS ................................................................ 20
15. PROJECT SCHEDULE MONITORING ................................................................................... 21
16. COMPLAINT MANAGEMENT SYSTEM ................................................................................. 21
FUNCTIONAL REQUIREMENT: Offline Android Apps ............................................................. 21
FUNCTIONAL REQUIREMENT: Application Hosting ................................................................ 21
FUNCTIONAL REQUIREMENT: Synchronization ...................................................................... 22
Page 3 of 22
FUNCTIONAL REQUIREMENT: Online Applications
User Login
Regardless of whether you have installed the server version of the desktop live version, you
will use a web-browser to log in to the applications. The systems should be compatible with
most modern web-browsers, although you will need to ensure that android apps can be enable
to log in systems.
Once you have started ICT based e-M&E systems, either on-line or off-line, the displayed
screen will prompt you to enter your registered user-name and password. After entering the
required information click on log-in button to log into the application. The default user name
and password may be 'admin' and ‘DFAP. They should be changed immediately upon logging
on first time.
You can select the language which you wish to display system from the "Change language"
dialog box at the bottom of the screen. Not all languages may be available.
Should you have forgotten your password, you can click on the "Forgot password?" link. You
must have informed system of your email address and the server must be properly configured
to send emails.
If you want to create your own account taking permission from administrator, simply click
"Create an account" and follow the directions.
Once you have logged into systems, refer to the specific sections in the system for the
different functionality which is available. In addition, Just click on the Profile and the click "Log
out" the top-right corner of the systems menu.
Personal Dashboard
Contents of the dashboard should be dynamic. So that user can update the contents as
required over the period and it provides a personal dashboard where user can put his/her
favorite charts, maps and reports for fast access. He can search directly from the dashboard
for analysis related to a particular subject or for other people. The dashboard features
integrate messaging functionality which lets user can communicate directly with other users.
From the dashboard he/she can view the different event status in dashboard.
Apps Module
This systems will better if it is modular base. The purpose of packaged apps is to extend the
web interface of system, without the need to modify the source code of core system itself. A
Page 4 of 22
system deployment will often have custom and unique requirements. The apps will provide a
convenient extension point to the user interface. Through apps, can complement and
customize the system core functionality with custom solutions in a loosely coupled and clean
manner.
Apps do not have permissions to interact directly with system API. Instead, apps are
expected to use functionality and interact with the system services and data by utilizing
the system Web API. A packaged app is an Open Web App that has all of its resources
contained in a zip file. It can be uploaded to a system installation directly through the user
interface at runtime. A packaged app is a ZIP file with an app manifest in its root directory.
thorough description of apps. Purpose of packaged Apps. A sample apps module is given below
1. ADMINISTRATION
Administrative module of the system should have the facility to initialize master information
for the overall system operation. Records that are to be used for operating various other
components of the system should be defined through this module including defining users and
Page 5 of 22
providing access rights to the users at different forms and data operation layers. End users,
therefore, will have limited access rights in this module.
Major part of this module is initialization which should be incorporated into the systems.
Through this feature, various master data that drives various components of the system will
be define by the administrator.
1.1. User Management
a. Super user Management systems
Super user management system is the main and major administrative module. For any system,
firstly have to create users and its different roles. This module, first time create the User role
authentication and create basic awardees organization role and assign those roles to specific
awardees. Also create the Awardees catchment area and assign those area in their own user
role. After receiving awardees users, awardees can handle their own catchment area and
modules. In all aspects, awardees can create their new role and assign user level catchment
area
b. Organization user maangement
Organizational user role and user management module shows that each organization has its
own catchment area, and the organization super user can crteate user roles for its users,
create users and assign cathment area .
c. User Group Management
User group management will help to create same type of user group. It has many functions
such as same message or notification can be sent to a group of users. On the other hand same
user role can be allocated a group of users. Diffrenet type of reports will be generated through
this module.
1.2. Organizational Staff Information
Every awardee has different set of staff for performing different activity within the
organization. System should have the facility to keep each and every staff basic information
along with others information like catchment area, digital signature, photo, etc.
1.3. Period/Period Type and Operational Months
System admin and Organization/awardees will create the period type like, July-June, April to
march financial year with has start date and end date. Also keep the Operation Month in
period table where it will keep the Period type , date and it’s flag.
1.4. System Parameters and System Administrative Management
User require all types of dynamic systems. They need system parameter settings part in
Administrative /maintenance module. In this module awardees system admin can set their CSS
Page 6 of 22
file which will give opportunities to change color of menus and they can set and select their
own logo and other profile settings.
In addition, individual awardees can set the Household (HH)ID structure and Individual
participants member ID parameters too. When new HH or Member participants add in
systems they will get new id in the same pattern.
1.5. Authorization setting module
This proposed systems organize census and different type of activities like training, meeting,
distribute seeds, etc. so this systems requir different type of authentication in different levels.
This module will review and verify all sorts of activities and then finaly will aprove the activity
events. Different user has different type authentication role. Defending on type of
authentications role, he or she can only do that part of authorization. User only will see
his/her part of authentication in the dashboard.
2. CATCHMENT AREA/GEO LOCATION COVERAGE
System should have the feature to capture information related to different operational
coverage in terms of Resources like Service Provider, Area like Food Distribution Point,
Service Site, etc. It should also have the facility to define different linkage between Resources
& Area or between 2 (Two) different area of coverage.
2.1 Catchment Area
An administrative module is catchment area management, it will be dynamic for any user of
the software. During development it will be empty but have to have provision to create and
update new catchment area by system or lead admins.
Create and define the administrative boundary, then create administrative boundary like:
Country, state, region, division, district, sub-district or so on. After that assigned catchment
area to awardees admin users and after that Only Awardees can handle his catchment area
but cannot access others boundary. In addition, user role will be define in that way that who
has assigned any District that user can work only under District level users and all task.
Awardees Users can create their own catchment area and can assign their own user in
different below level catchment area. And those user usually will link with awardees staff
member database and sometime other users too.
2.1.1 Service Point Management
Each awardees Admin user and role base users can create their own type of service point. It
is better to create a common service point type for maintaining standard and interoperability
between all awardees such as EPI center, Community clinic, School, food distribution center,
etc.
Page 7 of 22
2.2 Organization Information and Group
Organization information module will in Administrative module. In this module rols base user
will add all organizations name and there details. Those organization will organize or provide
training and othere program wise activities. This activities information will have in database.
System Admin/ awardees admin/ role base admin will create the Type of Organization and
create the Organization information details. Organization type may be NGO/ Donor/Private/
Government and details information of organization (Name of Organization, Logo, Address
and etc). In addition, create organization group by type or by area wise so that later on this
group one can use different kind of reports.
3. PROGRAM, COMPONENT AND ACTIVITY DESIGN
3.1 Program Information Systems
Program management module is a main module program information systems. It is a kind of
administrative module. Super admin will create diffrenet type of programs like Livelihood,
MCHN, DRR.etc
Each program has different type of components. Admin user can create the program specific
components and assign with program pupose. Each component has similar or different type
of attributes , so one can assign component wise attributes by components. All components
has similar type of activities or intervention such as Capacity building, transfer grants,
distrubution hardware or installation, etc. Each activity may have more attributes and Data
elements.One should Assign activity wise elements and attributes.
However, it is a major design for each and every awardees admin team. It is better to sit
together all awerdees and design their activities format. It should have standard and
interoperability for easy to report as per IPTT indicators. Major of Indicator reports will come
from these activities. So all elements and attributes have to have plan format before real time
format design in systems.
3.2 Trainer Information Management
Trainer information management will be insite program adminsitrative module, When any
kind of capacity building intervension is organized in that time the system have to store in
database of the trainer information with details like inhouse trainer or NGO’s staff or other
voulnteers. So system will keep the trainer information including his/her organization
information.
3.3 Group Management
Each catchment area has several type of participants group. In addition, non-partipants group
can make a group with participants group. Each group can attend several type of activities.
Also, Same type of group has several sub groups in one cathment area
Page 8 of 22
There can be many groups in one village such as MCHN group, Youth group, Livelihood
group, VDC group, Ward WATSAN group , water treatment and water safety plan (WSP)
group , LSP-1 and LSP-2 group, Growth Monitoring and Promotion (GMP) group with 40-45
children, Pregnant mothers(LM-32 persons), Men Care group, Engage 36 farmers in climate
smart agriculture (CSA) group, etc. Different activity event will be held under these groups.
3.4 Data Element & Options Attribute
All activities has attribute , options and data elements. Those attributes, elements have to
add and delete seperatly in program administrative module. Later, during activity design,
allocate those elements to the specific activity.
Data elements List : ANC Visits, ANC 1st Visit, ANC 2nd Visit, ANC 3rd Visit, , ANC 4th +
more visits PNC 1st Visit , PNC 2nd Visit, PNC 3rd + More visit, Name of seed, Quantity,
Hieught, Weight, LMP date, Vitamin A campain (Yes/no), Growth Monitoring Held (Yes/NO),
Youth training session held(yes/no) . All census data element will add as a data element, etc.
Options: Quantity (10,20,30), yes/no.All Census Data elemnt dropdown/ radio button will be
the options for specific data elements, etc.
Options can assign for specific data element like youth training session held is a data element
and its options is Yes/No
Attributes: Name of Participants, Father’s Name, Husband’s Name, Mother’s Name, House
hold Name, House Hold ID, Member ID, National ID card, Father National ID card, Mother
National ID, Mobile Number, all Demographic informatioon is an attrubutes.
3.5 Purpose/ Program wise Validation ruls Managements
The proposed ICT based e-M&E systems can manage the purpose /program wise validation
rules management
Census master list of members will enroll in different program purpose like MCHN,
Livelihood, etc. Each purpose/program has program validation rules or conditions which have
to fulfill to enrollment criteria under any purpose/program. For example pregnant women or
lactating women need to enroll in MCHN program. Similarly, Poor peoples will enroll in
livelihood programs. So Program/purpose module will create validation rules by awardees. If
any changes in the program rules it would be updated
3.6 Smart Card Management
System should have the capacity to facilitate printing of Smart ID Card along with QR Code
for the enrolled participants in order to track them & validate physically. System should have
the integrated QR Code scanner facility to scan QR code from the Smart Card to
Page 9 of 22
identify/search participant basic information faster hence will save time while making entries
corresponding to the respective participant(s).
Every individual member who will register in any purpose or program like IGA/MCHN, etc.
he or she will get a smart identification card. To perform this work, system requires a SMART
Card management module. It will have several parts- one is admin part, where awardees can
set content and QR of Member Smart Card. When new card create, and issue it will contain
the set contents.
After Completing Household census, Selected Household members register and enroll in
purpose group in that time, Field Facilitator usually request for Smart card for each purpose
group member. If it is a new request and members fulfill the condition of a new purpose group
member, then check if he/she full fill the all condition and issue a new card. In another way, if
anyone lost the card and request for another new card, then FF search his/her by Name,
village, purpose wise or use national identification card and find out his old card history and
recheck is he eligible for card. If it is true then issue a new card and update participant
information also keep provision to update the card lost section in database.
NOTE: Mobile based module should be incorporated to scan Smart ID Card onsite.
4 CENSUS & PARTICIPANT ENROLLMENT
Programs are implemented at the community level among the participant(s) of the program.
Participant(s) are selected through an enrollment process, which includes household visits and
screening of the eligibility of the members within the households. This module should provide
wide range of options to enroll participants and/or summaries grouped at various operation
levels and/or time span and/or enrollment categories.
4.1 Household Census
Proposed system should have the facility to have the census information which can be the
first step of participant enrollment. Household Census interface should be design in such a
way, so that user can define the control which he/she wants to use during capturing the
information related to Household/Participant. It means, interface should be dynamic control
creation facility according to set rules into the system.
4.2 Participant Enrollment
Considering the modalities of DFAM, participant enrollment process should have the flexibility
like either from census information or direct enrollment through interface. System
administrator will define the way of participant enrollment during system configuration.
Participant enrollment process should have the facility to capture participant picture during
enrollment at household (HH) visit as well as should have the facility to capture GPS
coordinates (Latitude & Longitude) for that household (HH).
Page 10 of 22
FF visits HH and
collect census
information
Different program
element will produce
list of potential
participant and FF will
finalize the list through
physical verification of
the HH
FF handovers the Smart ID
Card to the concerned
participant
Participant Smart ID Card handed
over to upazilla team office
Print Smart ID Card for
the participant and reprint
sequence is shown on the
card
Only one reprint
request can be
submitted at a time
Frontline Staff
submits re-print
request for the lost
cards thru system
using Smartphones
System will generate
unique participant ID
considering the defined
set rules of ID
After finalization of participant list FF will do
enrollment through online/offline interface &
System will validate participant info that has
· met beneficiary criteria
· met age-specific cut offs/ranges etc
· met catchments service site, Village, HH etc
· are made within a valid reporting period
Participant Enrollment Process
Administrative Controls Accounting Controls
Enrollment
DEO/FF will
update census
information
through offline/
online interface
DEO – Data Entry Operator FF – Field Facilitator HH - Household
Based on census and household survey, awardees record all information of households and
register memeber of households in the systems.
FFP technical and role base user prepare the household census questionaries’ and scheduled
for census and push it to Filed facilitator or roles base user dashboard. If a new census in area
or village assign census facilitator and field facilitator conduct the census. After that add the
census questionnaire answers in systems. And then register household data and the members
in systems structure. Households (HHs) and Member ID will update as per admin panel
member and HH ID setting structure. At the end of the census there will be census report
and upload all required documents to each census event. In-migrants and out-migrants event
may happen then update information in the systems. In case of newborn or death in the
catchment area, filed facilitator collects and updates the information. Those households and
members deactivate by flags or keep separate database table. In addition those members
information will change in every program they enroll. And a message will go to all defined
user dashboard by sms or email or user dashboard flag.
NOTE: Mobile based module should be incorporated to capture records onsite as well as
web based interface should be there to operate in case as a backup process.
4.3 Participants/ Household members Validation Rules management
Systems may require different validation rules. So the proposed ICT based e-M&E systems
require validation rules module
4.4 Individual Participants Enrollments different program/purpose
Master list of census members will be enrolled by program/purpose wise. Each
program/purpose has validation rules to enroll for different program/purpose
Technical team can create the program and set the rules. Field facilitator or role based
member first select the catchment area and all registered members comes from this area.
Then they will select any purpose. Now selected members of household can automated check
Page 11 of 22
the specific conditions and will enroll in purpose/program. The usual program rules are
Female, Husband name and LMP date for LW and PW women. And under 2 children require
DOB, Father and Mother name. For enrollment in Livelihood program he or she have some
wealth information. For example, for a pregnant woman need LMP date, AGE or DOB for
age? DOB essential is case of Growth Monitoring.
4.5 Participants Dashboard
Every person who will be registered in systems will have a dashboard. To get a dashboard for
a person, Role base user have to select catchment area and program/purpose or any activities.
The participants list will show in window. If select one participant and click on it, this will
show the selected participant dashboard. The dashboard will show the selected person
demographic information, from his/her catchment area and service point. The dashboard will
further show enrolled program and its activities s status. Moreover, relationship will show
with other participants, like, information of family members such as mother, father, brother
and sister. A complete profile of a participant will show in dashboard. Notification information
will show in his/her dashboard.
Unique Identification Number for Households and Participants
Various program elements will likely to have participants at the community level. Participants
will be delivered various services. Participants need to be enrolled based on eligibilities to
receive services. A program can have participants of different criterion. Tracking of enrolled
participant electronically is one of the major requirements. Participant will be tracked with
unique identification numbers.
Proposed system should allow to define the rules to generate unique identification number
for both household and participant. Example of creating ID are given below, but it should be
parameterized to define the rules for creating this ID.
Assign Program Element for Enrolled Participant
Once member(s) are enrolled as participant under specific program element, he/she can be
then assign to one or more other program elements e.g. participant enrolled under Purpose
1 and he/she wants to have service(s) from purpose 2. Therefore, one participant will not be
enrolled more than once. However, provision will be to assign one or multiple program
elements to that participant following the enrollment protocol.
NOTE: Mobile based module should be incorporated to capture records onsite as well as
web based interface should be there to operate in case as a backup process.
Dynamic Framework to Accommodate Enrollment Parameters
Proposed system should have a dynamic framework to accommodate registration parameters
for which primary data will be captured. Enrollment parameters will be merged into the
framework based on consultation with the program team or based on agreed upon provision
Page 12 of 22
determined by the program implementation requirements. System administrator should have
the facility to define enrollment parameters to merge into the framework.
Participant Listing, Searching of Beneficiary
System should have the features to view or download list of participant for given program
element or criteria. Also should have the options to filter cases overlapping into multiple
programs. In addition to that there will be provision to search beneficiaries with name or IDs.
Dropout of Participants
System should have the method to formulate projected date by when a participant will be
dropout. Otherwise there will be a default method to apply dropout protocol for the enrolled
participants. If the dropout is not observed automatic then provision should be to drop a case
with a reason, where list of reasons will be made available by the system administrator upon
request from the field team.
NOTE: Mobile based module should be incorporated to capture records onsite as well as
web based interface should be there to operate in case as a backup process.
Staff Catchment on Making Changes over Primary Data.
Not everyone will be allowed to make entries or update entries rather the system will provide
data partition mechanisms based on staff catchment area. So that to protect data from getting
it changed by unauthorized sources.
5. CAPACITY BUILDING ACTIVITY EVENT DELIVERY
Programs offers various services to the enrolled eligible participants. Every service has unique
contents for which performance are measured within a defined time period. Therefore,
service deliveries need to be tracked with each participants. Often services are delivered to
communities rather than to individuals benefiting the whole community. The proposed system
should facilitate capturing service records delivered to an individual level as well as will capture
service records delivered to the communities within a time period. This module will provide
wide range of options to list service attendance and/or summaries grouped at various
operation levels and/or time span and/or service categories.
5.1 Event Schedule
Event schedule module should be design in such a way, so that administrator can define the
group of user to prepare the event like FF/Technical Team etc. After preparing the event,
each event should be authorize through event authorization sub-module mentioned under
section 5.3. After having complete approval, frontline staff or respective staff will proceed to
have the event in place and he/she will update the participant information through tablet.
Page 13 of 22
Technical teams can prepare event schedule and these schedule will be given to the lower
user for program implementation
5.2 Event Dashboard
All the events for respective user should have the option to observe the ongoing and
upcoming event in event dashboard. So that user can take necessary initiative like update
information related to participant attendance, budget update, pre & post test score update etc.
5.3 Event Authorization
Each and every event should be authorized through respective user and this authorization
process (like who will prepare, verify and approve) should be design in administration part
under program parameter settings. Under the program parameter, According to this
definition, each and every event should be authorized before execution.
5.4 Budget Management
For the event which has the cost involvement, budget should be prepare through this sub-
module for each event. After completion of the event user will have the option to update
actual expenditure against the budget made for respective event.
6. SERVICE DELIVERY MODULE
Most program components have service delivery type activities. Growth Monitoring, Lactating
women PNC visits, Pregnant women ANC visits and other service delivery, etc.
A field facilitator or a designated person linked with a certain location will select his own
catchment area, selectr the pupose and component of purpose and select the activity. He or
she can see the sleected list or user have to select the participants from group or Purpose
wise participants list. It will show the participants upcoming event or periodwise events. If
select one participants dashboard. It will show the participants Dashboard with current
activities Formet and demographic information. In addition service service point information.
Update each participants information. If possible service delivery point Thump Scanning as a
attandance may update in particpants event wise dashboard. All activities should have Mobile
base apps so easy to update and manage the timly events.
Service Attendance Records at Individual Levels. Only enrolled eligible participant will be listed
for capturing whether or not services are delivered to them. Participants who will dropout
from the program element should not appear in the list. Individual attendance at services
delivery event will capture who will receive the services. Therefore, service coverages will be
reported over the reporting period. System should have the facility to capture GPS
Coordinates (Latitude & Longitude) for service site where participant attended to have the
service.
Page 14 of 22
NOTE: Mobile based module should be incorporated to capture records onsite as well as
web based interface should be there to operate in case as a backup process.
Records for Service Parameters at Individual Level
Proposed system should not limit service recording only just capturing attendance on an
individuals. Therefore, it should also have a framework where various service specific
parameters like Child Weight, Height etc. can be tagged to capture records corresponding to
those parameters.
NOTE: Mobile based module should be incorporated to capture records onsite as well as
web based interface should be there to operate in case as a backup process.
· Training Participants
Program often offers various capacity building trainings to its staff or at community level.
Proposed system should have provision to capture records for participants at the training
events. Found sources for those trainings will be tagged while initiating a training. Over the
period system will allow program management team to make use of the data for reporting
training events, participant listing, group by fund sources, categories etc.
System should have the facility to define training event and participant list for the specific
training event. Through this event participant list, user will update the individual participant
attendance information. System should have the facility to capture GPS Coordinates (Latitude
& Longitude) for training venue where participant attended to have the training.
NOTE: Mobile based module should be incorporated to capture participant attendance
onsite as well as web based interface should be there to operate in case as a backup process and to prepare training event schedule.
7. TRANSFER
Programs offers various transfer to the enrolled eligible participants. Every transfer has unique
contents to improve participants HH & economic status. Therefore, transfer of any kind of
goods or technology need to be tracked with each participants.
7.1 Distribution of Items Without Voucher
Program often transfers different items to the participants at the community level as part of
the services. Items can be delivered without voucher. Proposed system should have provision
to group items to be distributed e.g. Tools, Seeds, and Animals etc. System should have the
facility to track and quantify distribution of those items voucher distribution modes. There
should be the facility to prepare muster roll for eligible participant under the specific
distribution schedule.
Under this module some example includes; (i) children age under two years of old will receive
micronutrient powder (MNP) (ii) As a part of IGA development activity agricultural inputs
Page 15 of 22
support such as seeds, fertilizers and cash grant distribute to participants of the DFAP
program. Also participants will receive inputs and materials for their business purpose too.
7.2 e-Voucher
Program often offers deliveries of different distributable items to the participants at the
community level as part of the services. Items can be delivered through voucher. Proposed
system should have the facility to generate e-Voucher for the participant to receive distributed
items from the selected vendor from the community. System should have the facility to
generate e-Voucher for specific participant and should send an SMS to the respective
participant mobile along with the information like Participant Unique ID, Voucher Number,
Item(s) & Quantity of the voucher and last date of redemption etc. Participant will participate
to the specific vendor with this SMS along with the Smart ID Card to redeem the voucher.
Vendor should send an SMS with the Participant Unique ID and Voucher Number regarding
the confirmation of redemption and system should send a confirmation message with
confirmation number to the vendor phone. After having redemption voucher information,
system should produce fund transfer document to reimburse the amount through mobile
money to respective vendor and system should also have the facility to capture reimburse
information against the respective vendor after transferring the amount.
SMS preparation should be dynamic, so that user can define the contents of the SMS according
to his/her requirement.
Dissemination Redemption Reimbursement
Voucher Sent Electronically & Automatically to
Targeted Participant
Participant Receive Voucher on Phone Through SMS including Participant
ID, Voucher No, Item Description &
Quantity
Participant Redeem Vouchers at Participating
Vendor
Redemption Automatically Received by Vendor,
Retailer Automatically Reimbursed by Mobile
Money
E-Voucher
7.3 Cash Transfer
This Cash Transfer module will serve to facilitate the cash transfer facility for different activity
under the different program element like pregnant mothers will receive conditional1 cash
transfer (CCT) support under the food security program of DFAP. This cash transfer can
done by mobile banking systems or in collaboration with banks with a wide network.
1 Conditional means, based on which condition cash will transfer and this condition will be define in program parameter/rules management settings. One of the example is, if any participant receive ANC/PNC service from any designated service point, she will be eligible for cash under health and nutrition component
Page 16 of 22
7.4 Instrument Installation module.
Some instrument installment held by catchment area or by household. Like Latrine installment,
or tube well installment or repaired in any area. System should have the facility to update
information related to instrument installed within the geographical area. Role base user select
the purpose and component wise activities. Only difference is in select a cachment area. And
select any participant who is any group head or HH head. And update information in his
dashboard and in catchment area. Later one IPTT information report will come from this
Activities.
7.5 Adoption/Practices
Programs offers various transfer to the enrolled eligible participants. Every transfer has unique
contents to improve participants HH & economic status. Therefore, transfer of any kind of
goods or technology need to be tracked with each participants. Also it is required to have the
onward progress of program participant which has been made through using of different
technology and practices provided by the program. System should have the facility to capture
the participant’s ongoing status along with adopted technology as well as practices.
8. COMMODITY ACCOUNTING & INVENTORY
Inventory management will be the part of Title II food commodities which will includes the
following activities and features
· Importation
This features should allow user to update Basic info related to Life of Activity (LOA) tonnage
and equivalent monetary records. Having LOA resource info will help program team to track
and analyze resource level obtained across Fiscal Year (FY); do necessary adjustments
accordingly in order to maximize resource through forth coming Pipeline and Resource
Estimation Proposal (PREP).
· Bill of Lading
System should have the ability to capture all necessary information related to every
commodity consignments. These information will use not only to determine marine losses
but also to reconcile Fiscal Year wise resource level over the Life of Activity (LOA). Also
serves tracking of commodity stock in terms of equivalent monetary values.
· Arrival Survey
Propose system should have the feature to capture all survey related information for every in
country consignments. These information will use not only to filter marine losses but also to
account transportation losses when cargoes are reached to the destination warehouses.
Page 17 of 22
· Waybill
Waybill used for commodity dispatched ‘from’/‘to’ warehouses to capture thru the waybills
set forth for the transactions. Propose system should have the feature, so that user can make
minimum entries for updating waybill information in the system; making data updating process
easier, faster, and accurate.
· Dispatch Authorization Memo (DAM)/Dispatch Invoice (DI)
DAM/DI is the memo to dispatch commodities from the warehouse based on authorization.
Overall ‘Dispatched’ status should be updated automatically as per entries made thru waybills.
Total dispatch made thru waybills cannot exceed DAM authorized limit.
· Stacking
System should have the feature to capture all transaction of commodities related to
dispatch/receive from the specific stack under warehouse
· Reconstitution
Propose system should have the feature to capture transaction records related to commodity
reconstitution. Units that will enter as Slack/Torn or Wet/Infested thru ‘waybills’, will
automatically filter and will become visible for reconstitution. Otherwise, stack cards will filter
with relevant details.
· Loss & Adjustment Report (LAR)
System should have the feature to capture ccommodity loss records. LAR reference number
and associated entries are inserted in order to endorse increase or removal of units at
inventory level. Summaries will automatically filter based on entries made through
Reconstitution, Waybill or Stack related processes. Therefore, these will be read only.
8.1 Commodity Distribution
Programs often distributes food, nonfood items or cash, conditional upon service receipts of
the participant or unconditional for the eligible enrolled participant for which a distribution
plan is issued. This module will provide wide range of options to list selected participants
and/or summaries grouped at various operation levels and/or time span and/or service types.
Defining Distribution Schemes
Page 18 of 22
This functionalities should be designed in a way so that to specify schemes where schemes
are the unit quantities of the items at which those are distributed to the participants, for
example, 4Kgs of Oil, 5 grams of seeds etc. Schemes will be selected based on criteria which
can be changed over the period however, only one scheme will be applied over a distribution
round.
Recipient Listing
This functionalities will facilitate automatic listing of eligible recipients prior to the distribution
event. Dropout participants will be filtered out from this listing. Entries are captured from the
service recording. List will contain basic enrollment information of the participants including
identification number as well as the scheme for which beneficiaries will be receiving the items.
Participant will be linked with a distribution points, which are also linked with service delivery
points at the community level. List may or may not contain an area to capture thumb
impression of the participants. Preferred template of the recipient list will be supplied by the
program management team, which then should be integrated to the system.
Distribution Planning
Based on the recipient list, a summary of the plan containing details like total quantities to be
distributed grouped by the distribution points automatically compiled by the system whereby
other logistic information like date of distribution, name of distributor will be submitted by
the logistics team.
Distribution Recording
Provision to capture distribution records should be available in the proposed system that will
facilitate capturing of the recipient attendance records on the distribution date. Mobile based
module should be incorporated to capture records onsite. However, the web based interface
should also be there to provide provision to operate in case as a backup process.
Recipient Status Reporting
System should automatically compile the summary of the distribution status, which reports
basic comparison of post distribution status with distribution plan upon availability of the
distribution records in the system at the end of every round of distribution; hence the status
will produced at distribution point level summarized up for other aggregated level.
9. SURVEY MODULE
9.1 Survey module design
This module will have either census or survey of operational areas of awardees. Admin user
will design the survey. Then deside the survey type like census survey or sample survey. After
that design and develop the questionare with required variables. This survey tool will need to
be assigned to catchment area mentioning time period. This tool will show in dashboard of
role base users.
Page 19 of 22
9.2 Survey Module
The Survey Module will follow necessary procedure to bconduct a survey as per survey design
and schedule in catchment area by role base users mainly FF. This event will show in
authorised user dashboard. The role base user of FF will select the participants. In case of
sample survey they need to select participants by random procedure. In case of census then
select all participants from the catychment area. After selecting the participants, create new
event for this survey, And after that surveyer will prepare and update report. On completion
of data entry, the surveyer can not make any change. Role base users can analyze data the
servey and create the different reports. This survey events will meet and feed different kind
of IPTT reports.
10. INDICATOR MODULE
Different indicators are set beginning of the project based on implementation plan. Each
indicator has targets to be achieved over a specific period. Indicators are tracked to monitor
progress during implementation of the project. The system should have the facility to add
indicators as deemed necessary by the program management to oversee implementation
progress over the period. This module should facilitate management of indicators including
adding, editing, sequencing, formulating of the indicators.
Setting up Indicator Characteristics
System should allow addition of indicators, desegregations. Also setting up reporting
properties of the indicator into one of the three categories, yearly, quarterly or month. So
that, yearly indicators can be further tacked on a monthly basis if similar indicator is defined
under month frequency. This should also allow setting up sequence of the indicators to appear
on reporting.
Defining Measuring Methods for Indicators/Desegregations
Each indicator has a clear definition on how it will be counted. System should have the facility
to define SQL methods following the definition, which will trigger the results based on
available primary information in the database.
11. PERFORMANCE DASHBOARD
A dashboard which provide a gateway for the senior management team and where
appropriate external stakeholders to explore the performance of the project. Performance
summaries should be linked to the dashboard entities. Therefore, different components of
the system should be explore through hyperlinks set at the dashboard. Dashboard should not
provide any interface for making entries rather to show up the lead summaries linked with
the other components of the system functional for obtaining primary records.
There should be the graphical presentation for every summary under dashboard along with
the summary to have the better presentation of the data. Every summary table that will appear
at performance dash board, can be exported to a commonly used data format like Excel along
with the graphical presentation.
Page 20 of 22
There should be various option into the dashboard, so that user can filter the summary
according to his/her requirement like date, program element, sex of participant etc.
12. REPORT GENERATION MODULES
Different report format should be incorporate according to requirements of the projects
which has to be identify through User Requirement Specifications (URS) documents. There
one reporting modules and insite this module has 4 types report, static reports, Dynamic
tabular reports, Dynamic ghraph reports and Dynamic GIS reports.
12.1 Static Reporting Module
Static reporting module will have the facility to have user defined custom format like
Distribution plan as well as few static report like different summary under dashboard.
12.2 Tabular reporting module
This is another sub module of reporting modules. This dynamic module has different options.
One can design his/her own tabular report design.
12.4 Graphical reporting module
This is 3rd diagram of reporting modules. This dynamic module has different options. One
can design his/her own graphical report.
12.5 GIS reporting module
This is the last sub module of reporting modules. This dynamic which has different options to
create geographical reports. One can design his/her own GIS report. These reports will
show the catchment area bounadary layer and layer of service point. This is also show house
hold point layer (longitude, latitute). This is very strong visible reports for any kind of analysis.
This sub modules will genertate dynamic reports.
12.6 Users Dashboard module
This is very vital module of the proposed ICT based e-M&E systems. It has got many functions.
Under this module one can see his/her personal profile, notifications, Event list and upcoming
events, Possible type of reports, etc. The special characteristics of this module is that user
can design his own dashboard what ever he required for the management of the programs.
13. IMPORT AND EXPORT META DATA AND DATA The proposed module will enable to import or export Meta data and data within the systems
under different format like CSS, XML, HTML, Excel, etc.
14. DATA SYNCRONIZATION BETWEEN SYSTEMS Offline data either daily or any frequency of time can be synchronized with cloud server when
internet connection will be available
Page 21 of 22
15. PROJECT SCHEDULE MONITORING
Each awardee required to plan their activity each year and this module should have the facility
to monitor the activity through different time frame even by different purposes. Dashboard
of this module should facilitate to have an overview of the task to take management decision.
16. COMPLAINT MANAGEMENT SYSTEM
There should have integrated module to track the field level issues which is related to system
operation as well as any issues related to support. User will send their specific complaint
and/or suggestion(s) through interface. There should be integrated mail facility to assign the
task and onward follow-up.
FUNCTIONAL REQUIREMENT: Offline Android Apps Proposed system should have an offline android apps along with the above online
functionalities that facilitates data collection using handheld Android operated mobile devices
from remote locations where cell phone network is limited. Android apps should cover the
following modules with the same functionalities defined for online application, but not limited
to this module. Along with this functionality, offline android apps should have the capacity to
synchronize the data stored into the device to SQL Server database in central server
whenever device comes under any GSM network or got internet connectivity.
· CENSUS SURVEY & ENROLLMENT (See Functional Requirement: Online
Application - Section 3)
· SERVICE & TRAINING DELIVERY (See Functional Requirement: Online
Application - Section 4)
· TRANSFER (See Functional Requirement: Online Application - Section 5)
· DISTRIBUTION (See Functional Requirement: Online Application - Section 8)
· ROUTINE PARTICIPANT SURVEY (See Functional Requirement: Online
Application)
· SUMMARY REPORTS FOR EACH OF THE ABOVE MODULES
FUNCTIONAL REQUIREMENT: Application Hosting
Developed Application should be hosted at cloud like Microsoft Azure or any other hosting
platform as well as local server at Awardee Data Center. But there should be replication
functionality between this 2 (Two) hosting server cloud & local. So that operation can be
uninterrupted and data can be more secured during any sort of disaster. Application should
be design is such a way, so that system administrator can be able to define the replication
schedule according to his/her requirement.
Page 22 of 22
Cloud HostingLocal Hosting
FUNCTIONAL REQUIREMENT: Synchronization
As application will be developed in 2 (Two) different modalities – Online & Offline.
Synchronization features should be in-built with the system between RDBMS like SQL or
POSgreSQL which will be linked with online application and device Database which will be
used in android device. Offline module will be used to collect information from the rural area.
Due to interrupted internet connectivity, it’s required to have this module at field with
synchronization functionalities. Main database will be hosted at cloud as well as local server
of different Awardee premises. So, it’s required to have this synchronization features built-in
with the system to synchronize data between device operating at rural area and SQL in cloud.
This synchronization system can be automated as well as user operating features at device to
synchronize the data
