Business analysis, preliminary analysis and detailed analysis - how are they different?
You are dealing with a business process in a company and come to the conclusion that instead of doing everything manually, the process should take place in the information system. The idea is good, but how do you describe what you expect from the information system?
After some googling, you will come to the understanding that you need a requirements specification, i.e. a document that contains system and user requirements. This rather common approach tends to be too general in practice and does not give a clear answer to what you really need.
In software development, the analysis process accompanies the development work from start to finish, and its methodology differs significantly from that used in the construction industry, for example. In construction, a clear line can be drawn where the design ends and the construction work begins.
There is no such luxury in software development - the design of a solution usually lasts throughout the development process. It is important to understand that at different stages, the analysis is carried out at different levels of detail.
At Trinidad Wiseman, we offer you support throughout the entire analysis process – business analysis to assess the value of the idea, pre-analysis to formulate user requirements, and detailed analysis to provide clear input to developers.
Read more on our analysis service page, get acquainted with completed projects and contact us.
No software specification can be infinitely detailed
About 8 years ago, there was a fairly common understanding among customers in analysis projects that once the analysis is carried out, all the requirements are written, they do not need to be changed, and development can be started without further discussion, investigation or questions – in other words, without further analysis.
In fact, no specification or description of requirements can answer all the developer's questions, because the amount of work required to prepare such a document would be comparable to the completion of the entire software.
Since it is not possible to create an ideal, comprehensive user requirements document, it is necessary to find the right level of detail for the project – a balance that allows you to start the development while maintaining flexibility.
NB! In the context of systems analysis, the terms "preliminary analysis" and "detailed analysis" are often confusing, as they are general and their meaning varies from one client to another. We have seen situations where one client orders a preliminary analysis, but expects a very high level of detail as a result – even more so than another client who thinks they are ordering a detailed analysis.
We have also received projects for which it has been claimed that a detailed analysis has been carried out, but the complexity of half of the application was hidden behind one extraneous sentence.
The following is a description of the different levels of analysis granularity:
- Business Analysis
- Pre-analysis or user requirements analysis
- Detailed analysis.
Business analysis, or business requirements analysis (vision level), focuses on formulating business needs and starts with setting up a problem. It is analysed why the development is needed now, what is the purpose and scope of the desired system. For example, the business side may see that the company's volumes are growing: "there are currently 50,000 invoices per month, in a year it will be 100,000, but the existing system is already slow."
Business analysis can help identify what changes are needed and what their impact will be. This does not always have to lead to the development of the system – sometimes it may turn out that a more efficient solution is to reorganise the business process or remove unnecessary activities. Business analysis can also be used to evaluate ready-made solutions to find out which solution best suits the company's business processes.
Business analysis in the context of software development is aimed at the owners of the system – the people who decide whether to invest in the development of the system. The description of the proposed solution must be clear enough to understand the potential business benefits and at the same time assess the approximate cost of the development (for example: whether it is in the range of 50,000, 100,000 or 300,000 euros). Typically, business analysis focuses on the business area, business processes, and problems to be solved.
Once the business analysis has been completed and the costs and benefits have been mapped, the client can make the first and very important decision: whether to move forward with the project immediately, postpone it temporarily or abandon it altogether.
Pre-analysis, or user requirements analysis, focuses on what the system should be like from the user's point of view. Its purpose is to describe the behavior of the system in more detail than in a business analysis. The business process is analysed and use cases or user stories are reached.
In parallel, work will also begin on the prototype of the interactive user interface. The prototype helps the user to best understand what the system will look like for the end user and how it will work.
The preliminary analysis is aimed at the future end users of the system – the people who will actually use the system. As a result of the analysis of user requirements, they can say: "yes, such software would be useful to us" or "this is the solution we are looking for."
The preliminary analysis also defines the primary non-functional requirements of the system – the technical limitations or conditions that the system must meet. These include, for example, interfaces, security, ease of use and other similar aspects.
In addition, this may also include requirements related to the development process, such as how testing and system handover should take place. However, these can often be agreed upon in more detail with a specific developer, taking into account their usual work practices.
As a result of the preliminary analysis, the cost of the development can be estimated much more accurately. While the estimate made based on a business analysis can differ up to two times from the actual cost, in the case of a preliminary analysis, the possible error is usually between 20% and 50%.
Detailed analysis focuses on aspects of system behavior that may not be of primary importance from the end user's point of view, but are essential for the implementation and management of the software. Detailed analysis documents are highly technical and their main target group is developers.
The detailed system requirements document must contain all the special situations that the developer must take into account. For example: what are the database tables and their interrelationships, how are authentication and login solved, what data communication protocols are used, how the system is documented, and what technological solutions need to be implemented. In addition, the interfaces between the front-end and the back-end and the exact behavior of each UI element are described.
It is often expedient to prepare a detailed analysis in parallel with the development work, as it also reflects the working style of the specific team and the choices that emerge during development. For example, we have seen projects where the exact description of the interfaces is left to the developers, and the analysts only describe the part that only includes the description of commercially important data exchange. On the other hand, there have been projects where all the details have to be documented in advance in the analysis.
It is not reasonable to prepare a detailed analysis long in advance, as business needs may change over time and the requirements of the system may also change. Therefore, a flexible detailed analysis that is updated during development is often more effective than technical documentation that is locked in too early.
Quality criteria for the analysis
Consensual – the results of the analysis have been discussed several times and all parties are convinced that this is the system they want. As changes in information systems usually affect several people from different fields, it must be ensured that all parties have a common understanding of the proposed solution. By the end of the analysis process, it must be clear that this is a system that is useful for the organization.
Understandable – the document must be formatted and worded in such a way that the business user understands its content without too much effort. In the case of voluminous documentation, a clear structure is especially important: move from a general level to a more detailed one, use precisely referenced subsections, and explain all professional terms. When compiling user requirements, it is always worth assessing whether both the future user of the software and the developer understand the use of words in the same way.
For example, UML diagrams can be used in preliminary analysis, but often the readers of the documentation do not understand them. In this case, confusion arises and the document does not serve its purpose. Therefore, we recommend that you prefer a simple and as understandable way of marking as possible.
Non-contradictory – the documentation must not contradict itself or contain conflicting information between different documents. Such errors often occur when several people are working on a project at the same time. The result can be a situation where data moves into the system, but there is no place to store it – simply because the requirements did not define this part or were described in a contradictory way.
Comprehensive – the analysis must cover the entire scope of the solution. It is often a mistake to focus on an interesting problem, but after assessing the development volumes and starting work, it becomes apparent that important parts have been left out of the analysis altogether. The most important thing here is not the level of detail, but that the solution is essentially complete and all the necessary components are thought through.
Independent – in the case of business analysis and preliminary analysis, the analysis should remain independent of the technological solution. This is important so as not to unduly influence or limit the subsequent choice of technology. As a rule, we avoid situations in our work where a specific technical solution is preferred in the requirements at an early stage. However, if a technological restriction is identified in the user requirements, there must be a clear and well-justified need for it.
Testable and verifiable – detailed requirements must be unambiguous and objectively verifiable. The needs formulated because of a business analysis are often more general and do not allow for accurate testing, as they provide guidance rather than specific criteria.
The clarity of details has a direct impact on the final quality of the system. Therefore, the user requirements must be described in sufficient detail so that their fulfilment can be unambiguously assessed during testing. For example, "the system must be fast" is not a testable requirement, but "the operation must take place within three seconds" already is.
A similar problem occurs with the requirements of ease of use. The expression "the system must be convenient" does not say anything in itself. When we create a user interface prototype, our task is to describe exactly what "convenient" means in a given context. It often depends on small but important details – for example, whether the system sets the appropriate values by default or whether a professional user can quickly access the information and get the actions done.
What next?
If you are a client of a software project, it is worth first thinking about the phase of your idea and how clear your own vision of the planned solution is. For example, have you already done a business analysis in your mind – perhaps you have come to the understanding that you want to invest in your idea?
Or have you already written down your best understanding of the system's functions and main business processes and feel like going into more detail now?
Business analysis is a phase where you need a partner to help assess the viability of the idea. Pre-analysis is the moment when you need someone to help you write down your thoughts in a systematic and unambiguous way. Detailed analysis is the stage where the system is thoroughly polished and a specific structure of tasks for developers is established.
In the end, the most important thing for moving forward is that the key persons of the software client have a clear and common vision of the solution to be created.
