We can have an incredible vision for a product and then fall short due to additional requirements. Industry requirements or regulations burden our solution and can even make it unviable. Likewise, these are often constraints on our solution that cannot be avoided or ignored. They might add to the cost and force the design to be done in a way that would not be our first choice. Therefore, we need to list any such requirements from the start and provide the correct context for our solution.

Plan For Requirements Or Regulations

One of the costly mistakes we can make is getting started on a project and then changing course. While those costs can sometimes be avoided, that is not possible if there are regulations or compliance factors for our solution. Thus, this is an area where the mistake is completely avoidable. All it takes is asking the question. Once we know the industry or corporate requirements or regulations, we can determine how they impact our solution.

Common Compliance Requirements

There are many ways a system can be required to be in compliance with regulations. They are not all game-changing needs. However, several common constraints are best addressed from the start. We want to ensure these detailed questions have been thoroughly answered before proceeding with our design.

• Are there particular security constraints? This can range from complex password requirements to encryption levels and remote access. For example, that can include steps to ensure we know who a user is and that they are a valid customer (geographic, age, or other restrictions)
• Do we need any additional requirements for our data? There might be a limit to what data is shown (PII/PHI and account numbers) or where it can be stored. We might be required to encrypt all data, store it separately from an account identifying number, or be allowed to transfer data across boundaries.
• Do we need to utilize data updates? This need can be as simple as grabbing the latest valid zip codes or ICD10 values or something much more complex like current tax calculations.
• Do we need multilingual support and unique access? These sorts of requirements can range from allowing users to use the application in their native language to access for blind or other impaired users that take advantage of screen readers and other technology.

Data and Reporting Requirements

• Part 1: Are there additional reporting requirements? This may seem like a minor addition. However, we cannot report on data we do not have. Thus, we may need to store more data than we intended. That can include audit information and complex data change logging.
• Part 2: Are there additional reporting requirements? For example, we might need to integrate with systems to report tax, sales, or other data.
• Are there disaster recovery or backup specifications to be met? Not all software has a life-or-death level problem it address. However, industry requirements exist for our systems’ availability or at least some confidence that the data will not be lost.
• Do we need to keep records for a certain length of time? Data can pile up quickly, and sometimes it is easiest to purge old data from a system regularly. Unfortunately, that is not always possible. There are reporting requirements that can go back five or more years.

Need To Know

The difference with industry requirements or regulations is that we can not get around them. Some restrictions can make it very difficult to retrofit our design to support them. When we plan with these in mind, it is very helpful. It might even be a critical factor in our success. Likewise, no one likes to be deep into a project and hear, “oh, did I forget to mention this requirement?”

Signing Off On This Question

This question may be as simple as a “no” answer or require a document. HIPPA and other compliance requirements can be lengthy and require an expert to help you navigate how to build a compliant product. A project can start without a complete answer to this question. However, the sooner you have a full response, the better. That minimizes the chances that the design needs to be reworked down the road.

Improve Software Success

We have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.