Requirements vs. Wish Lists: Translating EHS Program Needs into Implementable System Designs

What is a Software Requirement?

Well-developed software requirements are the foundation of successful strategic preparation for software projects (often called “Phase 0s”), digital selections, and digital implementations. If the requirements defined don’t match a process, the software can add frustration and appear to be lacking features or functionality. When requirements are well-written and thorough, project success is more likely, and meeting all the requirements leads the user community to acceptance of the project and/or product as effective and useful.

At the start of every digital project, the business team [usually environmental, health, and safety (EHS) professionals] and the Information Technology (IT) teams have a “wish list” of features or tasks the software should be able to do. In this list, there are usually some things that are simple to implement, and some that may be complex and less practical. Business or IT teams not familiar with EHS Software often cannot tell the difference between the two extremes. How do you get from this wish list to a list of requirements that match your business process and can be successfully implemented?

Steps to Refine Wish Lists into Software Requirements

Here are some steps that help develop projects goals into discrete requirements that can lead to project success and user acceptance:

1. Consolidate wish lists from all stakeholders into one requirements list. Remove any duplicate requirements and refine the requirement list.
   1. Note that the best practice is to do the duplicate clean up before further refining the list.
2. Consider the full picture when making a requirement list. The importance of input from all stakeholders can’t be overstated. Areas that are often overlooked include:
   1. EHS reporting requirements.
   2. IT requirements such as single sign on (SSO), cybersecurity, and/or internal Digital Privacy Impact Assessment (PIA).
   3. The end user experience (e.g., iPhone vs. Android mobile usage).
   4. Permissions – which people or what groups should be able to see and edit what information at various stages.
   5. Notification triggers, subjects, bodies, and recipients should be explicitly stated in requirements.
3. Determine which requirements are “must haves” versus “nice to haves.”
   1. Discussion between different EHS professionals and multiple stakeholders may be required.
   2. If all requirements are being called “must haves,” then revisit with a tighter filter to determine which requirements are truly mission critical.
4. Re-write requirements as needed using IT team members and EHS team members. IT team members can help balance specifics with broadness to create software requirements that can be implemented.
   1. Good requirement example: Need to have triggering questions to show or hide groups of conditional audit questions.
   2. Example requirement that is too broad: Need to be able to have some conditional display audit questions.
5. Review with all stakeholders to be sure that any critical information has not been lost in the refining process and that they are aligned to what a successful implementation would look like. The more complete and concrete the requirements are, the smoother the digital selection or implementation will go for all parties.

Note that it is normal to desire scope changes or feature changes after implementation once users get into the system. Change design can also be discussed and implemented later.

A successful digital project starts with translating the EHS business team’s wish list into implementable software requirements. The above steps are a high-level process for crafting solid requirements. If you would like to discuss more, please contact Rena Wolinsky at rwolinsky@all4inc.com or 732-858-4013 or Julie Taccino at jtaccino@all4inc.com or 281-201-1247.