13-Attachment N - Approved Templates.pdf

ATTACHMENT N: APPROVED TEMPLATES

The awarded vendor shall provide comprehensive project management services, employing Agile methodologies to ensure transparent planning, execution, and delivery. TEA has provided Attachment N: Approved Templates and Attachment O: Processes and Procedures for reference and support.

1. Known Issues Report Sample Report

MM/DD/YYYY PRODUCTION RELEASE

Help Desk Ticket

Dev Ticket

Component Issue Description

User Impact Available Workaround

Date Reported

Expected Release Date

CAS-

PROJ-

Abcdef Error when accessing screen

User unable to complete data submission

Use Chrome browser

02-15-20## 03/31/20#

2. Release Notes Sample Report

MM/DD/YYYY PRODUCTION RELEASE

• <Module Name> o The <<APP_ACROYNM>> application was updated to align with the 20## data standards

• <Module Name> o The <<APP_ACROYNM>> application was launched, providing users the ability to submit…

• <Module Name> o The <<APP_ACROYNM>> application was updated to correct the issue of no data displayed for ...

<Report Name > <Report Name 2> <Report Name 3>

• <Module Name> o The <<APP_ACROYNM>> validation rules have been updated to correct an issue where the rule was firing for <insert invalid condition here> <Rule 1> <Rule 2>

Customization Register

• Requirement/User Story Reference

• Classification (Configuration/Extension/Custom Code)

• Upgrade Impact Statement

• Rollback/Contingency

• TEA Approval Date

3. Training Plan Sample Training Plan For each role and type of application user or administrator, create a plan outlining:

Revision History:

Date:

1. Objective – the objective of this training plan is to provide users with the knowledge and skills necessary to use the <<application name>> application.

2. Audience – this training plan is targeted to internal users with a specific security role

3. Content – the content of this training plan will cover the following topics:

a. Introduction to the <<application name>> application

b. User Interface Overview

c. Basic Functionality

d. Advanced Functionality

e. Troubleshooting

f. Steps to seek support

4. Delivery – this training will be delivered in a blended format, with the combination of instructor-led training and self-paced training.

5. Assessment – The training will be assessed through a combination of knowledge checks and hands-on exercises.

6. Resources – The following resources will be provided to the learners:

a. Training Materials

b. Training Videos

c. Practice Exercises

d. User Help Documentation

e. Trainer Notes for TEA Staff to use in any TEA-led trainings

7. Schedule – The training will be delivered over the course of two days, following the successful completion of user acceptance testing.

8. Evaluation – The training will be evaluated through a TEA approved survey of the learners.

9. Revision – The training plan will be reviewed and revised after each training session and will incorporate the feedback and learnings from the training evaluations.

4. User Research Plan Sample Plan

• Objectives: Clearly define the goals of the user research. For instance, "To understand user pain points while using the current search function on our website."

• Target Audience: Describe the specific user group you'll be researching. This could be existing customers, a new demographic you're targeting, or a combination.

• Research Methods: Outline the specific techniques you'll use to gather user data. Examples include:

o Surveys: Online or paper questionnaires to collect user demographics, preferences, and opinions.

o Interviews: In-depth conversations with individual users to explore their experiences and goals.

o Card Sorting: Users organize topics or features into categories to understand how they ++++++++++++++perceive information architecture.

o Usability Testing: Observing users interacting with a prototype or existing system to identify usability issues.

• Data Analysis Plan: Explain how you'll analyze the collected data to identify trends and insights.

Techniques like thematic analysis or affinity diagramming can be used here.

• Deliverables: Specify the outputs of the user research, such as a report summarizing findings, user personas, or recommendations for design improvements.

5. Business Requirements

Business Requirement ID: BR[Number]

Requirement Name: [Concise name describing the requirement]

Description: [Detailed explanation of the business need or objective]

Business Value: [The value this requirement brings to the business or user]

Priority: [High, Medium, Low]

Stakeholders: [List of individuals or groups affected by this requirement]

Assumptions: [Any assumptions made about the requirement or its context]

Dependencies: [Any other requirements or systems that this requirement depends on]

Acceptance Criteria: [Specific conditions that must be met for the requirement to be considered fulfilled]

Additional Notes: [Any other relevant information]

Example Business Requirement

Business Requirement (BR1):

• Requirement Name: Secure Authentication

• Description: The system must provide a secure login mechanism to protect user accounts and prevent unauthorized access.

• Business Value: Protect user data, ensure privacy, build trust, and comply with security regulations.

• Priority: High

• Stakeholders: Users, Security Team, Legal Team

• Customization Register o Requirement/User Story Reference o Classification (Configuration/Extension/Custom Code) o Upgrade Impact Statement o Rollback/Contingency o TEA Approval Date

6. Functional Requirements

Functional Requirement ID: FR[Number]

Requirement Name: [Concise name describing the requirement]

Description: [Detailed explanation of the functionality to be implemented]

Priority: [High, Medium, Low]

Actor: [The user or system that will perform the function]

Input: [Data or information required to perform the function]

Process: [The steps involved in performing the function]

Output: [The result or outcome of the function]

Error Handling: [How errors or exceptions will be handled during the function]

UI/UX Design: [Any specific user interface or user experience design considerations]

Dependencies: [Any other requirements or systems that this requirement depends on]

Acceptance Criteria: [Specific conditions that must be met for the function to be considered working correctly]

Additional Notes: [Any other relevant information]

Example Functional Requirement

Functional Requirement (FR1):

• Requirement Name: Login Form Display

• Description: The system shall display a login form with fields for username and password.

• Input: User-provided username and password.

• Output: Login form displayed on the screen.

• UI/UX Design: The form should be visually appealing and easy to use.

• Customization Register o Requirement/User Story Reference o Classification (Configuration/Extension/Custom Code) o Upgrade Impact Statement o Rollback/Contingency o TEA Approval Date

• Acceptance Criteria:

o The login form is displayed correctly.

o The form is accessible to users with disabilities.

7. User Story Title: [Concise summary of the user story]

As a [User Role], I want [Goal/Desire] so that [Reason/Benefit]. [BA, Dev, and Test Estimates]

Acceptance Criteria:

• Scenario: [Specific situation or context]

• Given [Precondition(s)]

• When [Action taken by the user]

• Then [Expected outcome or result]

Additional Details:

• Priority: [High, Medium, Low]

• Dependencies: [Link any dependencies on other user stories or features]

• Technical Notes: [Any relevant technical considerations or constraints]

• Mockups/Wireframes: [Attach or link to relevant visual representations]

• Customization Register o Requirement/User Story Reference o Classification (Configuration/Extension/Custom Code) o Upgrade Impact Statement o Rollback/Contingency o TEA Approval Date

Example:

Title: Secure Login Functionality

As a registered user, I want to be able to log in securely from any device so that I can access my personalized information. [Estimated by BA, Dev, and Test team members]

Acceptance Criteria:

• Successful Login (Desktop):

o Given I am a registered user on the login page using a desktop browser (Chrome, Firefox, Edge) o When I enter my valid username and password o And click "Login" or press Enter o Then I am redirected to my dashboard within 2 seconds o And I see a personalized welcome message (audible if using a screen reader)

• Successful Login (Mobile):

o Given I am a registered user on the login page using a mobile device (iOS, Android) o When I enter my valid username and password o And tap "Login" o Then I am redirected to the mobile-optimized dashboard within 2 seconds o And I see a personalized welcome message (screen-reader compatible)

• Invalid Login:

o Given I am on the login page o When I enter an invalid username or password o And click/tap "Login" or press Enter o Then I see a clear error message within 1 second, indicating invalid credentials o And the error message is associated with the relevant input field (screen-reader accessible) o And the invalid attempt is logged (with timestamp and username if available)

• Forgotten Password:

o Given I am on the login page o When I click/tap "Forgot Password" o Then I am redirected to an accessible password reset page o And I can initiate password reset using my registered email

• Accessibility:

o Given I am using assistive technology (screen reader, keyboard navigation) o When I interact with login, error, and password reset pages o Then all elements are usable and understandable o And screen readers announce all relevant information

Additional Notes:

• Priority: High

• Security: Login attempts are rate-limited to prevent brute-force attacks.

• Error Handling: System errors display a generic message and are logged with details.

• Logging: All login attempts and system errors are logged with timestamps.

Technical Considerations:

• Password hashing and salting.

• Session management.

• Responsive design for mobile optimization.

• Accessibility testing with WCAG guidelines.

8. Code Review Checklist Accessibility (Current WCAG):

Semantic HTML:

o Are elements used for their intended purpose (e.g., headings, lists, buttons)?

o Is the reading order logical and understandable?

o Are landmarks (e.g., <header>, <nav>, <main>, <footer>) used to provide structure?

Text Alternatives:

o Do all images have descriptive alt text (or are they purely decorative)?

o Are complex images accompanied by longer descriptions?

o Do form elements have labels and instructions?

Keyboard Accessibility:

o Can all functionalities be accessed using only a keyboard?

o Is the focus order logical and visible?

o Are there keyboard traps?

Color Contrast:

o Does text have sufficient contrast with its background (at least 4.5:1 for normal text)?

o Are there any color-based instructions (e.g., "click the red button")?

Time-Based Media:

o Do videos have captions and transcripts?

o Can animations be paused or stopped?

o Are there any flashing elements that could trigger seizures?

Forms and Error Handling:

o Are form fields clearly labeled and associated with their labels?

o Are error messages descriptive and helpful?

o Can errors be corrected easily?

Coding Best Practices:

Plain Language:

o Is the code written in a clear and concise manner?

o Are comments used to explain complex logic or decisions?

Open Source:

o Is the codebase open source and publicly available?

o Are licenses for third-party libraries clearly documented?

Testing:

o Are there automated tests (unit, integration, end-to-end) in place?

o Do the tests cover a significant portion of the codebase?

Security:

o Are input validation and sanitization implemented to prevent vulnerabilities (e.g., XSS, SQL injection)?

o Are sensitive data (e.g., passwords) handled securely?

Performance:

o Is the code optimized for performance (e.g., minified assets, efficient algorithms)?

o Are there any unnecessary network requests or large file sizes?

Maintainability:

o Is the code well-structured and easy to understand?

o Are there clear separation of concerns and modularity?

o Is the codebase well-documented?

Scalability:

o Is the code designed to handle increased traffic or data loads?

o Are there any potential bottlenecks or performance issues?

Error Handling:

o Are errors handled gracefully and logged appropriately?

o Are there clear error messages for users?

Version Control:

o Is the codebase under version control?

o Are commit messages clear and descriptive?

9. Test Case Template Test Case ID: TC_Login_ [Unique Number] (e.g., TC_Login_001)

User Story: Secure Login Functionality

Description: Verify that the login functionality works correctly for registered users.

Preconditions:

• The user is registered in the system with a valid username and password.

• The login page is accessible.

Test Steps:

1. Navigate to the login page.

2. Enter a valid username in the "Username" field.

3. Enter a valid password in the "Password" field.

4. Click the "Login" button.

Expected Results:

• The user is redirected to their dashboard.

• A welcome message is displayed on the dashboard (e.g., "Welcome, [Username]!").

• No error messages are displayed.

Actual Results:

• [Record the actual outcome of the test here]

Status:

• Pass/Fail

Additional Test Cases for the User Story:

To ensure comprehensive testing of the "Secure Login Functionality" user story, additional test cases would be needed to cover different scenarios, such as:

• TC_Login_002: Invalid login attempt (incorrect username or password)

• TC_Login_003: Forgotten password functionality

• TC_Login_004: Account lockout after multiple failed attempts

• TC_Login_005: Session timeout after inactivity

• TC_Login_006: Remember me functionality (if applicable)

• TC_Login_007: Accessibility testing of the login form

10. Technical Documentation and Visual Aids Introduction

• Project overview and goals

• Target audience and user personas

• Redesign scope and exclusions

• Technology stack and tools used

User Flow and Navigation

• User story mapping and key user journeys

• Site architecture and information hierarchy

• Wireframes and prototypes

• Navigation elements and interactions

• Content strategy and organization

Front-End Development

• Programming languages and frameworks used

• Design system and component library

• Code structure and file organization

• Accessibility compliance standards

• Responsive design and device compatibility

Back-End Development

• Programming languages and frameworks used

• Database schema and data management

• Server-side logic and APIs

• Content management system (CMS) configuration

• Security measures and user authentication

Performance and Optimization

• Page load times and optimization techniques

• Caching mechanisms and content delivery networks (CDNs)

• Image optimization and file compression

• Browser compatibility and performance testing

Testing and Deployment

• Unit testing, integration testing, and user acceptance testing (UAT)

• Staging environment and deployment process

• Rollback plan and emergency procedures

• Performance monitoring and analytics

• Accessibility testing process

Operations and Maintenance

• Content update procedures and version control

• Bug tracking and resolution process

• Security updates and vulnerability patching

• Ongoing performance monitoring and optimization

11. Vendor Requirements on Equipment Hardware and Software Requirements

• List of necessary equipment and software licenses for project execution

• Minimum technical specifications for hardware and software compatibility

• Installation and configuration instructions

Access & Security Credentials

• User accounts and access privileges for relevant systems and tools

• Security protocols and guidelines for data protection

• Password management and change control procedures

Appendices

• Glossary of technical terms

• Developer and support contact information

• Third-party licenses and credits

• Additional documentation resources

12. Deployment Checklist Template Pre-Deployment

• Code Review Completed: Code thoroughly reviewed and approved.

• Unit Tests Passed: All unit tests pass successfully.

• Integration Tests Passed: Integration tests completed with no critical errors.

• Performance Tests Passed: Performance tests meet acceptable thresholds.

• Security Scan Completed: Security vulnerabilities identified and addressed.

• Environment Setup: Deployment environment configured correctly.

• Backup Created: Full backup of current production environment taken.

• Deployment Plan Reviewed: Deployment plan reviewed and approved by stakeholders.

• Communication Plan Ready: Plan in place to notify relevant parties of deployment status.

Deployment

• Code Deployed to Staging: Successful deployment to staging environment.

• Smoke Tests Passed on Staging: Basic functionality verified on staging.

• User Acceptance Testing (UAT) on Staging: UAT completed with no critical issues.

• Code Deployed to Production: Successful deployment to production environment.

• Smoke Tests Passed on Production: Basic functionality verified on production.

• Monitoring Initiated: Monitoring systems activated to track performance and errors.

• Deployment Verified: Final checks completed to ensure successful deployment.

Post-Deployment

• Communication Sent: Notification sent to stakeholders about successful deployment.

• Documentation Updated: Deployment documentation updated with any relevant changes.

• Lessons Learned Documented: Any issues or improvements noted for future reference.

13. Rollback Plan Template

1. Trigger

• Conditions for initiating a rollback (e.g., critical errors, performance degradation).

• Decision authority (Who has the authority to initiate a rollback?).

2. Communication

• Individuals/teams to be notified of the rollback.

• Contact information

• Communication channels to use (email, messaging apps, etc.).

3. Rollback Steps

• Detailed, step-by-step instructions for reverting the deployment.

• Include any manual steps required.

• Identify the parts of the rollback process that are automated.

• Reference relevant scripts, commands, or tools.

4. Verification

• Tests to confirm the rollback was successful.

• Checks to ensure the system is stable and functioning as expected.

5. Post-Rollback Actions

• Analysis of the cause of the deployment failure.

• Documentation of the rollback process and lessons learned.

• Actions to prevent a similar failure in the future.

Disclaimer: This is a general template. Adapt and tailor it to your specific project and environment to ensure the most effective rollback strategy.

14. Risk Management Plan Risk Description

• What is the potential event?

• What is the consequence of the event happening?

• What would cause the event to happen?

Risk Mitigation

• What is the mitigation plan to prevent the event from occurring?

Contingency Planning

• What is the contingency plan if the risk is realized?

• What is the trigger date or milestone to invoke the contingency plan?

Risk Exposure

• What is the probability the risk will occur? (Likely, Seldom, Unlikely, Occasionally)

• What is the impact if the risk occurs? (None, Minor, Moderate, Significant, Extensive)

• What is the exposure to the agency and stakeholders if this risk is realized? (Allowable, Undesirable, Unacceptable)

Risk Categories

• Potential damage to Agency or IT reputation

• Potential to put end-users at a significant disadvantage

• Financial risks of $10,000 or higher

• Potential impacts to several (3+) agency program areas

• Potential impacts to data collections or key dates

15. Change Request Template Change Request Information

• Change Request Number

• Date Submitted

• Project Name

• Requester Name/Role

• Requester Contact Information (Email, Phone)

Change Description

• Change Title

• Change Description

• Reason for Change

• Desired Outcome

Impact Assessment

• Scope Impact (How does this change affect the project’s goals/deliverables?)

• Schedule Impact (Will this change alter the project timeline? By how much?)

• Cost Impact (Are there additional expenses associated with the change?)

• Resource Impact (Will this change require different or additional resources?)

• Risk Assessment (Identify potential risks introduced by the change)

• Mitigation Plan (Describe steps to address the identified risks)

Technical Details

• Technical Requirements (Specifications, dependencies, etc)

• Implementation Plan (Proposed steps for executing the change)

• Testing Plan (How will this change be validated?)

• Rollback Plan (Steps to revert the change, if necessary)

Approval Workflow

• Approval Level (Project Manager, Change Control Board, etc)

• Approver Name/Role

• Approver Signature

• Approval Date

• Comments/Conditions

Implementation Details

• Implementation Start Date

• Implementation End Date

• Implemented By

• Implementation Status

Change Request Closure

• Post-Implementation Review (Summary of results, lessons learned)

• Closure Date

• Closed By (Name/Role)

16. TEA Deliverable Acceptance Form Project Name: [Project Name] Deliverable Name: [Deliverable Name (e.g., User Research Findings Report, Visual Design Mockups)] Deliverable Number: [Reference the Deliverable Number from the Project Scope Document] Sprint Number: [If applicable, the Sprint in which the deliverable was completed] Date of Submission: [Date] Acceptance Criteria:

• [List the specific acceptance criteria for this deliverable, referencing the relevant section of the project requirements document]

Vendor Confirmation:

• The vendor confirms that this deliverable meets all specified acceptance criteria and is ready for review and acceptance by the TEA.

• Vendor Representative Name: [Name]

• Vendor Representative Signature: [Signature]

• Date: [Date]

TEA Acceptance:

• The TEA has reviewed the deliverable and confirms that it meets all specified acceptance criteria.

• TEA Representative Name: [Name]

• TEA Representative Title: [Title]

• TEA Representative Signature: [Signature]

• Date: [Date]

Additional Notes/Comments:

• [Optional: Space for any additional notes, comments, or feedback regarding the deliverable]

Next Steps (if applicable):

• [If the deliverable acceptance triggers any subsequent tasks or actions, outline them here]

Payment Information (if applicable):

• [If the deliverable acceptance triggers a payment milestone, provide the relevant details here]

16. TEA Deliverable Acceptance Form