Fred Brooks realised this and wrote the following:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements.”

(Frederick P. Brooks)

The question that comes to mind is why is integrating business requirements into software design such a difficult thing to accomplish.

To answer this question there are various aspects that one needs to consider such as:

1. The type of business and operating environment,
2. The knowledge of the software team and their understanding of the business domain,
3. The tacit domain knowledge residing within the business itself, which is not always easy to articulate or describe,
4. The problem that needs to be solved within technical terms.

Figure 1 provides an illustration of the two sides that need to integrate in an effective manner to ensure that the design implemented within a software solution is in fact the best possible option.

One thing to note is that no solution is perfect and during the iterative process of requirements gathering it could be discovered that a specific area not explored before or highlighted contains a deep critical success factor, which can directly impact the overall design of the software being developed.  To mitigate this risk a modular approach is followed during software design.

The Modular Approach

To ensure software stays flexible and changes within the operating environment can be absorbed by the system, many software solutions especially enterprise-wide follow a modular approach.

This modular solutions model enables a problem to be broken up into smaller sections/components and each of those sections is then explored to determine if that section within the overall modular design is capable of solving a specific business requirement.

By following this approach one already provides longevity within a software system because software is an ever-evolving process because business environments change and so do the demands on a software solution. Maintenance within software and changes can be an ongoing process and should a system not be flexible enough it leads to a system not being able to adapt to changes fast enough or a failed software solution requiring a rewrite. This point is not always easy to identify, but when considering the cost of continual changes within a system against a complete rewrite and the latter is more cost-effective, that is usually the tipping point.

Requirement Elicitation Methodologies

Software engineering and design methodologies have evolved over the years and various processes and tools have been developed and used to support the integration process of business requirements into software design and solutions. Methods include UML (unified modelling language) tools, JAD (Joint Application Design) and RAD (rapid application development) to mention a few.

“Unified Modeling Language (UML) is a standardized modelling language enabling developers to specify, visualize, construct and document artifacts of a software system.”

UML diagrams have two core focus areas namely: structural and behavioural.

“Structure diagrams are used in documenting the architecture of software systems and are involved in the system being modelled. Behavior diagrams represent functionality of software system and emphasize on what must happen in the system being modeled.”

https://www.techopedia.com/definition/3243/unified-modeling-language-uml

The use of UML provides an overall as well as an in-depth view of the software and supports the design process very well. It also enables the solution to highlight potential gaps or processes not defined yet, requiring further analysis to gather those requirements the business needs. By following this approach a software solution is already designed with a modular mindset, already providing the foundation for programmers that need to develop the solution required.

UML do need client engagement and JAD sessions are a process which supports requirements gathering quite well.

“JAD (Joint Application Development) is a methodology that involves the client or end user in the design and development of an application, through a succession of collaborative workshops called JAD sessions.”

This process provides continual client interaction and supports the development process quite well, especially when specific business requirements need to be understood by the technical side. The process helps to identify critical success factors during the software development life cycle, where difficult business concepts are not always easy to articulate. This can take place where very specialised software needs to be developed for a specific environment, e.g. business analytical software using deep analytical and statistical models for predictions used within a financial institution.

During these JAD sessions, difficult concepts would then be explained and examples used to provide the technical team with a foundation to work from. One area that can either enhance or hamper the design in such a situation is the business domain understanding of the technical team. The reason why this can become a problem is that if a client provides business requirements and deep tacit knowledge explanations to inform and educate the technical team and some information is not articulated or not explained in detail, certain assumptions can be made about what the software should be doing.

This will then directly impact the design of the software and its functionality. If a modular design is followed and a critical success factor does come to light, e.g. such as a specific calculation required to be incorporated under certain conditions, then a module or modules affected by such a discovery should be updated without the need to affect the entire system.

A risk within such domains is that if the technical team does not understand the underlying risks well where the solution will be operating in, it runs the risk of a solution being built not taking external factors into account that could change the overall solution being designed and developed. It is vital that technical teams know how the business functions to make sure that the requirements gathered are considered and impact the overall design in the correct and most flexible modular manner possible. This approach mitigates the risk of discovering a hidden domain factor too late in the software development process resulting in a system-wide impact not planned for.

In some cases, rapid application development is used to build a small-scale solution and determine if a specific problem can be solved, before investing too much time and effort into a project that contains high-risk factors.

Rapid application development (prototype) is used to build a mock-up (show and tell solution) to explore if a certain problem can be solved at a high level and if so, what is the expected outcomes envisaged. This already provides a baseline and strategy being explored to ensure that business requirements are not overlooked and infiltrate the software design process as best as possible.

“Rapid Application Development (RAD) is an adaptive software development approach where a software prototype is rapidly updated based on user feedback and iteratively delivered until it meets all client requirements.”

In many cases, these tools do help to elicit and open the core of business requirements not mentioned during discussions or normal documentation requirement description processes but software development still has many challenges leading to budget and time overruns, due to the nature of the iterative processes involved during the software development lifecycle.

The methods described are not exhaustive, and others also exist each with its positives and negatives. Overall there is no one size fits all and projects do differ as well as clients and business environments.

One thing remains and that is to integrate business requirements into software design is not an easy task, which is why software projects today with all the methodologies and tools available, still experience challenges. If these challenges are not correctly addressed in a timely manner, projects have an increased risk of failure.

“The Standish Group’s 2020 CHAOS report estimates that around 66% of software projects fail.”