Why there is no functional requirements analysis technique in BABoK?

Functional requirements analysis technique in BABoK

This was a very interesting question posed by one of our workshop participants.

She asked “LN., there is a technique for non-functional requirements analysis in BABoK but there isn't any technique for functional requirements analysis. Why is it so?”

It made me think. As business analysts, we probably spend more than 90% of our time in conducting functional requirements analysis than non-functional requirements analysis. Non-functional requirements analysis is very useful when you are architecting a new product. Once the product is architected, our focus would usually shift to functional requirements analysis.

I said, if there is nonfunctional requirements analysis technique, there must exist a technique for functional requirements analysis.

I decided that let me build a functional requirements analysis technique in a similar way to non-functional requirements analysis for functional requirements analysis.

My suggested categories for functional requirements analysis are

1. Data
2. Activity / flow
3. Status
4. User interface
5. System interfaces
6. Rules
7. Roles and permissions
8. Autonomous processes

I am describing all these categories in a brief and typically what techniques we can use to elicit this kind of functional requirements.

1. Data perspective

Majority of software applications hold data. In the data perspective, we discover data to be stored in the application. Data to be stored can be obtained from analyzing current reports and information needed to make decisions.  Typically we would be using models related to information structure of the application which could be Entity relationship diagram or Class diagram.

2. Activity / Flow perspective

Most applications automate business processes that we see in businesses. All business processes have a flow associated with them. When we look at activity perspective, we are essentially trying to describe how Information flows between various users and systems. Typically we would be using activity diagram or process flow to indicate such kind of requirements.

3. Status perspective

Applications deal with certain entities, such as customer, employee, order and all these entities move through various statuses, such as starting from being created and finally made in-active or obsolete. In between, they may have many intermediate statuses. The status perspective is usually indicated by a state diagram. When we model status perspective, we need to understand when and how an entity status will be changed.

4. User Interfaces perspective

User interface perspective is quite interesting because almost all applications would have many user interfaces for different kind of roles. We need to understand how do we make the user interface simple and interesting for the stakeholders.  Mostly we will be using some kind of a prototyping approach to indicate user interfaces for the application.

5. Rules perspective

Applications implement rules as one of the main reasons for automating processes is to ensure that the organization and end user follows the right rules when they transact.  Rules can be captured using rules catalog which would give them the perspective of why the rule was developed what processes get affected by the role. We can use flowcharts, decision tables to indicate behavior associated with rules.

6. Roles and permissions perspective

Most applications have multiple roles and each role has different privileges with the application. So as business analysts, we must understand what are the roles that the application is expected to support and the kind of privileges the role would enjoy in the application. Typically we use Roles Permissions Matrix to capture the requirements with respect to roles and permissions.

7. System interfaces / Integration perspective

Majority of applications are not an island and they interact with other applications for completing the functionalities by receiving information or sharing information with other applications. As functional business analysts, we also should understand how these interfaces work what kind of data transfer happens between these interfaces. An interface analysis template could be a great approach to capture such requirements.

8. Autonomous processes perspective

Systems are expected to perform a variety of activities without any user intervention. As functional business analysts, we also need to understand if there are such processes which need to be executed at some point in time in the application. Using a batch process definition template could be helpful for this purpose.

This technique is work in progress and not meant to be perfect and can definitely be improved.

I would encourage my BA friends to contribute to this list so that we can make it an exhaustive list. A good functional requirements analysis technique will be quite helpful for all BAs.