Software Requirements Guidelines



Subscriber Website (SWS) & Mobile App

Kick-off Meeting Checklist

Before submitting this checklist and starting development, a consultation with Web & Mobile Solutions is required as per the IT Intake process for new websites. Please contact Jon Charles to setup an IT Intake meeting.

Note: The official Subscriber Website (SWS) Process can found on and should be regarded as the “source of truth” for the most up to date version of the process.

To start the Subscriber Website (SWS) process, the EPRI project manager must:

1. Complete steps 1 & 2 of the SWS Process (link above).

2. Complete this Kick-off Meeting Checklist and e-mail it to the SQA team with the design and URL approvals.

To start the Mobile App process, the EPRI project manager must:

1. Complete this Kick-off Meeting Checklist and e-mail it to the SQA team with the design approval.

SQA will schedule a kick-off meeting to review this checklist and approve start of development.

|Checklist |Answers |

|Application Information | |

|SWS/Mobile App Name: |      |

|SWS/Mobile App Acronym: |      |

|SWS URL (e.g., SWS.): |      |

|Project Manager (name, e-mail, phone): |      |

|Sector/Department: |      |

|Project Work Order # (WBS): |      |

|Pre-Production (e.g., Beta) Product ID: |      |

|For Pre-Production Product ID, contact your Master of Materials | |

|Production (e.g., Final Acceptance) Product ID: |      |

|For Production Product ID’s contact your Master of Materials | |

|SWS Product ID: |      |

|If this web application is going to be protected, a Subscriber Website (SWS) product ID | |

|must be created with appropriate mappings in the SAP system. Contact Richard Pettit to | |

|obtain the SWS ID. Nuclear Sector staff must follow the Nuclear Sector SWS Product ID | |

|Export Control Process. | |

|Lead Technical Developer (name, e-mail, phone): |      |

|External Developer (if applicable) (company, address, name, e-mail, phone) |      |

|Alternate Contact (name, e-mail, phone) if project manager and developer are unavailable: |      |

|Are there plans for a mobile version? Define OS. |      |

|Is there an existing SWS/Mobile App that is like this application? |      |

|Purpose | |

|What is the purpose of the SWS/Mobile App? |      |

| Define key functionalities and elements (i.e. Tables, Tabs, Calendars, etc.) |      |

|Schedule |Date Format: MM/DD/YY |

|Date to provide source code and build to EPRI? If not ready, provide an estimated date. |      |

|Pre-Production testing submittal date to SQA? |      |

|Production testing submittal date to SQA? |      |

|Planned Completion Date (PCD)? |      |

|Technology: | |

| | |

|Subscriber Website (SWS) must be compatible on the following stack: | |

|Microsoft Windows Server 2016 | |

|Microsoft Internet Information Server 10 | |

|Microsoft .NET Framework | |

|Microsoft SQL Server 2016 | |

| | |

|Supported programming languages: | |

|All .NET programming languages (C#, , etc.) | |

|JavaScript | |

|Python* | |

|*Note: Environment for Python-driven SWS must be discussed with SQA prior to starting | |

|development. Pre-requisites and other dependencies may require approval from IT | |

|Management. | |

| | |

|Mobile Apps must be developed with EPRI approved framework and follow current | |

|requirements: | |

|Ionic: | |

| | |

| | |

| | |

|If your stack requirements do not meet the technology requirements above, state your |      |

|requirements here. | |

| | |

|Note that Pre-requisites and other dependencies may require approval from IT Management | |

|prior to starting development. | |

|Does your application utilize any protocols aside from HTTP or HTTPS (e.g. wss) |      |

|Application Capacity / Bandwidth |  |

|Estimate: How big is your application data in megabytes/gigabytes and its annual rate of |      |

|growth? | |

|Are there any files being created on the server’s file system (e.g. uploads)? |      |

|Approximately how many users will be accessing this application? |      |

|Do you anticipate any heavy data processing or response time issues? |      |

|Database Configuration / Capacity / Bandwidth | |

|Approximate size of database in number of Tables and Rows and its annual rate of growth? |      |

|What is the approximate size of database in either, MB, GB or TB? |      |

|What would be the approximate shelf life for this database? |      |

|What is the Minimum SQL Server Edition requirement? |      |

|Would there be an issue if we decide to use a higher edition/version of the SQL Server? |      |

|What should be the recovery model for DBs? Full (Managed Transaction Logs) / Simple? |      |

|What should be the Compatibility Level for DBs? |      |

|Application Details | |

|Is this a read only type of application or is this transactional (e.g. update, insert, |      |

|delete)? | |

|Will you have regular content updates? Please explain potential update cycles. |      |

|What is the minimum support term (i.e., years)? |      |

|Access Control / PING / Users / Security | |

|Is there an administrator with special access rights to the application? |      |

|Are all users deemed equal for access purposes? |      |

|Is this web application limited to funders? |      |

|If this web application is going to be free to the public you must: | |

|Submit the Free Posting Form to legal | |

|Forward the approved Free Posting Form to your sector’s master of materials (MOM) | |

|What type of users do you expect to use the application? |      |

|What roles or functions will exist for external users? |      |

|Can they post information? |      |

|Can they edit information? |      |

|Can they delete information? |      |

|Can they see other user’s postings? |      |

|What roles or functions will exist for internal or special users? |      |

|Can they post information? |      |

|Can they edit information? |      |

|Can they delete information? |      |

|Can they see other user’s postings? |      |

|Is the information sensitive? |      |

|Change Control Process |  |

|Please acknowledge that you understand and agree that a Change Control form must be |      |

|submitted and approved before updates are promoted to Production? | |

SWS Integration and Planning Checklist

For guidance on working with IT-SQA to make the SWS functional, utilize this checklist.

|Step # |Action |Responsible Party |

|1a |PM to contact SQA to setup SWS development CX consultation with Web & Mobile Solutions & Digital |PM |

| |Marketing teams. Review Subscriber Website (SWS) process | |

|1b |PM to obtain Design approval from primary UX Engineer |PM |

|1c |PM to obtain URL (e.g., SWS.) approval. Indicate if this SWS will be a free-results posting |PM, SQA |

| |(zero-priced/public). | |

|2a |PM to contact SQA to setup SWS Kick-off meeting. This meeting will establish requirements up front |PM |

| |(e.g., security, technologies, and formatting), plan/schedule reviews throughout the project with all | |

| |affected parties. | |

|2b |PM to work with SQA on server requirements. IT Management will need to be consulted if the site utilizes|PM, SQA |

| |unsupported software. | |

|3a |PM obtains Preproduction and/or Production Product ID |PM |

|3b |PM obtains Subscriber Website Product ID (N/A if free-results). |PM |

|4 |When URL is provided, SQA requests DNS entries from Service Desk. Create DNS entries for: |SQA, Infrastructure |

| |Development Server (DEV) – sitenamedev. | |

| |Test Server (TEST) – sitenametest. | |

| |Production Server (PROD) – sitename. | |

|5 |If new servers are required then firewall rules will need to be setup for: |InfoSec, Network Services |

| |Internal HTTP/S access to Server – Port 80/443 | |

| |PING access to Server | |

| |Server access to PING (if site requires login to another SWS) | |

| |Server access to Database | |

| |Server access to SMTP (if email functionality is used) | |

|6 |Setup server with appropriate host file entries (if needed) |SQA |

|7 |Install/Configure MS Deploy on Servers and give admin access to SWSDeployAgent service account for the |SQA |

| |appropriate domain | |

|8 |Obtain a GitLab Repository by sending the following to SQA@: |PM or Developer |

| |Project GitLab Repo Name (letters, digits, underscores, dashes, and periods only) | |

| |Developer EPRI Network ID(s) and emails | |

|9 |Provide developer/contractor GitLab Access and create project |SQA |

|10 |Provide developer/contractor VPN access if contractor is external to EPRI. |Service Desk |

|11 |Developer connects to VPN and checks-in the application’s source code to GitLab repository DEV branch. |Developer |

| | | |

| |Note: DO NOT check in build artifacts (i.e. DLLs, EXEs, etc.) or other binary files unless you’ve | |

| |informed SQA and gotten approval. | |

|12 |Provide scripts or export file (.bak) of database to DBA team so that it can be run/imported onto |DBA |

| |centralized database server specific to the DEV environment. | |

|13 |Infrastructure configures PING policy for DEV, TEST, and PROD |Infrastructure |

|14 |Initial Deployment - Developer provides documentation for the following: |Developer, SQA |

| |Setting up application dependencies | |

| |Compiling application source code | |

| |Which build artifacts and files to deploy to web server | |

| |Which files/folders are being created or modified at application runtime (Note: This is especially | |

| |important to ensure that data stored on the file system isn’t overwritten by subsequent deployments) | |

| | | |

| |SQA will use the provided documentation to configure an automated deployment script that will build and | |

| |deploy the code. | |

|15 |Developer/PM confirms that DEV functions as expected. Requests for the TEST site to be created. |Developer, PM |

|16 |Developer makes changes in DEV as necessary to prepare for testing and the next release |Developer |

|17 |Promote Application code to TEST |SQA |

|18 |Promote Database to TEST |DBA |

|19 |Developer/PM confirms that TEST functions as expected. |Developer, PM |

|20 |Submit Pre-Production (Beta) Package to SQA |PM |

| |Note: Pre-Production testing is required for all new software deliverables unless an exemption is | |

| |obtained | |

| | | |

| |OR | |

| | | |

| |Submit Production (Final Acceptance) Testing Package to SQA | |

|21 |SQA performs Usability Testing |SQA |

|22 |SQA provides approval to PM and schedules a promotion date and time |SQA |

|23 |Verify that SWS Promotion Checklist is up-to-date and correct |PM and Developer |

| | | |

| |Note 1: The Promotion Checklist will specify instructions for database promotion. Some examples of | |

| |common promotion procedures are: | |

| |Full backup and restore | |

| |Run script to upgrade existing PROD database and then restore in BETA | |

| |Run script to clean data from testing and then promote to BETA | |

| | | |

| |Please test your SQL scripts in DEV or TEST prior to the scheduled promotion time in order to avoid | |

| |delays and excessive downtime for the site | |

| | | |

| |Note 2: If this a BETA version of an SWS already in PROD then specify which URL you’d like to promote | |

| |the site to in this document (i.e. sitenamebeta. or sitename.). | |

|24 |(Pre-production only) Create CRM list with list of Members that will be Beta testing. PM to provide list|PM |

| |of qualified contacts that exist in CRM (Full Name, email, and Company Name) | |

|25 |Configure PING Policy for PROD (if needed) |Infrastructure |

|26 |Promote Code to PROD |SQA |

|27 |Promote Database to PROD |Infrastructure |

|28 |(Pre-production only) Provide URL to End User to do Beta testing |PM |

|29 |(Pre-production only) Execute End-User Production Beta Testing |PM, Members |

|30 |(Pre-production only) Provide feedback to developer |PM, Members |

|31 |(Pre-production only) Return to step 16 and continue |Developer |

|32 |SQA requests activation for the SWS in SAP |SQA |

|33 |PM Announces that the SWS is now live to their members |PM |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download