This Software requirement specification (SRS) provides a complete description of all the functions and specification of Mid Day Meal Scheme of Bihar Madhyan Bhojan Yojana Samiti. This SRS shall be subject to the terms of the RFP. In the event of any conflict between this SRS and the RFP requirement, the provisions of the RFP requirement shall prevail.
1. Executive Summary
This Software requirement specification (SRS) for the education department, GOB. is an outcome of requirement document provided by education department, GOB. for Real time Data Collection, Integration & MIS Generation on daily basis for Mid Day Meal Scheme.
Knowlarity engineered IBD architecture enables voice based messaging via the pre-defined IVR (Interactive Voice Recording) flow. The IVR call flow is implemented either as IBD (Inbound Dialing) voice call flow or corresponding OBD (Outbound Dialing) voice call flow. However, associated IBD and OBD voice call flow implementation is carried out based on specific customer’s requirements.
The document provides an overview of the main conceptual elements and relationships in architectural component, including candidate subsystems, components, nodes, connections, data stores, users and external systems.
The main purpose of the architecture overview diagram is to communicate a simple, brief, clear and understandable overview of voice automation system for education department, GOB.
The SOW contains the functional scope of development and deployment efforts pertaining to campaign management solution, including focusing business requirement and security considerations.
2. Voice Application Management System
Knowlarity Communications furnishes multi-modal communication services in the diversified and wide domain of mobile commerce. In addition to instant voice communication services via the scalable knowlous systems engineering architecture, Knowlarity Communications also renders advanced SMS based services.
As proposed, Knowlarity Communications will furnish Real time Data Collection, Integration & MIS Generation on daily basis for Mid Day Meal Scheme to education department, GOB. based on preliminary requirements base lined by MDM-Bihar Govt. The voice application system will automate an outbound voice call from Knowlarity voice application server on the phone of user. Following sequential instructions stated by IVR (Interactive Voice Recording) call flow, the phone user will press relevant key to furnish the related information as per the Mid Day Meal activity being carried out or by recording there relevant piece of information over the call itself . After the voice based communication session ends, the voice system will capture user-pressed DTMF (Dual Tone Multiple Frequency) key inputs and recorded messages (in case if any) and thereby stores set of captured information into intended storage location.
3. Project Scope
Real time Data Collection, Integration & MIS Generation on daily basis will be integrated with web based application module that will allow multiple application users to perform various functions. Voice application development team delineates following business-oriented functional requirements:
Overall objective of the project is to touch base with Principle/Teacher via an automated Interactive Voice Response System on a daily basis at a pre-scheduled time to collect information from them on how many meals are prepared for that particular day, that is from the overall available students how many students have been provided with the meal on daily basis. In case the meal were not provided then to capture the reason behind as to why the meal were not provided. The data collected is further used to generate reports which highlight the gaps from the delivery of Mid DAY Meal to the last mile.
4. Business Requirement:
The proposed system will provide Real time Data Collection, Integration & MIS Generation on daily basis so as to facilitate the education department, GOB for smoothly conducting the mid day meal campaign. The IVRS system will be powered by a telephony platform which is highly scalable, fault tolerant and secure. The voice application system will have following modules:
4.1 IVR’S Module:
IVR’s module largely consists of scheduled automated calls. Outbound calls will be originated to the Principle of the schools spread across entire Bihar state. The phone nos. of Head master and officials mapped by school, village, block and district will be provided by the Education Department. The IVR shall play several questions, whereby the call recipients are supposed to respond to the question using the relevant key’s available on their handset. The captured response in the form of DTMF (Dual Tone Multiple Frequency) key inputs will be stored at the intended storage location and further will be available online as Reports (Web Panel Module).
4.2 Data confirmation IVR Module:
This module will allow the system to trigger an automated call on monthly scheduled basis for data confirmation. The calls will be pushed onto the mobile numbers of the designated person (as provided by the directorate) from each village so as to confirm the data being collected and complied over the period of entire month via daily calls. In case the data as per the captured mechanism does not match with the data available with the representative the system shall prompt them to enter the data as per their records and the same shall be update in the database.
4.3 Web Panel Module:
This module Constitutes of administrative console to create and manage other web application users down the hierarchy.
- Enable application’s administrator to assign specific set of rights and permissions to intended child application users and users groups
- Facilitate administrator to view the profile and details of users in compatible report formats.
- Fetch the collected data and make the information available to the viewers at school, block and district levels.
- The report information will be displayed in terms of how many students were present in the school. Out of the available students how many students were provided with the mid day meals.
- The Reports available at the panel will be in downloadable formats.
- The web panel shall also contain a grievance collection/ feedback option where in the visitors can login and provide there feedback for further actions and betterment.
4.4 Data Transfer Module :
The proposed IVRS based data capturing system access the MDM server through an Internet / VPN, which will connect IVR/Database server to/from MDM server.
4.4.1 Third Party Database Integration:
The proposed solution will be easily configurable with MDM MIS System (third party database) so as to be capable enough to fetch or update any piece of information so that application user can view and profile mid day meal activity related reports using multiple in-built searching criteria. This Module shall be furnished using an interactive API mechanism, either provided by MDM MIS System, run by the education department, GOB or else can be shared by Knowlarity Communications Pvt. Ltd. Basis this API interaction the application user will be able generate analysis reports using searching options and the information can be offloaded in compatible file formats.
4.5 MIS and reporting Module :
The voice application system will integrate advanced MIS (Management Information System) module so that application user can view and profile mid day meal activity related reports using multiple in-built searching criteria.
The MIS module will furnish intuitive web based interface to select and define various searching criteria. Based on user-opted searching criteria, the MIS sub system will retrieve data reports from within internal source database repository. The application user can segregate campaign reports using searching options. Also campaign reports can be offloaded in compatible file formats. The module will have drill down facility for the various levels in the hierarchy based on the rights allocated to the user.
4.5.1 MIS Data can be Graphical or Table
Reports can be view either Graphical or Tabular form through web-base interface.
4.5.2 Intelligent Sample Selection for Physical Audit
System can generate sample data set for physical Audit. We can used randomization sampling technique on different variance data set which guarantee that every individual school has an equal opportunity for selection. Three Variance data set can consider base on data collection percentage. 1. Less then Average % , 2. Greater then Average % and 3. Average %.
4.6 Alert and Notification Module:
This module is basically designed to generate automated alerts in case of any critical situation. Alert notification generation system will raise an event based communication to the predefined list of recipients (MDM Officials) so that the required action can be take under given circumstances thereby ensuring smooth functioning of the mid day meal activity.
There will be two type of events:
- Technical Events
- Business Events
There will be three modes of communication in case of any alerting/notification situation:
1.1 IVR Flow
Monday to Thursday Automated Scheduled Call will be as follows:
- An automated call is triggered to the concerned individuals contact number.
- IVR welcomes the call recipient by informing them that this call is from MDM, GOB.
- IVR asks the call recipient about how many students were present in the school for that particular day and recipient will asked to punch the numbers on his/her mobile phone.
- IVR asks next question to the recipient that whether the Mid Day Meal is prepared for that particular day, if yes, press 1 and if not the press zero.
- If recipient presses 1 then IVRS will ask next question that how many students took the meal in the school for that particular day and recipient will answer this question by punching mobile keys.
- IVR confirms back all the feedback given by recipient i.e. the total number of students in the school, Whether meal is prepared or not and number of students who took the mid day meal.
- IVR Plays thanks & Confirmation message and the call ends.
Friday Automated Scheduled Call
On Friday the above steps will be repeated up to step number “e”. Then IVR will ask two addition question as follows:
- IVR asks the call recipient whether the sufficient Grains for next week’s is available or not. Incase yes then press 1, else if it’s not available then press 2.
- IVR then asks call recipient if the sufficient Funds for the next week’s is available or not. Incase yes then press 1, else if it’s not available then press 2.
- IVR confirms back all the feedback given by recipient i.e. the total number of students in the school, Whether meal is prepared or not, number of students who took the mid day meal, Grains & funds availability for coming week.
- IVR Plays thanks & Confirmation message and the call ends.
Chart 1: Daily OBD Call Flow
Chart 2: OBD Call Flow On Friday the above steps will be repeated as shown in chart no-1 up to number students who took the meals question. Thereafter the IVR Flow will be as follows:
5.2 Number Verification:
The system will be designed with a facility for verification of numbers of the officials from mid day meal activity. Before rolling out of the project an automated call will be pushed to the MDM officials that prompts the users there name and school name/code and will ask them if the call recipient is the authorized person for providing the mid day meal activity. In case the user responds positively the same shall be updated in the database, else if the user responds that he is not the concerned person the system will prompt him to provide the concern person’s contact number. After repeated call if principal/Headmaster/School In-charge not confirming the verification call then reports of such scholl will be submitted to MDM Bihar for further action.
Apart from this the system will also be able to generate wrong or bad format numbers. The system will also be capable to identify the numbers which are not from Bihar circle.
1.3 Web Panel:
The proposed campaign system will integrate scalable web based MIS module to furnish multiple activity reports derived from available report generation criteria. The MIS module will furnish intuitive web panel to select and define various searching criteria. Based on user-opted searching criteria, the MIS sub system will retrieve data reports from within internal source database repository. The application user can segregate campaign reports using searching options. Also campaign reports can be offloaded in compatible file formats.
1.3.1 User Management
- This part of the module will constitute an administrative console to create and manage other web application users down the hierarchy. The hierarchy shall be as MDM Authority, NGO or Public as per decided by the MDM Authority Bihar.
- Enable application’s administrator to assign specific set of rights and permissions to intended child application users and users groups in the hierarchy.
- The information so displayed on the panel will be in accordance to the rights being allocated to the user. For eg : User from a block level shall only be able to view data and reports at the block level.
1.3.2 Login Page
Common screen for all the users in the system, role of users are identified automatically post-login.
5.3.3 Contact us
Contact details for the officers at all district and block level will be displayed.
5.3.4 Feedback Page
This page is meant for the purpose of complaint registration and grievance redressal where in the school representatives/Public/NGOs can provide there feedback.
5.3.5 Meal served status page:
In order to track the status of meals being served in the schools, user can select the date range and can view the count of student whom meal was being served. Further for each district user can just click on the district name and view details for that specific district, based on the hierarchical rights being assigned to him.
5.3.6 Schools where meals were not served:
User can easily track the schools at various hierarchal level where the meal was not being served.
5.3.7 School’s data collection status:
User can easily view the data compilation status for various hierarchal level and can further drill down the data from district to town and so on.
The displayed information shall be provided in downloadable formats where in the users can select the date range and click on the download tab to offload the piece of information. The piece of information displayed shall depend upon the rights being allocated to the user/ login id from which the user has logged in. For eg. Official from a particular block shall only be assigned rights to view the information at block level only and so the hierarchy shall follow at various levels.
6. System Architecture Diagram
1. Telecommunications & IT Infrastructure Requirements
1.1 PRI Lines
For generating a IVR call to 70000 schools and collect the data as per RFP within a time span of 5 hours (Between 10 am to 3 pm) Primary rate Interface (PRI) lines will be required. These PRI lines will be outsourced from any of the leading service Provider like BSNL, Tata, Reliance, Bharti, idea etc. An E1 PRI is a digital business telephony connection between the Telecom Service Provider Exchange and the E1 card.
An E1 PRI is a group of 30 individually configurable voice channels, provisioned over a 4-wire 2 Mbps digital system. It is expected that 20 to 25 PRI lines would be required to cater this requirement.
1.2 Hardware Interface
Web Server Specification:
Topology: 2U Rack Mountable
Processor: AMD Opteron Processor Quad core 2.4 Ghz, 64 bit (native), 6 MB cache, Integrated memory controller 2.2 GHz, Bus Speed 1000 MHz
RAM: 16GB DDR3
Hard Disk: 512 GB. RAID technology.
I/O Bandwidth: upto 37.3 Gbps
PSTN Gateway Server Specification:
Processor: AMD Quad core (x4) 2.0 GHz, 64 bit, 512 KB L1 Cache, 2 MB L2 Cache, Hyper Transport Technology
RAM: 8GB DDR3 1333 MHz
Hard Disk: Solid State Hard Drive, hot swappable
ATCOM – TE400P 4 Port T1/E1 ISDN PRI Interface Card
Dahdi Driver. PLX Technology, Inc. Device 4002 (rev 01)
PostGreSQL 8.4 with active backup support
Apache 2.2 with Django 1.3 famework
Message Passing Mechanism:
Rabbitmq 2.2 (implementation of AMQP protocol)
2. Non Functional requirements
2.1 Planning for High Availability
- The system is architected such that there are multiple failovers for any one component in the system.
- All PSTN Gateways are redundant. Each node is capable of doing the same work as other
- IVR Execution Engine is continuously monitored for uptime and is automatically restarted within 45 seconds in case of a handshake failure.
- Warm Backup of Database is made every 15 minutes.
- Real Time Monitoring of Knowlus Platform is achieved with the help of NAGIOS. NAGIOS is an industry standard tool for IT Infrastructure monitoring. http://en.wikipedia.org/wiki/NagiosThe following components are monitored
- Monitor channel wise E1 occupancy level
- Monitor status of Data transfer(through Internet) between Server and MDM Server
- To ensure uptime:
- Knowlus platform will run self test every 15 minutes in a hour making it 96 times in day approx 100. The email can be sent to Email id of all stakeholders.
- Every selftest failing will be regarding as 1 incident.
- This will exclude the scheduled downtime.
- The scheduled downtime for maintenance will be maximum 2 times in 1 month with a total downtime of 4 hours.
- The customer will be informed of the downtime. The downtime will be taken only between10:00 pm to 6:00 am.
- All aspects of the network, including individual subsystems, processors, software processes, connections, and ports, are monitored 24/7 by theNetworkOperationsCenterin Gurgaon,New Delhi.
The non-functional requirements define the scope to safeguard data against loss or exposure, and to resist disruption by outside partners, or by unreliable resources. Following items describe the security requirements pertaining to system’s behaviour:
- Data protection
- Data sensitivity
- Password Policy
- Run-Time Requirements
- Environment requirements
2.2.1 Data protection
System will use customer’s database management system to store configurable items. Entirely separate database is to be designed for proposed system and will be protected via the registered user’s account.
2.2.2 Data sensitivity
Database stored message data is highly information critical and sensitive as it consists enterprising information, including messaging transaction details, which is categorized as “Highly Restricted”.
2.2.3 Password Policy
Password policy will be implemented on the available operating system platform. In use passwords will be expired in 30 days time or as suggested. Some policies suggest or impose requirements on what type of password a user can choose, such as:
- the use of both upper- and lower-case letters (case sensitivity)
- inclusion of one or more numerical digits
- inclusion of special characters, e.g. @, #, $ etc
Only three attempts will be provided to the user to enter password, in case a wrong password is being entered. On the very third attempt of wrong password the user account will be blocked and a pop up window will display the information as to contact the administration to get the account unblocked for further usage.
2.2.4 Run-Time Requirements
Browser and internet connectivity must be available to connect web console of application. To ensure the confidentiality of the web access page there will be an inbuilt mechanism to detect the ideal time for which a user is logged in. The ideal session will expire automatically after 15 minutes.
2.2.5 Environment requirements
- Windows based operating system, including latest service packs
- Microsoft Internet Explorer 6.0/7.0
- Mozilla Firefox 2.0
Knowlarity will manage and monitor entire system’s performance. Also Knowlarity will handle database clean up/re-indexing/backup activity.