TheIntRendz

Home » Posts tagged 'object oriented analysis of a software' (Page 2)

Tag Archives: object oriented analysis of a software

Structure Analysis of a software

Structure Analysis

2.1   Introduction:

This part of the blog does structured analysis of a problem statement for a residential school for handicapped children, which requires that all teachers, therapists, and children’s activities are tracked. Therefore, they require an identity badge, card-swipe, attendance and categorisation database, to track entry into and out of buses, buildings, and rooms. The system must identify automatically the person, place, and activity. It must time-stamp and categorize the activities to provide security through common-sense judgments (e.g., alarm when the same person enters different locations in quick succession, etc.). Administrative staff will use the system for accounting purposes. Therapists and teachers will use the system to assure that mandated therapies and activities are accomplished (e.g., that a student received three hours of speech therapy on a given day). Facilities personnel will use the system in the event of an emergency to locate people within the facility in real time. Security personnel will use the system to monitor normal as well as abnormal activities and provide the basis for alarms and monitoring restricted areas. To analyse the solution for the problem, RFID readers and RFID active badges for automatically tracking of all students and employees are being used. RFID readers will be installed in all premises in such way that the entire premises gets covered; let it be inside or outside of the building. Even the RFID reader will be installed in the bus to track the students.

2.2       Purpose

The purpose of the document is to describe the requirement specifications for a residential school for handicapped children, which requires that all teachers, therapists, and children’s activities are tracked.

2.3       Scope

The software system to be produced is a helper application which will be referred to as AYS (At Your Service) application through this document. The goal AYS is to track the students through the identity badge, card swipe, and attendance and categorisation database. The system must identify automatically the person, place, and activity. It must time-stamp and categorize the activities to provide security through common-sense judgments (e.g., alarm when the same person enters different locations in quick succession, etc.). Administrative staff will use the system for accounting purposes.

Therapists and teachers will use the system to assure that mandated therapies and activities are accomplished (e.g., that a student received three hours of speech therapy on a given day). Facilities personnel will use the system in the event of an emergency to locate people within the facility in real time. Security personnel will use the system to monitor normal as well as abnormal activities and provide the basis for alarms and monitoring restricted areas. This effort will be useful in assisting living facilities such as psychiatric centres and hospitals that care for the aging.

2.4       Document Conventions of Requirement Specification:

AYS(At Your Service). It is the name of the application for the residential school of handicapped students.

AM(Admin Module). It is the module which shall be used by the administration team of the school

TM(Therapist Module). It is the module which shall be used by the Therapist of the school.

SAM(Server Admin Module). It is the module which shall be used by the server admin team or the IT team of the school. This team shall have the super user rights and privileges to access the server and also to root privileges to use the AYS.

EPC: The Electronic Product Code (EPC) is designed as a universal identifier that provides a unique identity for every physical object anywhere in the world, for all time. Its structure is defined in the EPC global Tag Data Standard, which is an open standard freely available for download from the website of EPC global, Inc. The canonical representation of an EPC is a URI, namely the ‘pure-identity URI’ representation that is intended for use when referring to a specific physical object in communications about EPCs among information systems and business application software. This code can be written to a RFID tag.

TEM(Teachers Module). This module shall be used by the teachers of the school.

FM(Facility Management Module). This module shall be used by the Facility Management team of the school

SM( Security Team module). This module shall be used by the security personnel of the school.

CCTV(Closed Circuit Television). This device shall be used by the security personnel to check the activities going on inside and outside of the school premises

RFID(Radio-frequency identification ). is the use of a wireless non-contact system that uses radio-frequency electromagnetic fields to transfer data from a tag attached to an object, for the purposes of automatic identification and tracking. We will be using Active RFID tags so that we can track the students as the student’s badges will contain the RFID tags.

RRM(RFID Reader Module). This module shall be used by the SAM to check and maintain the RFID reader and also to write/rewrite any RFID tag.

SAM: Server Admin Module. This module shall be used by the IT/Server team of the school and these people shall have the end to end knowledge of the AYS application

SNM: Sensor Module. This module shall be used by fire and smoke detectors to raise an alarm

CTV: CCTV module. This module shall be used by the security personnel to monitor all activities inside/outside of premises

2.5       Intended Audience and Reading Suggestions

The intended audience of this document includes the prospective developers of the tool and the technical assessment personnel of the stake holders or client organisations.

2.6       Overall Description

2.6.1    Product Prescriptive

In schools related to handicapped students it is necessary to keep track of their movements and it is necessary to note what all therapies are being given to each student daily. Also it is necessary to remove the students if they got stuck in some area during any accident. So for this it is necessary to track the handicapped student’s movement.  Also the management, security, administrative and the financial team of these schools need some tool that can reduce the manual intervention in doing their task thereby reducing the manual error. So for this an integrated software application with sensors and some tracking technology can ease this task. Let the application be christened as AYS (At Your Service) application.

2.6.2    Product Features

The main functions of the AYS system are to allow the members of the administrative, therapist, teachers, facility management and security department of the school to use the central database server which will store the location of the student and record the timestamp of him/her. The security team will use the central database server to track entry into and out of buses, buildings, and rooms and they will also use the system to monitor normal as well as abnormal activities and provide the basis for alarms and monitoring restricted areas. Administrative staff will use the system for accounting purposes. Therapists and teachers will use the system to assure that mandated therapies and activities are accomplished (e.g., that a student received three hours of speech therapy on a given day). Facilities personnel will use the system in the event of an emergency to locate people within the facility in real time. The database stores the location of the student along with the time stamp, activities done by him along with the time stamp, therapies taken by him along with the time stamp, fees paid by him along with the time stamp and also it stores the user authentication of various departments to access their respective module of the AYS application.

2.6.3    User Characteristics

Users are not technically sound and they are the administrative, therapist, teachers, and security and facility team members. So they must be trained on how to use the software.

2.6.4    Operating Environment

The AYS will adapt, change, automate and improve the operations of various departments of the school. An environment where the AYS shall be operational is a new environment. The requirements and number of users may increase later so the AYS should be built in such a way that it can be adapted to changes.

2.6.5    Constraints

The system should enforce user authentication security, guaranty time stamps reliability and guaranty location tracking reliability.

2.6.7    Assumptions and Dependencies

The RFID reader should be reliable and RFID tags should be active tags used so that location tracking can be done.

2.7       Software Functional Requirement

2.7. A Software Requirement

2.7. A.1           Admin Module (AM)

AM_FR_3.1.1 The user shall be able to load the AM within the desktop system by double clicking the AYS application executable after login authentication pass.

AM_FR_3.1.2 The AM shall support the logging of the user.

AM_FR_3.1.2.1 The initial window of the AYS shall contain the field for a user name, a field for a password and a button labelled login.

AM_FR_3.1.2 .2 The password field shall be a secret field, which does not display what the user types.

AM_FR_3.1.2.3 When the user clicks the login button the AYS shall send a request to the main server to login the user.

AM_FR_3.1.3 If the logging of the user is successful (refer AM_FR_3.1.2.3), the user shall see the AYS screen pertaining to AM.

AM_FR_3.1.4 The AM shall pop up a dialog box mentioning the user who had done the last login in the AM of the AYS and the date and time of login.

AM_FR_3.1.5 The AM shall display the user currently logged in.

AM_FR_3.1.6 The AM shall display the employees/students details as the home screen.

AM_FR_3.1.6.1 The student details shall be displayed in table format, with every student record in different row.

AM_FR_3.1.6.2 The fields shall be identified with labels. Intuitive and non-confusing abbreviations can be used if necessary.

AM_FR_3.1.6.3 The fields shall be modifiable only by the user who has privilege to access the AM.

AM_FR_3.1.6.4 The AM shall allow the user to sort the records basing on any field.

AM_FR_3.1.7 The AM shall log with the time stamp of users logged in and the operations performed.

AM_FR_3.1.8 The AM shall not allow admin team to access any other module except the AM in the AYS application.

AM_FR_3.1.9 The AM shall allow the user to add new student/employee record.

AM_FR_3.1.9.1 The AM shall provide a button to add new record.

AM_FR_3.1.9.2 The clicking of the add new record button shall take the user to display the Edit/Details screen.

AM_FR_3.1.9.3 The Edit/Details screen shall contain various fields to enter student’s information.

AM_FR_3.1.9.4 The Edit/Details screen shall contain Done and Cancel button.

AM_FR_3.1.9.5 The Done button shall commit the records to the database.

AM_FR_3.1.9.6 The Cancel button shall not commit the student’s            details to the data base and shall take the user back to previous screen.

AM_FR_3.1.9.7 The AM shall generate an EPC code, once the record is committed to the database.

AM_FR_3.1.10 The AM shall allow the user to modify any student records.

AM_FR_3.1.10.1 The AM shall provide edit button at the end of each row towards the right side of the student records.

AM_FR_3.1.10.2 The AM shall take the user to Edit/Details screen once the user clicks the Edit button.

AM_FR_3.1.10.3 The Edit/Details screen shall be populated with the student’s/employees details in the fields of the Edit/Details screen.

AM_FR_3.1.10.4 The user shall be able to edit all the fields in the Edit/Details screen.

AM_FR_3.1.10.5 The user shall be able to commit the changes to the server by clicking the Done button.

AM_FR_3.1.10.6 The user shall be able to cancel the changes done by clicking the Cancel button.

AM_FR_3.1.11 The AM shall allow the user to take a print out of any record details.

AM_FR_3.1.12 The AM shall be able to see the total cost incurred by a student on various therapies.

AM_FR_3.1.13 The AM shall provide the user to search for records based on name or id.

AM_FR_3.1.13.1 The AM shall display the records matching the entered text in the search field.

AM_FR_3.1.13.2 The AM shall start the search once the search button is clicked.

AM_FR_3.1.14 The AM shall provide the user to do range search basing on the range of joining dates.

AM_FR_3.1.14.1 The AM shall provide the user to enter the From date and To date for the range searching.

AM_FR_3.1.14.2 The AM shall display the list of records in tabular format matching the range query.

AM_FR_3.1.15 The AM shall be real time in nature.

AM_FR_3.1.16 The AM shall be used to check the attendance of employee and student on a particular date.

2.7.A.2             Therapist Module (TM)

TM_FR_3.2.1 The user shall be able to load the TM within the desktop system by double clicking the AYS application executable after login authentication pass.

TM_FR_3.2.2 The AYS shall support the logging of the user.

TM_FR_3.2.2.1 The initial window of the AYS shall contain the field for a user name, a field for a password and a button labelled login.

TM_FR_3.2.2.2 The password field shall be a secret field, which does not display what the user types.

TM_FR_3.2.2.3 When the user clicks the login button the AYS shall send a request to the main server to login the user.

TM_FR_3.2.3 If the logging of the user is successful (refer TM_FR_3.2.2.3), the user shall see the AYS screen pertaining to TM.

TM_FR_3.2.4 The AYS shall pop up a dialog box mentioning the user who had done the last login in the TM of the AYS and the date and time of login.

TM_FR_3.2.5 The AYS shall display the user currently logged in.

TM_FR_3.2.6 The AYS shall display the students’ therapies details.

TM_FR_3.2.6.1 The student therapies details shall be displayed in table format, with every student record in different row.

TM_FR_3.2.6.2 The fields shall be identified with labels. Intuitive and non-confusing abbreviations can be used if necessary.

TM_FR_3.2.6.3 The fields shall not be modifiable by the user.

TM_FR_3.2.6.4 The AYS shall allow the user to sort the records basing on any field.

TM_FR_3.2.7 The AYS shall log with time stamp regarding the users logged in and the operations performed.

TM_FR_3.2.8 The AYS shall not allow Therapist team to access any other module except the TM in the AYS application.

TM_FR_3.2.9 The TM shall not allow the user to modify or create any student records.

TM_FR_3.2.10 The TM shall allow the user to take a print out of any student’s therapy details.

TM_FR_3.2.11 The TM shall provide the user to search for records based on students name, ID and therapies taken.

TM_FR_3.2.11.1 The TM shall display the records matching the entered text in the search field.

TM_FR_3.2.11.2 The TM shall start the search once the search button is clicked.

TM_FR_3.2.12 The TM shall provide the user to check the details of the types of therapies and total therapies taken by any student on any date of the calendar.

TM_FR_3.2.13 The TM shall provide the user a calendar to check the therapies details given on a particular date and what all students taken the therapy with time log.

TM_FR_3.2.14 The TM shall be real time in nature.

2.7.A.3              Teachers Module (TEM)

TEM_FR_3.3.1 The user shall be able to load the TEM within the desktop system by double clicking the AYS application executable after login authentication pass.

TEM_FR_3.3.2 The AYS shall support the logging of the user.

TEM_FR_3.3.2.1 The initial window of the AYS shall contain the field for a user name, a field for a password and a button labelled login.

TEM_FR_3.3.2 .2 The password field shall be a secret field, which does not display what the user types.

TEM_FR_3.3.2.3 When the user click the login button the TEM shall send a request to the main server to login the user.

TEM_FR_3.3.3 If the logging of the user is successful (refer TEM_FR_3.3.2.3), the user shall see the AYS screen pertaining to TEM.

TEM_FR_3.3.4 The AYS shall pop up a dialog box mentioning the user who had done the last login in the TEM of the AYS and the date and time of login.

TEM_FR_3.3.5 The AYS shall display the user currently logged in.

TEM_FR_3.3.6 The AYS shall display the students’ activity details screen.

TEM_FR_3.3.6.1 The student activity details shall be displayed in table format, with every student record in different row.

TEM_FR_3.3.6.2 The fields shall be identified with labels. Intuitive and non-confusing abbreviations can be used if necessary.

TEM_FR_3.3.6.3 The fields shall not be modifiable by the user.

TEM_FR_3.3.6.4 The AYS shall allow the user to sort the records basing on any field.

TEM_FR_3.3.7 The AYS shall maintain the time stamp of users logged in and the operations performed.

TEM_FR_3.3.8 The AYS shall not allow Teacher’s team to access any other module except the TEM in the AYS application.

TEM_FR_3.3.9 The TEM shall not allow the user to modify or create any student records.

TEM_FR_3.3.10 The TEM shall allow the user to take a print out of any student’s activity details.

TEM_FR_3.3.11 The TEM shall provide the user to search for a student based on its name, ID and activities.

TEM_FR_3.3.11.1 The TEM shall display the records matching the entered text in the search field.

TEM_FR_3.3.11.2 The TEM shall start the search once the search button is clicked.

TEM_FR_3.3.12 The TEM shall provide the user to check the details of the types of activity and total activities taken by any student on any date of the calendar.

TEM_FR_3.3.13 The TEM shall provide the user a calendar to check the activity details done on a particular date and who all students did it with the time log.

TEM_FR_3.3.14 The TEM shall be real time in nature.

2.7.A.4             Facility Management Module (FM)

FM_FR_3.4.1 The user shall be able to load the FM within the desktop system by double clicking the AYS application executable after login authentication pass.

FM _FR_3.4.2 The FM shall support the logging of the user.

FM _FR_3.4.2.1 The initial window of the AYS shall contain the field for a user name, a field for a password and a button labelled login.

FM _FR_3.4.2 .2 The password field shall be a secret field, which does not display what the user types.

FM _FR_3.4.2.3 When the user clicks the login button the AYS shall send a request to the main server to login the user.

FM _FR_3.4.3 If the logging of the user is successful (refer FM_FR_3.4.2.3), the user shall see the AYS screen pertaining to FM.

FM _FR_3.4.4 The AYS shall pop up a dialog box mentioning the user who had done the last login in the FM of the AYS and the date and time of login.

FM _FR_3.4.5 The AYS shall display the user currently logged in.

FM _FR_3.4.6 The AYS shall display all the rooms of the school.

FM _FR_3.4.6.1 The room details shall be displayed in table format, with every room record in different row.

FM _FR_3.4.6.2 The fields shall be identified with labels. Intuitive and non-confusing abbreviations can be used if necessary.

FM _FR_3.4.6.3 Every room number shall display the EPC codes; which are the people’s badge id, flashing, in the next column of the row.

FM _FR_3.4.6.4 The fields shall not be modifiable by the user.

FM _FR_3.4.6.5 The AYS shall allow the user to sort the records basing on room numbers.

FM _FR_3.4.6.6 Initial view of the table will be sorted in descending order of the number of students inside a particular room.

FM _FR_3.4.7 The AYS shall maintain the time stamp of users logged in and the operations performed.

FM _FR_3.4.8 The AYS shall not allow facility team to access any other module except the FM in the AYS application.

FM _FR_3.4.9 The FM shall not allow the user to modify or create any records.

FM _FR_3.4.10 The FM shall allow the user to take a print out of any room/bus details.

FM _FR_3.4.11 The FM shall provide the user to search for a student based on its name/ ID to find out the position of the student.

FM _FR_3.4.11.1 The FM shall display the record matching the entered text in the search field.

FM _FR_3.4.11.2 The FM shall start the search once the search button is clicked.

FM _FR_3.4.12 The FM shall provide the user to see all the students present in a particular room.

FM _FR_3.4.13 The FM shall provide the user a calendar to check the room/bus details of a particular date and identifies students/employees were present in the room with the time log.

FM _FR_3.4.14 The AYS shall also display all the buses details of the school.

FM _FR_3.4.14.1 The bus details shall be displayed in table format, with every bus record in different row.

FM _FR_3.4.14.2 The fields shall be identified with labels. Intuitive and non-confusing abbreviations can be used if necessary.

FM _FR_3.4.14.3 Every bus number shall display the EPC codes; which are the people badge Id, flashing, in the next column of the row, saying which all people entered in that bus.

FM _FR_3.4.15 The AYS shall help the user to find out the attendance of any calendar day.

FM_FR_3.4.16 The FM shall be real time in nature.

FM_FR_3.4.17 The AM shall be used to check the attendance of employee and student on a particular date.

2.7.A.5            Security Department Module (SM):

SM_FR_3.5.1 The user shall be able to load the SM within the desktop system by double clicking the AYS application executable after login authentication pass.

SM_FR_3.5.2 The SM shall support the logging of the user.

SM_FR_3.5.2.1 The initial window of the AYS shall contain the field for a user name, a field for a password and a button labelled login.

SM_FR_3.5.2.2 The password field shall be a secret field, which does not display what the user types.

SM_FR_3.5.2.3 When the user clicks the login button the AYS shall send a request to the main server to login the user.

SM_FR_3.5.3 If the logging of the user is successful (refer SM_FR_3.5.2.3), the user shall see the AYS screen pertaining to SM.

SM_FR_3.5.4 The AYS shall pop up a dialog box mentioning the user who had done the last login in the SM of the AYS and the date and time of login.

SM_FR_3.5.5 The AYS shall display the user currently logged in.

SM_FR_3.5.6 The AYS shall display videos of all the premises (inside/outside) of the school as provided by the CCTV.

SM_FR_3.5.6.1 The AYS display shall be divided in 3×3 matrix format.

SM_FR_3.5.6.2 The first two rows of the matrix screen shall be occupied by the videos of inside room of school.

SM_FR_3.5.6.3 The last row shall display the videos of outside room and premises of the school.

SM_FR_3.5.6.4 The display should cover entire premises of the school both inside and outside within some fixed amount of time.

SM_FR_3.5.6.5 The AYS shall allow the user to choose the main rooms (priority rooms) to always focus on so that the live video footage of that matrix in the display is constant and does not change.

SM_FR_3.5.7 The AYS shall maintain the time stamp of users logged in and the operations performed.

SM_FR_3.5.8 The AYS shall not allow security team to access any other module except the SM in the AYS application.

SM_FR_3.5.9 The SM shall not allow the user to modify or create any student records.

SM_FR_3.5.10 The SM shall allow the user to take a print out of any room videos snapshot at a particular time.

SM_FR_3.5.11 The SM shall provide the user to raise an alarm.

SM_FR_3.5.12 The SM shall provide the user regarding the report of health of all the sensors present in the premises.

SM_FR_3.5.13 The SM shall provide the user a calendar to check the CCTV video footage of a particular date.

SM_FR_3.5.14 The SM shall allow the user to save the video in 3 different format(.avi,.mov,.dat).

SM_FR_3.5.15 The SM shall save the video in 1024 x 768 resolutions.

SM_FR_3.5.16 The SM shall allow the user to pan and zoom any video that is getting displayed in the application.

SM_FR_3.5.17 The SM shall record all the activities as collected by all the sensors, CCTV’s and RFID readers with the time stamp.

SM_FR_3.5.18 The SM shall raise an Alarm automatically if it senses some unwanted behaviour basing on activity logs that it collects at real time.

SM_FR_3.5.19 The SM shall be real time in nature.

2.7.A.6            Server Admin Module (SAM)

SAM_FR_3.6.1 The user shall be able to load the SM within the desktop system by double clicking the AYS application executable after login authentication pass.

SAM_FR_3.6.2 The SM shall support the logging of the user.

SAM_FR_3.6.2.1 The initial window of the AYS shall contain the field for a user name, a field for a password and a button labelled login.

SAM_FR_3.6.2.2 The password field shall be a secret field, which does not display what the user types.

SAM_FR_3.6.2.3 When the user clicks the login button the AYS shall send a request to the main server to login the user.

SAM_FR_3.6.3 If the logging of the user is successful (refer SAM_FR_3.6.2.3), the user shall see the AYS screen pertaining to SAM.

SAM_FR_3.6.4 The AYS shall pop up a dialog box mentioning the user who had done the last login in the SAM of the AYS and the date and time of last login.

SAM_FR_3.6.5 The AYS shall display the user currently logged in.

SAM_FR_3.6.6 The AYS shall allow the user to access all the Modules of AYS.

SAM_FR_3.6.7 The SAM shall allow the user to write the students ID (EPC) and employee id on the RFID badge.

SAM_FR_3.6.8 The SAM shall allow the user to erase/modify the student’s/employee id (EPC code) in RFID badge.

SAM_FR_3.6.9 The SAM shall allow the user to generate and print reports of all the modules.

SAM_FR_3.6.10 The SAM shall allow to access and update any data base of the application.

SAM_FR_3.6.11 The SAM shall allow checking the statistics of all the hardware/Sensors health.

SAM_FR_3.6.12 The SAM shall allow setting or resetting passwords of any user of any module.

SAM_FR_3.6.13 The SAM shall allow setting or resetting passwords of any user of any module.

SAM_FR_3.6.14 The SAM shall allow blocking of any user.

SAM_FR_3.6.15 The SAM shall allow upgrading of the AYS software.

SAM_FR_3.6.16 The SAM shall be real time in nature.

2.7.B   Hardware Requirements

2.7.B.1             RFID Reader module (RRM)

RRM_FR_3.7.1 The RRM shall provide a way to read/write the EPC code to RFID tags.

RRM_FR_3.7.2 The RRM shall provide a way to read the RFID tags.

RRM_FR_3.7.3 The RRM shall help server admin/IT team to monitor its health.

RRM_FR_3.7.4 The RRM shall be responsible to update the respective database of tags read by their respective readers.

RRM_FR_3.7.5 The RRM shall be responsible to raise an alarm if unauthorised RFID tags detected.

2.7.B.2             Sensors Module (SNM)

SNM_FR_3.8.1 The SNM shall guide the building occupants along the escape routes through voice.

SNM_FR_3.8.2 The SNM shall support various languages.

SNM_FR_3.8.3 The SNM shall have the capability of earth fault detection and short circuit detection.

SNM_FR_3.8.4 The SNM shall be able to check the health status of all the sensors/detectors present in the school.

SNM_FR_3.8.5 The SNM shall update all details to the security team regarding any accident.

SNM_FR_3.8.6 The SNM shall update the logs with time stamps if any sensor gets activated.

2.7.B.3            CCTV Module (CTV)

CTV_FR_3.9.1 The CCTVs shall be able to work in all light conditions.

CTV_FR_3.9.2 The CTV shall be able to record all the videos and store in the data base with time stamp at a definite frequency.

CTV_FR_3.9.3 The CTV shall be able to take snaps of photos and store it in data base with time stamp at certain defined frequency.

2.8       Non Functional Requirements

2.8.1                Capacity Requirements

CP_NFR_4.1.1 The application should able to handle at least 5000 volume of students at any day.

2.8.2                Performance Requirements

PR_NFR_4.2.1The AYS application shall provide the performance availability consistent with the functions provided.

PR_NFR_4.2.2 The operational availability of AYS shall be determined by a formula. The time service as available is measured over a continuous 10,000 hour interval, except that any loss of availability of the application due to loss of service facility, such as power, shall not be counted. The time service shall also include all time services which are not available due to corrective maintenance downtime, administrative downtime, logistics supply downtime, and preventive maintenance downtime.

PR_NFR_4.2.3 AYS shall predict and periodically assess maintainability by measuring the actual Mean-Time-to-Restore-Service (MTTRS) and comparing to the required MTTRS.

PR_NFR_4.2.4 AYS shall have the maximum time-to-restore-service and it shall not exceed twice the required MTTRS in 99.9 percent of failure.

PR_NFR_4.2.5 Once a user has successfully navigated to the AYS front end user interface, AYS shall be available to address users’ request 99.99 percent of the time.

PR_NFR_4.2.6 AYS shall provide a Mean Time to Restore (MTTR) of 0.5 hours.

PR_NFR_4.2.7 AYS shall provide a level of service where less than 0.001 percent of all Transaction Instalment Packets are lost due to whatever errors with data transmission.

PR_NFR_4.2.8 AYS shall maintain/assure the integrity of all data received, stored, and transmitted.

PR_NFR_4.2.9 AYS shall be real time and the frequency of data collection shall be within 1500 milliseconds.

2.8.3                Recovery Requirement

RR_NFR_4.3.1 The recovery shall take place only at non peak hours.

RR_NFR_4.3.2 The recovery shall start only when a backup starts functioning.

2.8.4               Security Requirements

SR_NFR_4.4.1 The AYS development team shall communicate with potential users to assure the security concerns are incorporated and considered during the design for AYS security.

SR_NFR_4.4.2 AYS shall provide security consistent with the functions provided.

SR_NFR_4.4.3 The appropriate level of protection for AYS will be determined by the level of security required of the data generated and transmitted by AYS and stored in main server.

SR_NFR_4.4.4 AYS shall prevent unauthorized users from accessing the system.

SR_NFR_4.4.5 AYS shall make data available to the authorized users in an expedient and secure environment.

SR_NFR_4.4.6 AYS shall insure that Client and all department and transaction level data and communication be protected from unauthorized parties.

SR_NFR_4.4.7 AYS shall provide access monitoring to compile and report security violations and attempted security violations.

SR_NFR_4.4.8 AYS shall have the thorough capability to a log record of an unauthorized attempt.

SR_NFR_4.4.9 AYS shall evaluate the following security measures such as encryption and firewalls, which shall provide a model for the AYS design.

SR_NFR_4.4.10 AYS shall implement controls to ensure the privacy of information, individuals, and corporations are not compromised.

SR_NFR_4.4.11 AYS shall use audit controls, electronic signatures, data encryption and other methods to assure the authenticity of transaction and other relevant data.

SR_NFR_4.4.12 AYS database management security services shall include access control (e.g., Discretionary Access Control (DAC), Mandatory Access Control (MAC), content-dependent and context dependent access control), individual user identification and authentication (I&A), data confidentiality, data integrity (e.g., entity integrity, referential integrity, and label integrity), security audit, object reuse, availability of service and data, and other security services.

SR_NFR_4.4.13 AYS shall implement controls to ensure the authenticity of data is preserved.

SR_NFR_4.4.14 AYS shall comply with the SSE-CMM Security model.

SR_NFR_4.4.15 AYS shall adhere to guidelines for physical, personnel, computer, communications, and internal data security.

SR_NFR_4.4.16 AYS shall be foreseen of user registration system allowing:

– distinguishing different user roles;

– Authorisation of users;

– Authentication of users.

SR_NFR_4.4.17 AYS shall be foreseen with an access control policy functionality allowing access of users in different roles to different functionalities of AYS. At least the following roles shall be introduced for IPF:

– Supervisor – the role providing AYS operators with access to various AYS modules          functionalities necessary to operate the AYS system, and having access to AYS logs;       the role having access to the code of AYS server and AYS databases, and being   responsible for maintenance of the code and the databases;

– Operator – the role which is allowed to daily operate the AYS system modules, and      allowed a read-only access to AYS logs;

SR_NFR_4.4.18 Only registered users shall be allowed to log-in to the AYS application.

SR_NFR_4.4.19 Registered users shall be allowed to log-on only to those AYS functions which they are authorised to access and use.

SR_NFR_4.4.20 Registration of users in their respective roles shall be valid only for a limited period of time, where after their authorisation shall be re-confirmed and prolonged.

SR_NFR_4.4.21 The logon processes shall prohibit the display of help screens.

SR_NFR_4.4.22 The logon processes shall minimise the opportunities for unauthorised connections to AYS.

SR_NFR_4.4.23 The logon processes shall prohibit the display of the AYS system or the application details until the process has been successfully completed.

SR_NFR_4.4.24 The logon process shall deny access if either the username or password is invalid without identifying the specific erroneous element.

SR_NFR_4.4.25 The logon process shall allow only a fixed number of logon attempts before disabling the terminal.

SR_NFR_4.4.26 If access is denied following repeated unsuccessful logon attempts, this shall be treated by the application as a security incident and handled accordingly.

SR_NFR_4.4.27 The logoff procedure shall clear any screen displays prior to terminating the application.

SR_NFR_4.4.28 AYS shall disallow simultaneous logon by the same user.

SR_NFR_4.4.29 Passwords to log-on to AYS (and additional access control devices) shall have at least the certain length of characters. The password management system shall require the enforcement of a minimum password length.

SR_NFR_4.4.30 The password management system shall require the use of quality (i.e. difficult to guess) passwords.

SR_NFR_4.4.31 The password management system shall require the enforcement of a password change after a certain period.

SR_NFR_4.4.32 The password management system shall include non-display of the password when being entered.

SR_NFR_4.4.33 The password management system shall require the storage of passwords in encrypted form.

SR_NFR_4.4.34 For all security incidents a alarm functionality shall be implemented, which immediately informs the supervisor role of these incidents.

SR_NFR_4.4.35 AYS shall treat the following events as security incidents:

– Unsuccessful log-on to AYS;

– Intrusion detection;

– malfunctioning of encryption functionality;

SR_NFR_4.4.36 The logon processes shall display only the minimum amount of information to assist users.

2.8.5               Legal and Regulatory Requirements

LR_NFR_2.8.5 AYS shall provide flexibility to easily modify the system to handle changes in trade laws, regulations, and license & permit requirements.

2.8.6               Requirements to Standards

SD_NFR_4.5.1 AYS shall maximize the effective use of applicable international, national, commercial, RFID and all sensors standards for development and operations.

SD_NFR_4.5.2 AYS shall adhere to standards for Open System hardware and software and be compliant to an Open System Architecture in the part regarding development of Math Functions and user interfaces.

SD_NFR_4.5.3 AYS shall use a standard communication protocol.

SD_NFR_4.5.4 The communications and networks utilized or provided by AYS shall make maximum practicable use of standards for data transportation defined by various standard boards.

SD_NFR_4.5.5 AYS shall maximize effective use of systems management standards.

2.8.7    Usability Requirement

UR_NFR_4.6.1 AYS shall have a quick access to currently published information to base decisions on.

UR_NFR_4.6.2 AYS shall replicate the database data daily in Oracle.

UR_NFR_4.6.3 AYS shall support consistency in decision-making among various users.

UR_NFR_4.6.4 AYS has to be user friendly.

UR_NFR_4.6.5 The data shall be available in real time.

2.8.8    Reliability Requirement

RR_NFR-4.7.1 AYS shall update interval protocols for updating different data types.

RR_NFR_4.7.2 AYS shall populate missing data in the database as soon as possible.

RR_NFR_4.7.3 The AYS shall have the results of the queries consistent and reliable over time.

RR_NFR_4.7.4 The AYS shall make efforts to retrieve accurate data.

2.8.9    Logs

LG_NFR_4.8.1 All the modules and operations shall be logged.

LG_NFR_4.8.2 Log shall include the time stamp of all the operations that is getting logged.

LG_NFR_4.8.3 Logs shall include the AYS applications fault, errors and recovery processes too.

LG_NFR_4.8.4 The frequency of logs generation shall be TBD, in order to be consistent with the ability to trace appropriate actions of the application.

LG_NFR_4.8.5 Logs shall include all log-on and log-out as well as all attempts (whether successful or not) to log-on.

LG_NFR_4.8.6 Logs shall have appropriate retention period (TBD).

LG_NFR_4.8.7 The log generating software shall prohibit amendment of log details and disabling of the recording of events.

LG_NFR_4.8.8 The log generating software shall include review of log-on patterns to determine potentially abnormal system use.

LG_NFR_4.8.9 Files of logged events shall be protected from amendment or deletion.

LG_NFR_4.8.10 Logging process shall always be enabled except when explicitly disabled by a supervisor role. Controls shall be in place to prevent the logging process from being disabled.

2.8.10 Availability Requirement

AR_NFR_4.9.1 The AYS shall achieve 100 percent availability at all times.

2.8.11 Maintainability Requirement

MR_NFR_4.10.1 The system shall be optimised for supportability, or ease of maintenance as far as possible. This may be achieved through the use and documentation of coding standards, naming conventions, class libraries, abstraction, and component re-use.

MR_NFR_4.10.2 UML shall be used wherever possible to clarify requirements and document key design decisions. The use of suitable UML diagrams (e.g. interaction, class, and sequence and collaboration diagrams) will help facilitate a natural progression from requirements analysis to the subsequent design and development phases.

2.9       ER Diagram,CSPEC,PSPEC etc.  

3.o Object Oriented Analysis of a software