This page displays various resources referenced at other areas of the Software Development site.
Business Requirements Document (BRD)
The EPRI Business Requirements Document (BRD) is used to provide, both the Business Requirements and the Functional Requirements. The Business Requirements details the requirements as elicited by the business lead in conjunction with the key stakeholders. These state in business language what the desired solution must do.
CBT Related Resources
The resources available for CBTs are provided in the CBT-Specific Requirements section. For any questions you may have about these resources please contact EPRI Training.
Copyright Notice
This document contains requirements, examples, instructions, and text for the Notice of Copyright, Availability of Subject matter and Disclaimer required for EPRI software and source code.
Note: For SWS it is additionally expected they contain the footer content presented here.
Cryptography and Encryption Functions Checklist and Definitions
This form must be completed and submitted to Export Counsel ("cc" SQA) if the software uses/requires cryptography/encryption (e.g., key management, password protection, etc.).
Developer Quality Plan
The Developer Quality Plan is utilized to ensure that throughout the development process EPRI quality standards are met. This document should be completed and followed as the development progresses.
Installation Instructions
This document provides an example of the Installation section of a User Manual. The installation section is required for any software which is installed.
Note: The format of this document does not match the format of the EPRI User Manual Template, exercise caution using copy & paste.
Instructions Guide E-Media
The Instructions Guide E-Media document provides information to assist in checking E-Media products before they are submitted to SQA for subsequent distribution.
Note: Exercise caution, this document provides information which may be deprecated.
Mobile App Distribution Checklist
This document is required to be submitted with the Software Acceptance Form (SAF) for any submittal to SQA for testing and app store (Apple and Google Play) distribution.
Mobile Framework
This document provides guidance on the development of Mobile Apps utilizing the Ionic Pro framework.
Note: Contact Web & Mobile for any questions related to this guide.
Remediation Plan
The remediation plan should only be completed for addressing level 3-5 vulnerabilities once steps 1 and 2 have been exhausted.
- Remediate the vulnerabilities and request an SQA rescan.
- Submit evidence that the vulnerability is a false positive for review by Information Security. This can be screenshots, code snippets, other elements, or a combination. Information Security will be looking for this for each represented vulnerability type that is in question. Please use the same input values that the scanner used, where applicable.
Requirement/Policy Exemptions
Check applicable policies for instructions on obtaining an exemption. Submit the approved exemption to the SQA team via e-mail or as a document (DOC, PDF) attached with the SAF Traveler.
If there are no explicit instructions in the policy, send an email message to the person (e.g., Sector Director) who can approve the exemption. In the message, state the business reason for needing the exemption. Copy/forward the approval to SQA@epri.com.
Requirements Specification
The Requirements Specification document addresses EPRI software product and process requirements, including:
-
What users want to accomplish by using the software
-
A complete description of what the software must do (i.e., features and functions)
-
Attributes the software must have, besides functionality (i.e., response time, usability, platform, security levels, etc.)
-
A detailed project plan and schedule noting responsibilities and commitments
The specification is developed by the EPRI Project Manager with assistance from the developer and end-users.
If developers have existing planning documentation formats in place, these may substitute for the specification. In all cases, the content described in the specification needs to be addressed.
Software Acceptance Form (SAF)
The Software Acceptance Form (SAF) is required to submit your software to SQA for the Preproduction or the Production Acceptance testing. Ensure it is completed correctly as incomplete or incorrect information in the SAF will cause delays.
- Replaces the Software Deliverable Requirements Form (SDRF) when submitting a software contract request. Submit it with the Statement of Work (SOW)
- Replaces the Software Product Description & Export Coding Form - Used to provide export classification. The description content will appear as the description for the software product in the EPRI Member Center
Note: If submitting via ECM completing this form is unnecessary as it is built into the ECM workflow.
Software Lifecycle Management Plan
The Software Lifecycle Management Plan documents the expectations for the resulting deliverable’s role in future research.
A software lifecycle management plan has three parts:
- An estimate of how long the work product will be maintained by EPRI in its current role?
- Identification of the program(s) and/or projects that will provide support to maintain the software to EPRI standards during its time as an EPRI product.
- A list of the names of EPRI personnel who will support the project during its time at EPRI and, also, any users.
EPRI Software Manual
The software manual must conform to the EPRI Software Manual Template, the template contains pre-made styles and auto-text. Remember to scan the manual for plagiarism prior to submittal.
Note: Prior to SQA submittal review the Research Integrity Policy for iThenticate compliance.
Source Code Build Instructions
Developer must provide Source Code Build Instructions to SQA along with the software code for all software developed for EPRI. These build instructions must include information beyond just including/naming the source code and compiler(s), such as:
- Specifics of the build platform (such as operating system, build tools)
- Dependencies on native/platform libraries
- References to other third-party software (including version numbers)
- Values for build tool settings, command line switches, etc.
- Includes scripts/settings/configuration for installers (e.g., setup.exe)
Note: Template is not yet available.
Subscriber Website Database Request
Changes in Production may require additional approval from the Change Approval Board (CAB), depending on the type of change requested.
Content-only changes do not require CAB approval. Requests will be performed as they are received.
Examples:
- Insert records into tables
- Update records
- Export records between environments
Structural changes in Production involve downtime and require CAB approval. CAB meetings are held only once a week, and changes in Production can only be performed on certain days. Please expect a longer turnaround time and plan accordingly.
Examples:
- Promote database from DEV/TEST to PROD
- Restore database using backup file
- Change column names
Please use the SWS Database Request E-mail Form for any changes to an application database. The e-mail form will open in your default email client.
Note: You must provide a WBS # to charge with the DB request.
You may provide the file(s) as an email attachment. If you require an alternate approved file-transfer method, please contact SQA.
If button below does not work, please submit the request directly to SWSDBREQ@epri.com, copying the following into the email body:
WBS #:
Environment:
Name of database:
What needs to be done?
File location:
Subscriber Website Kickoff Checklist
The SWS Kickoff Checklist is used to discuss logistics/requirements with the development team and SQA/IT. Use this form as the first step when engaging SQA/IT.
Note: This form is required to be completed in the SWS and Mobile App development process.
Subscriber Website Promotion Checklist
This checklist is required to be submitted with the Software Acceptance Form (SAF) when submitting a Subscriber Website (SWS) to SQA for Preproduction or Production Acceptance Testing. It is the Project Manager's and Developer's responsibility to review the process and verify that the process being used and provided by this form is correct for the site being promoted.
Promotion of Subscriber Websites (SWS) with a Database may take additional time to schedule and perform in comparison to a site without one, plan accordingly to avoid issues with deadlines.
Web & Mobile UX Guide
This document provides examples of EPRI branding and user experience elements which should be used in the process of SWS/Mobile App development.
Note: Please contact Web & Mobile with any questions related to this guide.
Note: Expectations for footer content can be found here.
3rd Party Software Spreadsheet
This spreadsheet is to be filled out and provided alongside your SQA Submittal should your software utilize any 3rd party software.