Step 2: Validating Stakeholder Requirements

Following the identification of the stakeholder requirements and the creation of the initial document that combines them into a coherent—albeit conflicting—whole, it's time for the next stage of the design process, which is the validation of the requirements. The key elements of this stage are achieving consensus where potential conflicts exist and assigning priorities to all aspects of the proposed solution.

Achieving Consensus

No networking solution implementation occurs in a vacuum. If you are able to design an entire solution from the ground up without much concern for integration with existing systems, consider yourself fortunate because you can design the appropriate supporting components at the same time. It's more of an exception than a rule, but it happens. Generally, any proposed solution must integrate into an existing networking infrastructure and applications environment.

The process of identifying the stakeholder requirements leading to the creation of a design document is intended to flush out all of the relevant issues that need to be considered prior to implementation. For example, designing a CRM solution might bring up the issue of needing a greater level of network security. An SMB might have to decide whether or not the CRM solution implementation can proceed without upgrading security, or, if the SMB decides on security upgrades, then to what level, at what pace, and at what cost? This is where the designer's negotiation and mediation skills, as well as long-term vision, come in handy.

Assigning Priorities

Intuitively, it seems that everybody understands the concept of priorities, and there is sufficient lip service being paid to that principle in the business environments. However, when faced with multiple choices, assigning priorities and sticking to them usually requires a significant amount of willpower and can prove to be a daunting task.

If you are familiar with the Request For Comments (RFC) documents that specify numerous Internet protocols, you might already be aware of the terminology that's used in them. It's simple; the keywords used for identifying features of protocols that are to be implemented by vendors are MUST, MUST NOT, SHOULD, and MAY. These keywords also happen to be appropriate for assigning levels of priorities to aspects of complex networking solutions.

Do not confuse priority level with the order of execution of tasks that leads to solution implementation. When groups of tasks have been assigned the same level of priority, you still need to decide on the order of implementation.

MUST

The MUST keyword represents an absolute requirement. For example, if a CRM solution requires a certain type of server to support the application, then it's a MUST. The application simply will not work on anything else. If a certain bandwidth is required between servers because the CRM application is distributed, then it's also a must.

However, upgrading network security might not necessarily be in the same category as having a server with sufficient processing power or having sufficient bandwidth between servers. CRM will still work without a security solution, but the information that is collected through the application might be vulnerable to outside penetration or even an internal compromise.

MUST NOT

The MUST NOT keyword can be as important as MUST. If you are designing a security solution and identify that it's a MUST to have only one access point from the internal network to the Internet, it is equally important to state that there MUST NOT be any other access points—that is, end users placing modems into their workstations and bypassing the implemented security solution that offers protection from hackers and viruses.

SHOULD

The SHOULD keyword translates into something that is recommended. Whereas MUST and MUST NOT are quite clear cut, the SHOULD label is likely to entail a significant amount of debate. Generally, if something is recommended, it involves a certain amount of risk that must be taken under certain conditions if there is no follow-through on the recommendation.

For example, at an installation with a lot of sensitive data stored on its servers, having a firewall to protect the data from external security threats might be a MUST. But having an intrusion detection system (IDS) that checks for unusual traffic patterns on the internal network and potential penetrations through the firewall might fall into the category of SHOULD. If, however, there is no tolerance for any risk level related to security, an IDS becomes a MUST, just like the firewall.

MAY

The MAY keyword implies something that is optional. Assigning this label to an aspect of a solution can also be a challenge, because if it's really nonessential, why bother with it to begin with? But you will end up with some instance where MAY is appropriate if you go through the process of identifying the stakeholder requirements.

Have you ever listened to the news or read in a newspaper report about governments allowing their nonessential embassy staff to be evacuated from certain countries in times of crisis? Have you ever wondered what nonessential really means? One way to determine what is optional is to go through all of the aspects of the proposed solution and decide what is a MUST and what is a SHOULD. Everything that is left over will be MAY (that is, optional) by default.

Output from the Validation of Requirements Stage

Output from the validation of the requirements stage should be a set of functional requirements agreed upon among the diverse groups of stakeholders. It ought to present a basis for a common vision of what the solution is all about. It's a high-level blueprint; it's not a design document yet, but it's getting there. The MUST and selected SHOULD requirements can now be subjected to constraints of topology, performance, budget, and an implementation schedule.