How to Achieve Quality in Solution Requirements

Solutions Requirements of Quality

All organizations want clarity and alignment between stakeholders, but often the approach can be lacking, creating distance between strategic needs and implementation tactics, or in other words, leading to solutions requirements with insufficient quality.

The techniques for modeling a requirement can be many, as we have introduced.

Among the tools suggested by Babok v3 we find the checklists, easily adaptable to your needs, but able to give structure to the very nature of the information.

In this article we explore the ways in which we can ensure that the requirements related to the solution (Solution Requirements) are actually of high quality, with any considerations to be made to be traced back to the business requirements (Business Requirements).

Organizational Aspects

In the Software Development field, organizations that work according to adaptive approaches (especially of an Agile nature, more or less mature) risk not having the right practices to ensure quality in requirements, justified by the iterative nature of the implemented processes.

Given that organizational learning is built with interpersonal exchange and stakeholder buy-in, practices that act on structural aspects (rather than on the agency of the actors) still have an important force in bringing about change. These practices signal the guidance that the organization is willing to place on information compliance in order to create alignment between teams, rather than having lines of reporting and control aimed at placing a single point of approval.

In this sense, process control tools managed horizontally and subject to periodic review reinforce the effectiveness of adaptive practices, emphasizing the possibilities of contribution and shared ownership, allowing the assumptions on which these tools are based to be cyclically retested.

In other words, the final result also depends on how widespread awareness is, given that ALL stakeholders enable the work of the individual and every chosen tool is never neutral.

However, the effort to make sure that a requirement is of sufficient quality is directly related to the level of formality chosen. To avoid having compliance systems that are too complex to maintain, it is essential to balance convenience and effectiveness, building on the organization’s own tools and mindset.

Babok Recommendations for Quality Solution Requirements

Three Knowledge Areas of the Babok v3 offer us support in structuring the underlying logic of these tools:

1. Business Analysis Planning and Monitoring: area that describes the activities to organize and coordinate the effort of Business Analysts and stakeholders;
2. Requirements Analysis and Design Definition: area that describes the activities aimed at modeling and specifying requirements and designs, as well as at validating and verifying the information useful for satisfying organizational needs by comparing possible solutions;
3. Requirements Life Cycle Management: area that describes the management and maintenance activities of requirements and designs, from creation to retirement.
   By collecting the suggestions and guidelines indicated in the guide, we can identify various aspects on the basis of which to evaluate the goodness of a requirement. The evaluation of these aspects can then be condensed into a checklist aimed at ensuring quality and alignment between stakeholders.

In a more general way, specifically when verifying the requirements, the Babok v3 (English version) indicates as quality requirements that are:

• Atomic
• Complete
• Consistent
• Concise
• Feasible
• Unambiguous
• Testable
• Proritized
• Understandable

These characteristics concern all types of requirements, but with regard to Solution Requirements and their qualities in the Agile environment, the practice of adopting the point of view of the end user or the beneficiary of the chosen solution is very widespread. The acronym INVEST allows the combination between User Stories, activities and requirements.

• Independent
• Negotiable
• Vertical
• Estimable
• Small
• Testable

As can be seen, there is a relative overlap between the general quality criteria recommended by Babok v3 and the best practices spread in the Agile field. Among these criteria, the following list of attributes could be a good starting point that summarizes the quality aspects also used by adaptive approaches to Solution Requirements:

• Clarity
• Traceability
• Completeness
• Maintainability
• Testability

Clarity

Clarity can be defined as the absence of ambiguity, i.e. the restriction of the conceptual field to a few variables. It is a characteristic associated with concepts endowed as much as possible with semantic autonomy and independence, and therefore devoid of unnecessary information, concise, targeted and restricted.

First, to improve the clarity of the requirement and reduce interpretation alternatives, it is important that the sentences are grammatically correct and free from typos.

Another indication is to prefer positive structures in sentences, as opposed to negative ones (i.e., “MUST” rather than “MUST NOT”). In this way, the whole to which a concept belongs is specified, rather than referring to what is extraneous to it.

The use of bullet lists makes it easier to combine these characteristics with the need in the Agile environment to express oneself according to acceptance criteria. Again, we can satisfy the atomicity aspect indicated by the Babok by calibrating the size of each dot.

Traceability

Traceability focuses on exposing clear visibility of information attainable through categorization, functional decomposition and attribution of metadata, such as status, as well as potentially the tracking of related activities or items.

Status

Tracing a requirement means exposing its origin and impacts. Choosing to place different requirements in a single document, one way to express the Status could be the use of four available options:

• IN PROGRESS: the analysis, drafting and negotiation of the information are still in progress
• APPROVAL PENDING: The requirements in the document have been modeled and have the required level of quality for approval by key stakeholders
• APPROVED: this status (not eternal) indicates that the indicated stakeholders have approved the information present and the requirements have a sufficient level to be taken over
• DEPRECATED: The requirement has been indicated as no longer in line with the Scope of the solution/initiative

For each of these values, it is useful to trace the last date of change of status, also indicating the stakeholders involved and any additional reasons.

Activities

For each requirement collected through a bullet list, it should be possible to associate the activities required for its fulfillment.

In an Agile environment, tools like the Product Backlog make it easy to keep track of the remaining tasks. To maximize the traceability of pre-negotiated and then accepted requirements and designs, it is useful to associate individual atomic points with the related activities aimed at completing an increase in value.

Each feature of a design should have a set of activities made explicit in the analysis phase. By using a Product Backlog for the association of activities and Solution Requirements, it is therefore also possible to have a flexible and transparent way of re-prioritising needs.

Completeness

Completeness is linked to the properties identified by semiology as “extension” and “intension“.

The extension of a statement is its truth value referred to all possible concepts. Intension is the set of specific information that determines what the expression refers to. It follows that the greater the extension, the lower the intension.

For example, quadrupeds are a large class characterized by being animals with four legs. Cats are a subclass of quadrupeds and have a greater number of specific properties.

In other words, are we interested in knowing more about the relationships that a concept has with the class of concepts to which it belongs? Or are we interested in getting more specific about the specific properties and attributes of that concept?

In the software field, where technological systems are the main focus, among the possible completeness aspects we can identify:

• assumptions (expected benefits from implementation and references to current strategy)
• end users (from an organizational and business point of view)
• availability (application roles impacted, data availability)
  behavior (information architecture/UX and functional logic)
  non-functional requirements (aspects relating to quality of service, performance, usability)
• dependencies (both logical-functional and at data model level)
• technical interfaces (related to technical constraints, such as DTOs, signatures, methods, protocols)

To be resolved

In both cases, it is important to identify blind spots and make them clearly visible through the use of tools such as TBR (To Be Resolved). The aim is to capture the uncertainty and risk deriving from an unknown quantity in order to be able to track and resolve it in the ways that best suit the approach used by the organization.

Resolution methods could involve gathering additional requirements from specific stakeholders, as well as testing specific assumptions in uncertain environments.

The TBR can be seen as belonging to the more general category of Item Tracking tools, as described by the Babok v3, also designed to derive metrics beneficial to the transparency of the initiative.

Whatever the path chosen, it is good not to leave the points incomplete without indicating stakeholders and moments dedicated to the resolution. In case this occurs, it would be good and right to investigate the strategy aspects related to the actual business needs, consequently understanding the impacts on the other types of requirements.

Maintainability

Reuse

One of the key aspects that determines the quality of a requirement is the ease of its reuse, intrinsically linked to the ease of ascertaining its correctness over time. For this reason, implementing maintainability helps in recognizing limitations in the implemented solution in advance. For information purposes, the Babok v3 identifies various types of candidate requirements for reuse, such as legal requirements, contracts, quality standards, SLAs, business rules or processes, features, interfaces.

Using a shared taxonomy for the initiative (or better yet at the organization level) facilitates the maintenance (as well as traceability) of existing requirements.

Again, the size of the single requirement is important to narrow the specificity of the specification to a single solution. Focusing on atomicity and logical-conceptual independence favors the readaptability of information.

Testability

Testability refers to the restriction of the application field of a requirement within the logic of true/false. A testable requirement can be subjected to experimental testing, i.e. it is made up of formally demonstrable assumptions on the basis of empirical verification.

In the general context of Babok v3, testability does not only concern the quality and conformity of the implemented solution, but also the assumptions are testable (for example in the context of a market exploration activity).

However, within the scope of the Solution Requirements, testability is guaranteed all the more as unverifiable qualitative terms are avoided (flexible, easy, sufficient, safe, ad hoc, adequate, user-friendly, usable, “if necessary”, appropriate, fast, portable, light, small, large, and so on). As you can see, these terms may be suitable in earlier stages to contextualize a business requirement or related to stakeholders, but lack in terms of verifiability.

In this sense, the validation criteria of a Solution Requirement (functional or non-functional) must be measurable according to quantifiable parameters (for example, in terms of truth/falsehood, occurrences, seconds, bandwidth, etc.).

It follows that for effective testing, the preconditions must be clear.

A Checklist for Quality Solution Reuirements

As we have seen, the quality of the Solution Requirements can be evaluated under several aspects. For each of these aspects we have highlighted some characteristics that we try to collect in the following checklist, a fast and flexible tool.

Traceability
1. Requirements are easily identified with unique codes

2. Status present and updated

3. The requirements achieve the desired percentage of associated implementation act ivities
Clarity
1. The requirements are written by bullet list
2. Each sentence is free from grammatical and punctuation errors
3. Each requirement is written in an active and positive form
Completeness
1. Incomplete requirements are tracked using the TBR scheme
2. All aspects of a requirement have been filled. Otherwise, a TBR is used.
Maintainability
1. Only terms decided at the initiative taxonomy level are used
Testability
1.Each requirement is free from unverifiable terms
2. Each requirement is expressed according to quantifiable parameters
3. he preconditions for testing have been defined

Conclusions

The Babok v3 is an incredible resource for any Business Analyst and is packed with tips for effectively adapting industry practices. Drawing inspiration from and combining practices of adaptive frameworks, we have shown how it is possible to identify basic characteristics to build a common point of reference regarding the quality of the Solution Requirements.

It goes without saying that what is shown is the result of a particular organizational reality and what is really important is to abstract the logic of identification of the characteristics linked to the requirement. In fact, if the criteria according to which I have gone to define the quality of a requirement could be different in another organization, what remains the same is the practice of breaking down these concepts and exploring their scope in terms of verification in the field of quality.

In my opinion, collaborative practices in the definition of these taxonomies are at the center, practices designed to bring alignment between stakeholders, redefine priorities and ensure organizational buy-in.

My call is therefore to look for cohesion beyond local interests in corporate politics!