Goals

Primary

• Allow candidates to register for an examination with one of the following gender selections

  • Male

  • Female

  • Custom Gender

    • User must type a value

  • Prefer not to identify

Secondary

• Due to the end-of-support for the existing method of interacting with Authorize.net used by the current registration process, we will be implementing the payment process via the Authorize.net hosted pages functionality. This is no risk to downstream processing of payments with this change as it is currently the mechanism used for online product sales in ASWBCentral that are processed by CSC.

• We will use the same visual components/color schemes that are used in ASWBCentral through the design of this project. Since the work produced by this is intended to serve as a bridge until the new ASWBCentral Exam Registration development is completed, this will allow Candidates to become familiar with how ASWBCentral Online looks and operates.

Background and strategic fit

ASWB needs to ensure that it continues to support the changing social environment that Social Worker interact in. As part of this, the current registration process does not allow Candidates the opportunity to select a gender type consistent with their social declarations, Due to technological limitations of the current online registration system, a new interim system must be implemented to support this need. While this is opportunity to improve the current registration process, the need for timely development and minimal impact to staff and Candidates familiar with the online registration process, it has been decided that IT will develop a new site which addresses the immediate business need, but keeps the existing registration process (page navigation, field labels, error message, validation logic) intact. A visual refresh of the registration process will be included in this effort as the existing registration site utilizes the old ASWB.org color scheme and layout. This will be replaced with the visuals of the ASWBCentral site.

It should also be understood that other than the visual refresh, there will be no effort migrate the registration process or data into the ASWBCentral system. The majority of this work effort will be eliminated when the ASWBCentral specific project for exam administration is begun.

Terminology

Assumptions

• The new registration process will utilize the ASWBCentral layout and styling in all aspects

• The new registration process will interact solely with the legacy ASWBSQL2 and Datapath databases for all data actions

Actors 

Requirements

The following is a list of general requirements that apply to all related user stories unless specifically stated otherwise

1. The system is expected to handle all errors gracefully, providing a clear and concise message on the cause of the error. This includes but is not limited to:

   1. Data of an incorrect type being submitted. For example, alphabetic characters entered into a numeric only field

   2. Attempts to access a page of the registration process without successfully completing previous pages during the current visit. For example, attempting to access the Terms and conditions page, without first completing the Demographic information page

2. All data captured should be stripped of non-Ascii characters before attempting to process or save the data.

3. The system must require a valid SSL connection with the Candidate for all parts of the exam registration process. In the event that a secure connection can not be established, the Candidate must be prevented from continuing.

4. All interactions with the database must be through parameterized queries/procedures to maintain security of the system.

5. Only those validations and verifications listed within the user story must be applied and must be exactly as directed regardless of known changes to similar functions within the ASWBCentral system.

   1. This will allow for reduced testing as it will ensure that all conditions within the new system meet the current system requirements.

User Stories

Test Cases

The following is a list of test cases that have been identified by IT, and will be validated during the registration process. Each test case may have multiple variants to it to ensure that all scenarios specific to that test case are covered.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Timeline

Status: DRAFT

* A project meeting will occur at the end of each sprint to provide all stakeholders with updates on the project, walkthrough of completed items, and discussion of project deliverables.

Technical Review (IT)

Areas Affected

TBD