Modelling Requirements in Business Analysis

Modelling Requirements in Business Analysis

Business analysis is a multifaceted discipline that is pivotal in the structured software development process. To simplify, we can define analytical activities as encompassing information (requirement) acquisition, development, and management. These requirements are gathered through a variety of techniques involving diverse stakeholders. Consequently, the outcome of the analyst’s efforts materialises in the form of documentation. This documentation systematically organises the identified user needs (problems) comprehensively, translating them into precise descriptions of different requirement types and corresponding solutions to fulfil those needs.

Properly defining project requirements is essential to develop a product that effectively solves previously indicated business issues. The list can become extensive, but the implementation team uses it to create specific product features. Gathered requirements cover not only general (as often perceived by the client) aspects but also many other areas, like system integrations and security concerns.

Each requirement adds complexity to the project, increasing the extent of functional documentation, and the more extensive the documentation is, the harder it is to make it readable and accessible to different stakeholder groups. Considering their perspective is crucial because they are the recipients of the documentation and influence all of the pivotal choices regarding the final product. Therefore, the materials provided to stakeholders must meet recognised standards and be easily understandable.

The fundamental approach to address the aforementioned challenges involves employing a language both accessible, through simplification, and universally comprehensible for all participants in the multi-stage software development process known as the SDLC (System Development Life Cycle). Nonetheless, it is important to emphasise that the aspects discussed in the subsequent section extend beyond IT projects. In this context, we consider software development the primary and most frequently utilised frame of reference.

It is the modelling techniques that offer strong support in creating detailed and easily understandable documentation. They help business analysts (and other specialists) accurately represent processes and systems, all while maintaining documentation that’s clear and accessible to a wide audience.

Business processes and models

According to the widely accepted definition, a business process is a series of activities organised to achieve a specific outcome (e.g. information, good or service). The Object Management Group (OMG), a standardisation consortium, expands on this definition, labelling a business process as a sequence of activities performed to accomplish a distinct task. This expanded definition arose from the need to emphasise that a business process can encompass multiple activities but must adhere to a consistent approach. It is important to note that the OMG’s characterisation focuses on the execution of specific ‘work’ rather than the resulting product.

Analysing these processes thoroughly is essential to accurately recognise the needs (problems) of the various stakeholder groups and how they can be met (solved). Modelling the information (requirements) obtained in the course of classical analyses allows the results to be presented in a more accessible manner. In most cases, this speeds up the identification of possible conflicts simplifies finding improvements, and supports the overall optimisation of the desired solution.

But what exactly is a model?

In the broadest sense, a model is a simplified representation of reality. In a standardised graphical format, it illustrates the steps necessary to fulfil a process defined by previously acquired requirements. It is important to highlight that modelling need not be confined solely to standard processes; it can also depict specific characteristics, principles, or operational conditions of an object, phenomenon, or, in the most general terms, a system.

Notation standards

Models, much like other methods of representing acquired requirements, serve as tools that facilitate communication. Successful information exchange relies on all parties involved speaking the same language and comprehending the notation. The introduction of additional symbols, arrows, or other annotations might lead to difficulties where individuals interpreting diagrams crafted in such a manner struggle to grasp the conveyed information’s significance. More significantly, it could result in misunderstanding and the incorrect implementation of that information. To avoid such challenges, it is recommended to utilise standardised modelling languages and adhere to formal guidelines for their composition.

Various structured techniques exist for documenting business processes, known as notations. Among these, the most widely recognised are BPMN, EPC, and BPEL. Notably, BPMN (Business Process Model and Notation) holds prominence, prevalent not only within the IT industry but also beyond. The current iteration of this standard is BPMN 2.0.

On the contrary, EPC (Event-driven Process Chain) finds its primary utility in modelling higher-level business processes. This technique is integral to the ARIS (Architecture of Integrated Information Systems) methodology and has a significantly longer history than BPMN. In essence, EPC is primarily directed at the conventional ‘business’ context, while BPMN, due to its more formal character, is currently favoured for ‘IT’ systems.

The final language in this trio, BPEL (Business Process Execution Language), operates as an XML (Extensible Markup Language) based language. Its acronym reflects its core purpose: describing executable business processes exclusively. Processes conveyed in this language solely exchange information via web service interfaces. OASIS (Organization for the Advancement of Structured Information Standards) consortium has standardised this notation.

Besides modelling languages designed for typical business processes, there are various notations used for slightly different purposes. A classic and nearly as prevalent as the BPMN is the Unified Modelling Language (UML). It serves as a semi-formal language employed in the definition, visualisation, and development of various software-related systems. Yet, its scope extends far beyond this; it is used for purposes as diverse as illustrating organisational structures and modelling processes. In the latter context, however, BPMN is typically more favoured. This preference arises from its newer historical origins and specific design for visualising conventional processes.

In reality, the most common standards are BPMN and UML, supported by almost all the modelling tools available on the market. However, the topic of tools itself is broad. The right choice should be based on the analyst’s preferences or the patterns adopted within a project team. It is worth noting that you do not always need to purchase expensive and extensive modelling software like Enterprise Architect. There are various free tools available, such as draw.io, that can assist you in creating precise and valuable diagrams.

Working with models

Replacing conventional language explanations with diagrams offers various additional advantages. The primary benefits of enhancing the classic descriptive documentation approach with suitable models encompass:

  • Streamlined assessment of the behaviour of the actual process (or system) through analysis of its model and the scenarios clearly outlined within it.
  • Identifying absent components within the process and providing an easy way to add or extend them.
  • Concealing extraneous intricacies inherent in a real and extensive process (or system) during a particular analysis.
  • Tailoring the level of abstraction to the intended audience achieved by emphasising the key elements for easier comprehension of the analysed subject.

Software development is a time-intensive process that involves various individuals. The final diagram should be customised to suit the capabilities and needs of each stakeholder group. This means it is crucial to carefully consider the complexity of the documentation and choose the right level of detail. An example of a poor approach would be to display a complex implementation model (at a low level of abstraction) to a group of typical users, such as CMS editors. This level of detail may not only be confusing but also unnecessarily waste valuable time and resources.

Building on this, one of the most noteworthy advantages of using models is their ability to slowly refine the details, especially when working with vague requirements or those that are not clear enough from the beginning. By presenting these issues in a diagram and discussing the model together, both within our team and with the client, we can make gradual adjustments and improve weak points. This iterative approach to verifying and adjusting requirements is significantly faster and more cost-effective than making direct changes to the code during the development process.

Summary

The purpose of a model is to simplify the identified problem, whether a process or a system, by excluding details unnecessary for a specific context. When creating a model, it is crucial to consider what problem it aims to solve and for whom. These two factors are pivotal, as they influence numerous subsequent decisions, including the selection of a suitable language (notation) and determining the right level of detail.

While developing models as part of business analysis isn’t obligatory, it provides several advantages. It can notably enhance the documentation’s quality and readability (accessibility). This improvement applies to documents created during the initial analysis phase to validate the basic assumptions provided by the client, as well as during subsequent stages to verify the already structured and initially modelled data.

The time invested in meticulously creating compliant diagrams should be viewed as an investment with potential returns on multiple fronts. As the implementation process progresses, modelling helps validate the customer’s core needs and specify the requirements, which culminates in the final project delivery and transitions into the maintenance and development phase.

Sources

Contact Us

28 August 2023
Business Analysis
avatar of paweł drągowski

Paweł Drągowski

Business Analyst at Infinity Group

Previous Post
Next Post