There is a question that often returns: How do we know which analysis techniques we need to apply? There are of course several considerations to be made.

You can for example consider the nature of the system or the composition of the team. One good place to start is to take a look at the stakeholders of your analysis. Whom are you making it for?

So let's look at some of the classic stakeholders:

You: the analyst!

A first stakeholder that is often forgotten is you. You don't just create a functional analysis for other people. You create it first and foremost for yourself. It can help you get from complete chaos to getting a grip and fully grasping the domain. It allows you to look at it from different angles and to come to a better solution.

Development

The technical team is the next main stakeholder. They need information to create a design, to know what needs to be implemented. Your functional analysis is a tool to transfer your knowledge. Beware: it is not a replacement for communication.

Testing

Your analysis will often be input for testing. In case you're not testing yourself, you need to make sure you can provide the information that is needed.

Maintenance

A system doesn't stop to exist at the end of the project. The people working on the product after you will appreciate it if there is some documentation available. Don't wait to the end to create documentation or it will never happen.

Business

Can we consider business as stakeholders of our analysis?

• Most diagrams are not suitable to be shown to business users. As an analyst you will probably use other ways to communicate with business, e.g. examples, mock ups, workshop techniques, etc.
• In addition I don't believe in the concept of using a functional analysis as a contract between business and IT.

So in my opinion, functional analysis techniques are in general not useful in the collaboration with business.

Every organisation is different and this is obviously not an exclusive list. Depending on your organisation there will be other roles such as Business Analysts, Application Architects, Technical Architects, etc.

As with all stakeholders, you need to gather their requirements and take into account that these requirements can change over time, e.g. due to new insights or a changing context.

Please let me know what you think, whether you agree or not, which topics you find interesting, etc.!

Like this Blog?

Then you’re in for a treat! Visit Sarah Denayer’s personal blog, which offers many more hours of excellent reading material!