Functional Analysis – Navigating to the goal

After diving into the basics on this subject, which you can check here, how about navigating into the day-to-day life with a little more expertise through this sea of digital transformations? Like the skilled sailors on the expeditions to the new world, equipped with maps and sextants, an analyst must also have at his/her disposal several tools and practices to orient himself/herself in the search for answers, in his/her role as a driver of change. That is what I propose to do with this article.

Much of the work of a functional analyst takes place around requirements, their identification, their classification, and consequent presentation to the different stakeholders of the team or project.

But what is a requirement after all?

It is a condition to be fulfilled in order to achieve a certain objective. If we think about it, this concept is not exclusive to in digital developments, it is also commonly used to evaluate success in areas such as medicine, or even legislation and law. There may be requirements of different types. I will refer only to functional requirements and non-functional requirements, in a simple way. Functional are those that detail what a system / application / initiative should be able to do. Non-functional are those that detail quality characteristics of the system / application / initiative, aspects such as performance, usability, or reliability.

In general, and, focusing on IT, we can say that a requirement is meant to describe and clarify the needs of one or more users in the project. According to the objectives previously defined. However, a requirement does not always imply the development or coding of a new functionality in systems or applications. For example: if the objective of the project is to ensure that cashiers reduce customer service time. A requirement may well be, to design / identify a training plan for these cashiers, thus reinforcing their knowledge of the system and its handling. In this case, there is no need to develop a new tool. Therefore, it is up to the analyst to identify these alternatives and present them to the project stakeholders responsible for making the decision. A good requirement should be S.M.A.R.T. (Specific, Measurable, Attainable, Realistic, Timely).

Some Examples of key work tools:

There are currently numerous practices and tools that can be useful, both for surveying requirements from different stakeholders, as well as, for their analysis. So, I will leave you with just a few examples available. Just to mention that none is perfect, each one will always have its strengths and weaknesses, maybe I will be able to go into more detail on that later on.

• SWOT Analysis (S- Strength, W- Weakness, O- Opportunities, T- Threats)

It allows analyzing the information collected in 4 quadrants or categories. It is a technique that can be used in several phases of a project. Often, in an initial project phase: internal factors are considered strengths or weaknesses, whereas external factors can be classified as opportunities or threats. But it doesn’t always have to be that way.

• Brainstorming

It is usually a group initiative and perhaps one of the best-known practices. It works by stimulating the creativity of the elements of the group. By interacting, the group seeks to generate ideas, find the source of problems, and propose solutions to them. It is often used in a more embryonic phase of the projects and can serve to feed more complex techniques or simply to identify requirements and / or features.

• User Stories

This is a current practice and used mostly in Agile methodologies. Here, requirements are identified from the point of view of the end user, with the aim of building the best possible solution in the project. A clear advantage is the high efficiency of the analysis result, as it is very user focused. Briefly, they should follow the format: as (role) I can (ability), so that (receive benefit). From here, the capabilities and several functionalities necessary to achieve success in this project can be identified.

A simple example of a user story could be: ‘As a user of the system I want to ask the company for clarification so that my doubts are removed.’

• Business Process Modelling (BPM)

It is a technique for representing and modeling processes in sequential diagrams or flowcharts. Whether to simply map procedures or to allow a more in-depth analysis, looking for potential improvements. It is typically used in the analysis phase of a project to understand, study / illustrate, identify, and subsequently recommend changes, in order to achieve the pre-defined objectives. The best-known notation for building these maps / flows is UML (Unified Modeling Language), but there are others.

Much remains to be said on the subject, however, with this article I hope I was able to help you demystify a little more the functions and the role of a functional analyst in this ever-evolving world. In the future I will further address how everything can fit together, from one end to the other, in one of the many projects that populate our digital reality. Until then!