Recently I've attended ProductCamp Toronto. There I presented the topic "Hidden requirements and how to find them". In this post, I'd like to talk more about it.
Requirements are one of the core parts of every software project. It is impossible to develop anything without having an understanding of what is being developed. Explicit requirements are communicated in various formats: project specs, user stories, emails, etc. But usually, there are many other requirements. Those I called "hidden requirements". They are either implicitly communicated, or come from expectations, and in worst cases, they are completely unknown. Eventually, important requirements get uncovered. But the later it happens the harder it is to adjust the development process or add new functionality. There are some categories of requirements that are often missed during initial requirement analysis and design. Being aware of these categories will help you recognize pitfalls early.
During requirements gathering and analysis stage mostly discussed things are happy paths, how software will deliver value to the user, what steps user has to go through to achieve the result. But the real world is not all unicorns and rainbows. There are so many things that can go wrong. One of the most common cases is bad connectivity or absence of internet connection at all for mobile users. Another good example would be insufficient funds in the user account. User input may be wrong, and somehow application should inform the user about it. Any error that occurs during the application lifecycle must be handled somehow.
If these requirements are not discussed and design is not done it is essentially left to developers to figure out something. Developers may ask questions, but they cannot stall work waiting for answers. Thus most likely they will provide some default error handling. It might be something as simple as error logging, or simple alert, and making sure application does not crash. In most applications, unhappy path logic is actually a significant part of the code. But it is rarely good enough for the project needs. Improper error handling may result in poor user experience. On the other hand, advanced handling may help deliver value and win users.
To uncover these requirements think what can go wrong at each step of user interaction.
"An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter." - from Wikipedia.
The corner case is a combination of multiple edge cases. Similar to errors they happen all the time. Every user interaction can potentially hit an edge case. Here are some examples. The user has a new account with nothing in it, search results are empty, or too many search results, user name, address, whatever other input is too long or too short, network is very slow.
If not handled properly, edge cases become unhappy paths. It is important to correctly set limits, handle unusual situations gracefully, and be able to recognize when limits should be adjusted.
To uncover these requirements think if there are any unconstrained sources of data for application to process. Also, think about places in the application that normally should have some data but there may be none.
New features, modules are often designed in isolation. But sometimes when implementation and integration is done it becomes apparent that other modules need improvement as well. Which requires additional effort. For example a new payment method is added, but there is a transaction history module that needs an update; or new fields are added to registration process, but profile editing may need some of those fields too; or new buttons are added, and look nice on large-screen devices, but do not fit in smaller devices.
Again, if these interactions are missed during requirements analysis and design phases, it becomes more expensive to adjust once they are discovered. And in worst case software with gaps and poor user experience may be shipped.
To uncover these requirements think about associations that come to mind when designing new feature. If anything in existing features seems to be close. Similar concepts even from different modules are usually described with the same terms. Thus searching if domain specific language already contains terms or synonyms of new feature is very useful.
Compliance And Security
GDPR recently has come into force in EU. It has shaken up the industry. Some companies even went out of business. Caring about user data security and privacy kind of always was a thing, but nowadays governments all over the world turn their eyes on to inadequate user data protection. Depending on the software these requirements may require significant effort to satisfy.
If any user data is collected by application, make sure it will comply with operating area laws. Next, make sure user data is adequately protected, and this protection may be supported over time. Supposedly this should be a developers concern. But developers don't have a big picture, thus may over or under engineer solution. For example, if you are preparing to launch in North America, and move to EU only later, you may not need to fully comply with GDPR (although it is highly recommended). Let your team know about this requirement so that they keep solution flexible to support GDPR in the future, but not over-invest right away. Or maybe one of your product features is advanced security and developers should pay more attention to it.
To uncover these requirements think if software processes any user data. Any piece of information about the user, their device, or activity constitutes as user data. This data MUST be secured.
Target Audience Specifics
Gathering information about the target audience is a common practice for businesses. Knowing the target audience is essential in the most cases. Product managers, business analysts create user personas and work with those to derive requirements. Nevertheless, it often happens that some requirements associated with these personas are communicated implicitly. But as in all previous cases, this leads to issues.
For example, localization may be or may not be required. So developers need to know somehow if it is a requirement to invest appropriately. Especially if both left-to-right and right-to-left languages are going to be supported. Another example is accessibility requirements for children or elderly people in medical application. In such cases not recognizing requirement early usually leads to additional expenses down the road. There are also situations when it is possible to save money on initial development. Like when enterprise application will only be used on the large screen devices, thus no need to spend the time to support smaller devices.
To uncover these requirements think of all target audience attributes that come to your mind, and write them down clearly. Even if there is nothing notable today, future changes of the target audience may add something new.
This type of requirements is different from what was discussed before. These are process requirements, not product requirements. It is about how the project should be approached by developers, designers, testers, etc. For example usage of specific tools, usage of specific methodologies to align with existing business processes, high bus factor for critical components, ability to change development team to move development in-house in the future, ability to scale product in a specific way.
I think these requirements are one of the most important. They influence time and cost a lot. This is the type of requirements that make a significant difference in project costs with a seemingly same set of features. The biggest issue with meta requirements is that they are rarely discussed. In outsourced projects, it often so happens that developers are left with their own assumptions and let free to decide what process to follow. So they follow whatever they are used to, not what is good for the product. Eventually, it leads to losses when misses are uncovered. Sometimes this may threaten project and company existence.
To uncover these requirements think how software development lifecycle should be integrated with existing business processes. Think about potential risks and if it is worth minimizing some of them.
These are the main categories to pay attention to when working with project requirements. It may seem like a lot, but with some practice, these questions are asked unconsciously. Even if there is a business analyst on your team it does not hurt. Consider educating other people on your team as well. Chances of missing important requirements go down drastically when everybody involved in the development process is looking consciously or not for gaps. This article is a good place to start.
Thank you for reading. Please share your thoughts and stay tuned!