The system shall have a MDI form that allows for the viewing of the graph and the data table.
The system shall display Events in a vertical table by time.
The system shall display the Events in a graph by time.
The system shall display Events or Activities.
The display shall have two regions: left 2/3 of the display is graphical right 1/3 of the display is a data table.
The data displayed in both the nodes within the graph and the rows in the table are MSEL Summary data.
The table side of the display shall be split into 2 regions: sequential and temporal.
The top 1/4 of the table will hold events that are to occur sequentially.
The bottom 3/4 of the table will hold events that occur according to its relevance to current time.
The system shall color code events according to their variance from current time.
The system shall display data from the Sync Matrix 1.0 and Exercise Management Tool 1.0 applications.
The system shall link Events back to either the Sync Matrix 1.0 or the Exercise Managment Tool 1.0 applications for modifications.
The system shall allow modification of the display.
The system shall offer a display of all the Events in the exercise.
The system shall filter data by: Venues and Key Events.
The system shall allow a user to define the time segments.
The system shall display the local and exercise time in separate clocks.
The system shall offer the ability to pause and resume the refresh of data.
The system shall provide charts for the Activity or Event actual versus assumed time.
The system shall provide a history report of changes made to the Activity or Event data.
The system shall allow a real estate agent to query MLS information.
The user shall be able to get driving directions to a selected property.
The user shall be able to download appointments and contact information for clients.
The system shall display clear property images in the search results.
The system shall update or create new property listings in the MLS.
Realtor shall be able to generate a CMA report based on property criteria.
The system shall be able to call the seller or buyer to schedule an appointment.
The realtor shall be notified of new client appointments after automatic synchronization with office system.
The realtor shall be able to retrieve a map showing property locations for a specified area.
The system shall notify the realtor when a seller or buyer responds to an appointment request.
The product shall allow the user to save the property search results.
A cohort shall be associated to one Program of Study offered by the department.
Program Administrators and Nursing Staff Members shall be able to add a listing of students to a cohort.
Program Administrators and Nursing Staff Members shall be able to add a single student to a cohort.
Students added to a cohort shall be eligible for the cohort's Program of Study.
Program Administrators and Nursing Staff Members shall be able to specify the preferred sequence of classes for a given cohort.
For each class within a sequence for a cohort Program Administrators and Nursing Staff Members shall be able to specify which quarter that class will be offered.
For each class within a sequence for a cohort Program Administrators and Nursing Staff Members shall be able to specify which quarter that class will be offered.
Program Administrators and Nursing Staff Members shall be able to add new classes to a sequence of classes.
Program Administrators and Nursing Staff Members shall be able to add clinical classes or sections to a sequence of classes.
Program Administrators and Nursing Staff Members shall be able to add a new cohort to the system identified by start month and year.
Program Administrators and Nursing Staff Members shall be able to add new classes for the nursing department into the system.
A class shall be either a non-clinical class or a clinical class.
A non-clinical class shall specify the course name lecture room requirements and instructor needs.
A clinical class shall specify the course name lecture room requirements clinical site needs lecture instructor needs and clinical lab instructor needs.
Program Administrators/Nursing Staff Members shall be able to create a new Program of Study.
A Program of Study shall consist of a program name and listing of required classes (both clinical and non-clinical) that must be completed.
Program Administrators and Nursing Staff Members shall have the ability to specify which classes are required for a Program of Study.
The system shall be able to display a report of needed classes for a given quarter for all cohorts of all programs for Program Administrators/Nursing Staff Members' planning purposes.
The report of needed classes shall include (but not be limited to) classes to be offered number of sections needed number of labs needed and room types needed.
Classes for a given cohort shall not conflict with regards to the time and day that they are offered.
Program Administrators and Nursing Staff Members shall be able to add a new clinical site into the system.
Clinical site information shall include (but not be limited to) the name of the site contact person and contact information.
Program Administrators and Nursing Staff Members shall be able to add a new clinical lab section for an existing clinical class into the System.
A clinical lab section shall include the clinical site name the class instructor day and time of the lab.
Program Administrators and Nursing Staff Members shall be able to add a student who has registered for a clinical class to a clinical lab section for that class.
The system shall allow a Program Administrator or Nursing staff member to remove a student from a clinical lab section.
The system shall allow a Program Administrator/Nursing Staff Member to move a student from one clinical lab section to another clinical lab section corresponding to the same clinical class.
Program Administrators/Nursing Staff Members shall be able to cancel a clinical lab section only if there are no students registered for that clinical lab section.
A Program Administrator/Nursing Staff Member shall be able to add a new nursing student to the system.
A staff member shall have the ability to manage the progress of a part time student which includes modifying their sequence of classes and timeline of classes.
The system shall be able to display a printable summary for individual cohorts which will include the students enlisted the Program of study sequence of classes cohort progress through the program and timeline of completion.
The system shall be able to display a printable summary for individual clinical sites which will include information on labs being held at that site for the given quarter (Clinical site general information on labs held at that location dates and times of all labs held there).
The system shall be able to display a printable summary for individual clinical labs which will include (but not be limited to) class name class number lab section listing of students enrolled instructor day(s) time and location.
The system shall be able to display a printable summary for individual nursing students which will include (but not be limited to) student name student ID admission date classes credits GPA and the cohort that the student is enrolled in.
The system shall be able to display a printable summary of the system log.
The system shall contain contact information (e-mail and phone number) for all people relevant to the system including (but not limited to) staff members students lecture instructors clinical lab instructors and clinical site administrators.
The system will use the stored e-mail addresses as a primary means of communicating information to affected parties.
The system will notify affected parties for routine communication purposes including but not limited to informing students of upcoming offered classes (timeline) and what their schedule will be/shall be.
The system will notify affected parties when changes occur affecting clinicals including but not limited to clinical section capacity changes and clinical section cancellations.
The system will notify affected parties when changes occur affecting classes including but not limited to class cancellations class section detail changes and changes to class offerings for a given quarter.
The system will notify affected parties when changes occur affecting cohorts including but not limited to changes to the sequence for a cohort's program of study and changes to a given week's schedule (lab cancelled this week due to instructor illness).
The system will notify affected parties when changes occur affecting specific students including but not limited to changing a student's status from full time to part time and moving a student to a different clinical section.
Program Administrators/Nursing Staff Members shall have the ability to modify information relating to cohorts including cohort identifier program of study preferred sequence of classes and quarters that a cohort will be taking specific classes.
Program Administrators/Nursing Staff Members shall have the ability to modify information relating to a Program of Study within the Nursing Department including the Program of study name and required classes for that Program of Study.
Program Administrators/Nursing Staff Members shall have the ability to modify information relating to a Clinical Site including the clinical site name site contact person contact information and address.
Program Administrators/Nursing Staff Members shall have the ability to modify information relating to a Clinical Lab Section including the clinical site name the department/section for the lab the class instructor day and time of lab and contact information.
Program Administrators/Nursing Staff Members shall have the ability to modify information relating to a Nursing Student including student ID student name phone number e-mail status (full time or part time) and program of study.
The Disputes System must be accessible by both internal and external users.
The Disputes System must prevent users from accessing any dispute cases that do not belong to their cardholder base.
The Disputes System will facilitate direct data entry of a dispute case via a user interface that supports real time responses to the users.
The Disputes System must provide different levels of access with regard to disputes case initiation and follow-up actions.
The Disputes System shall provide view access capability for authorized users of the application.
The Disputes System shall provide update access capability for authorized users of the application.
The Disputes System must allow the users to select disputable transactions (based on the age of the transaction) from a user interface and initiate a dispute (ticket retrieval request or chargeback notification) on the selected transaction.
The Disputes System must provide the user the ability to initiate a single dispute case on multiple transactions that belong to a single merchant.
The Disputes System will provide the user the ability to create or initiate a ticket retrieval request. As part of ticket retrieval creation process the system must prompt the user to enter all the required information to create the ticket retrieval request. The ticket retrieval request is a document that is sent to merchant inquiring the validity of a transaction.
The Disputes System must allow the user to create three unique types of ticket retrieval requests. The three types of ticket retrieval requests are (1) Request for original receipt (2) Request for a copy of the receipt or (3) Request for a portfolio. A portfolio consists of documentation that would provide proof of a purchase such as the documentation that is received from a car rental agency that is more than a sales receipt.
The Disputes System must prevent external users from requesting original receipts. Requests for original receipts are restricted to internal users.
"The Disputes System must provide a confirmation to the user upon the creation of ticket retrieval request that contains the following information; the dispute case number the type of retrieval requested (copy original or portfolio) and the date that the merchant response is due."
The Disputes System shall allow the user to create or initiate a chargeback request. The system must prompt the user to enter the required information to initiate a chargeback request. The chargeback request results in a printed chargeback notification that is sent to merchant indicating that their account will be charged back if no proof is provided that the disputed transaction is valid.
"The Disputes System must provide a confirmation to the user upon the creation of a chargeback request. The confirmation must contain the following information; the dispute case number the type of chargeback requested (pending or immediate) and the date that the merchant response is due."
The Disputes System shall prevent the creation of duplicate dispute requests 100% of the time.
The Disputes System shall accurately provide a list of possible reason codes for a given transaction. The list of possible reason codes must be derived based on the type of transaction and the industry that the merchant belongs to according to the business rules defined for the Disputes System.
The Disputes System must provide the ability to view existing dispute cases.
The Disputes System must provide Search functionality. The search method must include the ability to search by (1) the dispute case number (2) the merchant account number (3) the cardmember account number and (4) the issuer number. In addition to the above criteria the search functionality must further allow the user to limit the results of the search by a date range the type of dispute (ticket retrieval request or chargeback notification) the case status (open closed or all) and the dispute reason code.
A list of all disputes cases that meet the entered search criteria must be provided to the user. The list of cases must differentiate the type and/or status of the case by color -coding the line item in the list. For example all open cases will be yellow and all closed cases will be gray.
The Disputes System shall provide the users the ability to view the history of all activities that have occurred on the dispute case.
The Dispute System shall provide the users with the ability to follow up on a dispute case via follow-up actions. The list of available follow up actions for a given dispute case must be filtered by the status of the case and the access level of the user.
The Disputes System shall record the name of the user and the date for any activity that creates or modifies the disputes case in the system. A detailed history of the actions taken on the case including the date and the user that performed the action must be maintained for auditing purposes.
For any systematic (non-user initiated) action that occurs on a case such as the disputes aging process a case activity will be generated. Upon the next logon the user that initiated the dispute case must be notified that a systematic action has occurred on the dispute case.
All letter requests must be formatted according to guidelines specified by the Print Letter Utility system.
Any disputes cases that have been closed for over 6 months must be purged from the online disputes database.
The user shall search for the preferred repair facility using vehicle vehicle location and radius in miles.
The vehicle data shall include vehicle year make and model.
The vehicle location shall include street address city state and zipcode.
The system shall resolve the zipcode for the street address city and state if zipcode is unknown.
The search radius shall be between 1 and 30 miles.
The system shall locate the preferred repair facility with the highest ratings for the input criteria.
The adjuster shall enter the preferred repair facility on the estimate assignment.
The adjuster shall be able to override the preferred repair facitlity on the estimate assignment.
The preferred repair facility shall be returned to the user.
The system shall return a list of repair facilities within the radius if the preferred repair facility cannot be determined.
The estimator shall search for available recycled parts using damaged vehicle parts information.
The estimator shall search for available recycled parts using a list of preferred parts suppliers.
The system shall search for available recycled parts for the supplied vehicle parts and suppliers.
The estimator shall search by zipcode with a radius of 30 miles if no parts are found for the preferred parts suppliers.
The system shall retain the available recycled parts and suppliers returned from the search.
The available recycled parts information and their suppliers shall be returned to the user.
The estimator shall apply selected recycled parts to the collision estimate.
The estimator shall not apply recycled parts to the collision estimate if no available parts are returned.
The adjuster shall review the collision estimate.
The adjuster shall request a recycled parts audit of the collision estimate.
The recycled parts search results provided to the estimator shall be retrieved by the system.
The system shall generate an audit report based on the available recycled parts and the collision estimate.
The audit report shall include the total number of recycled parts used in the estimate.
The audit report shall include the number of available recycled parts from the original search results.
The audit report shall include the percentage of available recycled parts used in the estimate.
The audit report shall include the total score of the audit which sums the indivual line items.
The audit report shall be displayed to the user.
The audit report shall be available to other adjusters at later points in time.
The user shall select to view the preferred repair facility ratings.
The current repair facility ratings shall be displayed to the user.
The system will display a blank set of ratings if there are not ratings yet defined.
The user shall enter new ratings based on the audit report.
The ratings shall be from a scale of 1-10.
The ratings shall include categories for attempted use of recycled parts and actual use of recycled parts.
The user shall select to save the preferred repair facility ratings.
The preferred repair facility ratings shall be saved by the system.
The product shall record meeting entries.
The product will notify employees of meeting invitations.
The product shall have the ability to send meeting reminders to employees.
The product shall assign the organizers contact information to each meeting they create.
The product will record meeting acknowledgements.
The product shall store new conference rooms.
The product shall update existing conference rooms.
The product will be able to delete conference rooms.
The product shall be able to store new room equipment.
The product will update existing room equipment.
The product shall be able to delete room equipment.
The product shall allow an organizer to invite other employees to meetings.
Each time a conference room is reserved the conference room schedule shall be updated to reflect the time and date of the reservation.
The product shall record the transportation status of equipment reserved.
The product shall display a map of the company building showing conference room locations.
The product shall record updated meeting agendas.
The product shall send a meeting confirmation to the meeting organizer.
The product shall display room equipment according to search parameters.
The product shall display conference rooms according to search parameters.
The product shall record different meeting types.
The product shall record all the equipment that has been reserved.
The product shall notify building personnel of equipment transport requests.
The product will allow priviledged users to view meeting schedules in multiple reporting views.
The product shall be able to send meeting notifications via different kinds of end-user specified methods.
The product shall have a customizable Look and Feel.
The product shall have an intuitive user interface.
The product will display an available status for unreserved conference rooms.
The System shall allow generation of Inventory Quantity Adjustment documents on demand.
The System shall allow on demand generation of all Inventory Quantity Adjustment documents since certain point of time.
The IQA subsystem shall take into account current inventory status and adjust inventory of substitutionary ingredients accordingly.
The System shall allow entering storing and modifying product formulas.
Product formulas shall allow use of semi-products which have own formulas.
Product formula ingredients shall allow defining substitutionary ingredients.
Product formula substitutionary ingredients shall be entered automatically by the PFE subsystem.
Formula substitutionary ingredients shall be kept in persisted order.
Product shall allow entering storing and modifying product menus used by POS terminals.
PME Subsystem shall allow building product menus based on the list of products kept in the accounting system.
PME Subsystem shall allow keeping submenus within menus and products within submenus in a managed and persisted order.
PME Subsystem shall allow for a product to exist in more than one submenu.
The RMS System shall have Windows XP look and feel and use GUI futures making its use intuitive.
The System shall generate Inventory Quantity Adjustment document based on product daily sales data and product formulas.
The System shall generate Inventory Quantity Adjustment document automatically when daily Product Sales data is available.
The website will allow customers to search for movies by title actor or director.
viewing a movie details the website will display the movies description actor and director entered in by the administrator.
Website shall request and authorize credit card payment before allowing a user to stream a movie.
shall be able to stream purchased movie via Windows Media Player for up to 2 days aftere purchase date.
Website shall allow customers to browse movies by categories entered in by izogn administrator.
Website shall allow customers to view reviews of selected movies by other customers.
Website shall allow customers to add their own movie review for a selected movie.
Website shall allow the Izogn administrator to approve a review posted by a customer.
System will allow customers to pay for a streaming movie with a pre-paid card.
Website shall allow customers to purchase pre-paid cards of $5 $10 or $20 value either by credit card or mail-in payment option.
System shall automatically update the main page of the website every Friday and show the 4 latest movies that have been added to the website.
System shall allow users to update their billing and contact information via the My Account section of the website.
Pre-paid cards shall be distributed via email or via a printed paper card.
Only registered customers can purchase streaming movies.
Movies can only be streamed if the customer has purchased a movie and is within the 2-day time period to stream the movie.
Website must be able to support free trial periods with various parameters set by the Izogn Manager.
All streaming movie sales will be logged in the database and accessible by the administrator.
All registered customer information shall be stored and maintained in the database even after the customer cancels their account.
Daily usage statistics should be logged and accessible by the administrator.
The owner shall have free access to all of the streaming movies.
The vendor will verify the invalid lead.
Vendor will submit a credit validation record to be applied to the enterprise billing system.
If a lead is scored to the high range the system will supply the lead data and score to the enterprise system.
The leads washing functionality will validate all leads received by the web service for valid data.
The leads washing functionality will insert all leads captured by the web service.
If the leads score falls within the high average score then it will be process by the ARA functionality.
If the leads score falls within the medium average then it will be set for manual verification by an Enrollment Coordinator through the eleads system.
If the leads score falls within the low average then it will be returned to the supplying vendor.
The leads washing functionality will compile both contact and academic scoring information for a total score.
The leads washing functionality will use the parameters supplied by corporate and schools to score part of the lead.
The leads washing functionality will return the lead data supplied to the vendor along with the reason of rejection.
The leads washing functionality will have an interface in which lead data parameters can be maintained.
The leads washing functionality will verify the users authentication and rights to make parameter updates.
The leads washing functionality will store any potential lead duplicates returned by the enterprise system.
Prior to submitting the lead to the enterprise system the leads washing functionality will assign the lead to an admissions rep.
The leads washing functionality shall receive a period list of available reps from the enterprise system.
The product shall maintain a list of players.
The product shall allow a user to identify himself or herself as a player.
Once a game has been initiated the product shall make the players assigned to the game unavailable for selection from the list of players.
The product shall allow a user to remove himself or herself from the list of players at any time.
The product shall make inactive players unavailable for selection from the list of players.
The product shall remove players who have been inactive for 24 hours from the list of players.
The product shall allow a player to initiate a game by selecting another available player from the list of players.
Once a game is initiated the product shall display a defensive grid to each player.
Once a game is initiated the product shall display an offensive grid to each player.
The product shall prevent a player from viewing the offensive or defensive grids of the other player.
Once a game is initiated the product shall allow each player to position their 5 ships on their respective defensive grids.
The product shall allow a player to position ships horizontally on their grid.
The product shall allow the player to position ships vertically on their grid.
The product shall allow the player to position ships diagonally on their grid.
The product shall prevent the player from overlapping ships on their grid.
When both players have positioned their 5 ships on their defensive grids the product shall define the status of each player for the first turn.
For each turn the product shall identify one player as offensive status and one player as defensive status.
The product shall maintain the status of each player for a turn either offensive or defensive.
At the start of each turn the product shall notify each player of his or her status.
For each turn the product shall allow the offensive player to define a shot.
For each shot the product shall examine the defensive grid of the defensive player to determine whether the shot was a hit or miss.
For each shot the product shall notify the players whether the shot was a hit or miss.
For each shot the product shall mark the shot as a hit or miss on the defensive grid of the defensive player.
For each shot the product shall mark the shot as a hit or miss on the offensive grid of the offensive player.
When the hit results in sinking a ship the product shall notify the players that the ship was sunk.
When the hit results in sinking a ship the product shall mark the ship as sunk on the defensive grid of the defensive player.
When the hit results in sinking a ship the product shall indicate the type of ship sunk on the defensive grid of the defensive player.
When the hit results in sinking a ship the product shall mark the ship as sunk on the offensive grid of the offensive player.
If the shot was marked as a hit the product shall allow the offensive player to define a shot.
If the shot was marked as a miss the product shall change the status of the offensive player to defensive.
If the shot was marked as a miss the product shall change the status of the defensive player to offensive.
The product shall continue to assign turns until the game is ended.
The product shall end a game when a hit by the offensive player results in sinking the last of the defensive player's ships which had not been previously marked as sunk.
The product shall allow a player to end a game at any time during the game.
When a game is ended the product shall notify the players that the game is ended.
The notification of the game ending will include the reason the game is ended (i.e. a player has won the game or a player has ended the game).
When a game is ended the product shall allow each player to identify himself or herself as an available player in the list of players.
When a game is ended the product shall allow each player to remove himself or herself from the list of players.