Business process and requirements analysis

Posted in process-engineering with tags business-analysis process requirements modelling - Wednesday, August 1, 2018

Software that is fit for purpose is paramount to the business' objectives. Sometimes the requirements are obvious and clear, but very often while the high-level intent of a new development effort may be clear, the actual definitions of the requirements are left wanting.

By investing in deriving good requirements that can later be verified, and then communicating those requirements to the necessary parties, it becomes possible to streamline the software engineering efforts.

More explicitly, having unambiguous and well vetted requirements frees up the software engineering resources to focus on the technical tasks at hand. This is far preferable to using the process of software development as the primary means for teasing out an understanding of the requirements that are aligned with the business needs.

Therefore, the first phase I engage on for a new project, is to start with helping business stakeholders analyse their context and goals. Once the problem space is understood and well defined, sufficiently clear requirements can be documented. These will be used to support the subsequent phases of software engineering in the project.

As highlighted below, it is important to match the problem space with the level of detail in, and method of capturing, the requirements. With this it is possible to leverage the software engineering skills effectively to produce useful and relevant systems.

more...

Communication and Validation

Good requirements can be identified because they succeed in communicating the intent to the relevant stakeholders.

However, it is important to realise that this in turn means that relevant parties need to be able to independently evaluate whether or not the requirements have in fact been sufficiently communicated — that is, can the results be validated?

Additionally, it is important to realise that the stakeholders, by definition, can include the full range of disciplines in the software engineering effort. That is, they would include business owners, architects, software engineers, process engineers, testers etc.

As such, requirements enable us to close the loop between various parties and the efforts involved:

business owners should be able to review the requirements and evaluate the definitions to ensure that any implementation will in fact solve a business objective.
software engineers need to be able to review the requirements and be confident that they can create a software system that embodies the automation required to support the requirements.
testers need to be able to review the requirements and be sure that they can evaluate the outcome and demonstrate adherence to the requirements.
etc.

However, one quickly realises that requirements analysis and gathering can be an in depth, and potentially lengthy, exercise.

When working on projects and with software engineering teams, I will guide them towards “pipelining” the requirements gathering process and using suitable representations depending on the audience.

In this way it often becomes appropriate to have a progressive increase in the fidelity of the requirements:

stories - written to capture the main players that will interact with the system and to highlight broad aspects regarding the dynamics of the system. These are often usefully supported by some structural diagrams.
design documents - written with more detail and a greater focus on enumerating “business rules.”
process models - coded forms that define, in more precise terms, the data flows between and across core subsystems.
system models - coded forms that dig into the details of how the moving parts of the final system will interact.

The important point is to see that this forms a cascade of increasing detail in the representation of the requirements. At each stage the requirements themselves can be evaluated and refined, before expending the effort on the next level of detail.

Additionally, this process of incremental analysis of the problem space can work in both directions. For example, if certain interactions are not apparent at the level of a story, it is perfectly reasonable if this comes to light later on, and is then pushed back up into the higher level documents. This, in fact, becomes a valuable way for ensuring continued alignment between the work carried out in the project and the ongoing, and potentially changing, needs of the business.

It should also be apparent that not all problems will benefit from the same level of detail in the requirements gathering and communication process. If a few sentences are enough for everyone to work together then there is no need for the additional detail.

Therefore, by casting analysis and requirements gathering as a communication and validation problem, we can look for opportunities to short-circuit the process.

We keep ongoing communication flowing while delivering early, and evaluating the outcomes of our experiments. In this way, the focus is on delivering software systems that are aligned with the business needs.