Intelligent Business Requirements

Intelligent Business Requirements are business needs and objectives that were designed to add business value and promote scalability and innovation.

‘Project success’ is the attainment of predefined criteria that emerge from attainment of user requirements. User requirements, in turn, are defined by an evaluation of the business and functional requirements. Thus requirements pave the path that leads to project success.

It will not be an overstatement to claim that intelligently conceived requirements invariably lead to a winning formula. Requirements in themselves are statements of the desired state, but collectively, these are greater than the ‘what’, ‘why’, and ‘how’. Thus requirements go far beyond mere user statements. The captured user requirements do not necessarily guarantee that what has been identified and stated is a true reflection of the exact requirement. User requirements must be intelligently identified, captured, and stated to ensure that these drive attainment of the desired outcome.

Information is vital for defining requirements and can be gathered through various channels. It is used to evaluate the criticality of the desired requirements and help establish priority. Information can be acquired through varied sources, such as interpersonal interaction, written communication, documents, and reports. The system of remodelling the unknown to arrive at acknowledged facts, issues, conditions, and legacy and the subsequent analysis to identify requirements is actually a process and not an end in itself. Literature recommends “validation” of the requirements as a quality check prior to developing a solution to address the business problem.

BABOK defines Requirements Validation as follows: “Ensure that all requirements support the delivery of value to the business, fulfil its goals and objectives, and meet a stakeholder need.” This definition emphasises three important aspects: “value”, “fulfil goals”, and “meet a need”. However, it still left the following questions unanswered:

1. What is the “value” that a requirement is meant to deliver?
2. How can we ensure that the requirements will deliver the specified outcome?

Requirements validation is a very significant aspect that should go beyond and should never be treated as just a validation check. I recommend a two-tier requirements validation. The primary tier is a preliminary validation of the requirements. The first tier is considered to be the sanity check to ensure that the requirements are within the scope and intend to deliver a solution along with a commercial value. It’s ensuring whether the user requirement is warranted.

However, the first-tier validation does not necessarily validate whether the requirements add value. In order to add value to a business, it is required to further evaluate the finer aspects of user requirements. Hence, the second tier of validation should be performed to understand the following aspects: Does the user requirement qualify as intelligent?

Tier 1 Validation: Warranted and Meets Business Goals

As per the BABOK definition, a requirement is ‘warranted’ if it meets the need and fits within the organisational objectives. This tier of validation is a quality assurance of the requirement. This check ensures the reliability and guarantees that the right outcome will be delivered, acting through to achieve the defined requirement. We need to ensure the following:

1. Does the requirement intend to deliver what is promised?
2. Is the requirement intended to achieve the business goals?

Does It Deliver What Is Promised?

The intent of requirements is to lay the foundation for a solution. A simplistic interpretation defines a requirement in terms of the following two assertions: a) this is what I want and b) this is my problem.

The requirements and their intended solution have an interesting relationship. If they are tightly coupled, the requirements tend to be defective; consequently, the solution has restricted applicability. Hence it can be safely assumed that a restricted solution was based on unwarranted requirements. The intent to deliver what has been promised helps ensure that the proposed requirements will lead to the right solution. However, it is unfortunate that there is no exact formula to derive a perfect solution. Validation is largely a checklist. I used these criteria:

1. Are there multiple sources of information? A single source may run a risk of being biased. Multiple sources go a long way toward removing or diluting the impact of a biased source.
2. Evaluation of multiple objectives emerges from different sources. This is necessary to ensure that every aspect is considered in order to arrive at an effective solution.
3. Is there a mechanism in place for conflict resolution? Divergent facts provided by different sources should be understood to resolve and identify the facts in order to establish and resolve conflict. This also makes it possible to determine the priority for inclusion.
4. Singular truth should prevail. There are multiple versions of truth. Synthesizing all these versions can help deduce the one singular truth that will prevail in all scenarios.
5. Is there an established process for review by impacted stakeholders? The analysis should be communicated back to the stakeholders for review and refinement.
6. Test to uphold the assumption that what is being conveyed as a “requirement” is all ‘known’ and that nothing is left to ‘unknown’.
7. Test to establish the relevance and urgency of the requirement.

Achieve Business Goals

Goals are specific results that an organisation aims to achieve. An example of a clearly defined goal could be as outlined as “to reduce the mortgage application processing time from three business days to twenty-four hours”. Often we undermine the significance of requirement analysis and end up proposing requirements that miss the targeted business goal. Consequently, the requirement fails to add value. Further, it is recommended to remain within the boundaries set by the business goals. This enables the ability to reinforce the focus required to achieve the desired outcome.

Intelligent Business Requirements

Warranted requirements ensure the delivery of the desired outcome. However, we need to go beyond and above to assess whether our requirements are “intelligent”. Intelligent requirements enable us to gauge if the future desired state is sustainable. The following checks help when validating the requirements as intelligent.

1. Is the requirement innovative or regressive?
2. Is the requirement future-proof?
3. Is the requirement targeted to achieve a sustainable solution or outcome?

Innovation

Einstein aptly stated, “The true sign of intelligence is not knowledge but imagination.” The concept of innovation advocates ‘change’ to establish a new form that is a distinct elevation from the conventional form. However, this concept is a little difficult to put into practice while developing requirements. We tend to be preoccupied with identifying the problem and seldom pay attention in order to innovate. We invariably end up settling for the basic requirement using conventional methods. Every problem statement is an opportunity to innovate, and an intelligent evaluation of the business scenario can yield process improvements through ‘thinking outside of the box’. It also enables taking the solution to explore thinking ahead and leads to value addition.

Future-proof

Very few things are truly future- proof. In any field that depends heavily on technology, a regular cycle of replacing and updating appears to be the norm. However, if you have innovated, then you probably are future proof. Again, this will only hold true if you have not settled for the basics. The requirements should address a problem and provide a solution that continues to be of value, even into the distant future. This is not as straightforward as it appears. That’s why a business analyst is called an “analyst”—because it needs a ‘great bit’ to figure out. Future-proof describes the exclusive process of identifying and anticipating the future developments in order to seize and exploit opportunities and to take actions that minimize or mitigate negative consequences. In the true sense, this is yet another opportunity to innovate and embrace the future.

Scalable

Scalable describes the ability of a solution to persist and resist the impact of potential future change due to growth, organisational restructuring, acquisitions, etc. The proposed requirement should be capable of delivering a solution that leads to a scalable future state. This can be achieved by determining the sustainability quotient by understanding what makes it scalable, flexible, and reusable.

There is no perfect process, structure, or method that will always guarantee a valid outcome. Some collection methods are considered unsuitable in most situations or organisations. These should be avoided at all cost to mitigate the risk of unwarranted and misleading requirements. Various parameters need to be considered while selecting a requirements collection technique. A few aspects that need to be considered are organisational culture, source of information, buy-in from impacted stakeholders, organisational politics, conflicting agendas, etc.

These constraints usually influence the outcome of the analysis and establish the process of uncovering the ‘unknown’ to ‘known’, consequently resultant in defective or biased requirements that may be incompatible with the organisational culture.