<aside> 🎯 In this chapter, you will learn more about stating the obvious: how to identify, elaborate and specify considerations for selecting a solution. You will see how we approach this for selecting an Identity Provider solution.
</aside>
A solution is only as good as its requirements. This is probably obvious but what may not be obvious is how to differentiate between good requirements and okay requirements. Understanding and describing what truly matters may be the toughest aspect of a technical decision. This requires a broad net of consideration but a high bar and critical eye for selection. Analysis paralysis from over-specified requirements is a common and dangerous trap for technical decision makers.
<aside> 🚨 There's a good chance you feel like you have an innate understanding of the needs for your solution and you will feel tempted to skip this section. You may already have a short-list of options that you are considering and want to skip quickly to a decision. Time to take a pause.
Even if the above is true, take at least 15 minutes to reflect on the needs and write them down. This may or may not sway a foregone decision but it will either give you confidence in your decision or flag areas of risk for later parts of the TDR.
Read on for suggestions to prevent this section from hand-tying the decision.
</aside>
There's a balance to the level of detail you drive toward for your needs and requirements. If they are too tightly specified, you may unnecessarily constrain the solution and even prematurely eliminate options. Of course, you also don't want to miss a key consideration and regret it later.
Here are some general tips for finding this balance:
<aside> 👉🏼 Good: The licensing system must be notified as new users confirm their registrations.
Too Specific: The IdP solution should include the ability to add custom web hooks to the registration flow to be invoked asynchronously whenever a user confirms their email address during enrolment.
</aside>
Classify as "Must Have", "Should Have", or "Nice to Have". Not all needs are equal. Be prudent in how you classify requirements. In particular, be conservative with what are the "Must Have" requirements. For example, there are a lot of things an Identity Provider solution Should Have but probably only a handful of requirements are absolute Must Have.
Don't over-prioritize the future. Focus on current needs and be cautious including future needs that look beyond a year or so. Unless your organization locks in and delivers on multi-year plans, the reality is that those long-term future needs will shift based on product and market direction. The options you will be evaluating are also evolving.
Better than distant future needs, are Should Have requirements that will lead to future flexibility. APIs, hooks, standardized protocols, and other customization features provide more adaptable options than fixed future requirements.
Use common sense. Skip the obvious stuff. The goal of a TDR is not to provide an air-tight reasoned argument that stands alone like a mathematics proof. If your organization expects that, you already have a decision making process far more mature than TDRs. With this in mind, capture the key features that are going to guide a decision. You have already defined the audience with in the Participants section so write at a level appropriate to them.
Pay attention to non-functional requirements. Product owners are quick to suggest a variety of functional needs and requirements but non-functional requirements are sometimes tougher to accommodate. In fact, in our experience, non-functional requirements are more likely to be the deciding factor between the the options.
Align stakeholders on needs and requirements. Before you dive in on options and evaluation, do a check that the stakeholders are aligned on the needs and requirements that you have captured. A good way to do this is to collaboratively write the needs and requirements in the TDR during a working session. Keep this session focussed on gathering inputs and not jumping to the solution.
Let's return to the Identity Provider TDR example again. Through this lens we'll enumerate potential needs and requiements. Even if your technical decision is drastically different, the breakdown that follows will spark ideas that will be applicable.
As suggested above, we'll start with a wide net to collect needs and understand the decision space but the details that we would include in a TDR would represent a consolidated list of what matters in the particular decision making context. It wouldn't be unreasonable to restrict the eventual criteria to 5-7 high level must-have requirements with a complement of nice-to-have.
It is often easiest to start with functional requirements because they are so openly discussed.
Think about all of the users and systems that will be integrating with your solution. For an IdP selection decision, this will pull you away from thinking just about the login screen. The realm of functionality included by modern IdP's is broad and complex. Identity, authentication, and authorization are all inter-related. What are the desired bounds of the solution for your application?