Structure, Cost Efficiency, and Speed: Why Your Project Needs an Analyst
Development of websites, apps, or portals is a group effort of an entire team of professionals. The work done by developers and designers is hard to miss, yet there is a team member whose contribution people tend to disregard as irrelevant even though it directly affects the result —namely, the analyst. Let's discuss why you need to bring them into your project, as well as the stages they go through in their work.
There are numerous categories of analysts who collect and analyze data to make judgments on how to improve a particular area of the project. We will focus on specialists who help companies understand what the business needs and assess whether it can achieve it — a business analyst.
Analytical Approaches
When working on a project, it's important to not only bring in an analyst but also to establish their approach to the work. The approach depends on the budget and time and determines when exactly the analyst gets involved in the project. We distinguish three approaches to project analytics.
Approach #1. Creating documentation before development
Developers begin their work with complete documentation. This approach yields the highest development speed and predictable results.
Pros:
● predictable development results;
● maximized development speed;
● predictable product launch time;
● minimized fixes and reworks;
● suitable for Waterfall project management.
Cons:
● difficult to make product changes during development;
● increases product launch time;
● product functionality may lose relevance while documentation is created;
● poor flexibility of product development;
● not suitable for Agile projects;
● significant disconnect between business and development teams.
Approach #2. Creating documentation in parallel to development
This approach is based on close collaboration between business and development sides. The analyst and the development team begin their work at the same time. All parties are actively involved in the creation of documentation, which allows them to adapt the product as necessary during development if a feature or solution is no longer relevant.
Pros:
● decreases product launch time;
● business and development sides work closely together;
● product can be adapted during development;
● suitable for Agile projects.
Cons:
● increases risk of significant reworks and revisions during product development;
● higher analyst workload at the start of the project as they try to outpace the development team;
● risk of missing significant top-level requirements;
● poor match for the Waterfall approach to project management;
● may create stressful situations for the team as not all of its members fully understand the project.
Approach #3. Combined approach
This is the most common approach. Business requirements and the general section of documentation are prepared before the start of development, while everything else is done during the development process. This approach provides you with a clear notion of the product from the business perspective, and allows you to adapt it during the development process.
Pros:
● clear notion of the product from the business perspective;
● decreases product launch time, although not as much as the previous approach;
● suitable for both Agile and Waterfall-managed projects;
● close collaboration between the business and the development side;
● moderate costs and moderate risk of fixes;
● balanced analyst workload.
Con:
● increases product launch time somewhat.
Stages of Analytics The number of analytics stages varies from project to project. We tend to distinguish four stages. The list of documents is not set in stone and may change depending on a project.
The list of documents prepared by our analyst for the Credit Broker project
Stage #1. Identifying business requirements
Business requirements represent the core list of documents defining what business needs are meant to be solved by the app under development. If we lose our direction at any point during development, we can reference these business requirements to get back on track. This stage involves the creation of the following documents.
| Document's name | Description |
|---|---|
| Vision document | The first one to be created. Fully and accurately yet concisely describes the concept and values of the project to the clients, and the look and feel of the project to the developers. Outlines the problems meant to be solved or the goals pursued by the product. By reviewing it, the analyst and the development team can understand exactly what the client wants and proceed to make business rules. |
| Project scope document | Describes project boundaries, detailing which features and parts should or should not be included in the project. This document also outlines the time frames and stages of project delivery. |
| Business rules | Every organization has its own wide set of corporate policies, laws, and industry standards. All these governing principles are collectively called business rules. These specify what the product should do but not how it should do it. All business rules must be implemented and maintained in line with more detailed requirements, such as scenarios and user stories. |
| Business capabilities | Describe project goals and objectives, methods that will be used to achieve them, and the technical and economic indicators of success. |
| Business objectives | Describe the predetermined milestones to be reached by the product over a given time period. |
| Success criteria | Set of metrics that help measure project success. |
Stage #2. Developing general documentation
General documentation defines all concepts and describes all objects, roles, and solution structure. This stage involves the creation of the following documents.
| Document's name | Description |
|---|---|
| Glossary | Glossary is based on Vision and Business Rules and lists all the technical and business terms so that the business stakeholders* and the developers can speak the same language. |
| Conceptual model | Abstract model that defines project structure, properties of its elements, and cause-and-effect relations. Architects, developers, and analysts need this model to form a solution architecture. The conceptual model serves as a reference for the logical data model and the object specifications description, based on which you can create the database (DB) structure. |
| Architectural model | Provides a comprehensive overview of the project architecture. Through this model, the developers and other team members can see all the architecturally important decisions made to deliver the project. |
| Class diagram / ER diagram | Defines system class types and the various static relations existing between them. Class diagrams also depict class attributes, class operations, and the constraints placed on the relations between classes. |
| Object specification | Clearly and accurately describes the essential technical requirements for objects, materials, or operations. Objects are digital counterparts of real-world entities described in the context of the software that requires them to function. Only software-essential attributes and methods of interacting with these counterparts are described. |
| Role description | Textual description of user roles within the system. Prepared for each role separately. |
| Function availability matrix | Contains a detailed description of functions available to a particular user role. |
*A business stakeholder is an individual or legal entity or a group of individuals whose actions and decisions can affect business operations, processes and profits. Stakeholders include suppliers, employees, shareholders, software customers, clients, and other parties who have a direct interest in the company's work and its results or have the opportunity to influence it indirectly.
Stage #3. Forming the functional requirements section
This section contains tasks for developers. These documents provide the entirety of all possible answers to questions that may arise during the development process. This stage involves the creation of the following documents.
| Document's name | Description |
|---|---|
| Top-level activity diagram | Describes system actions or people performing the actions, as well as their sequential flow. The activity diagram is the simplest and most accessible diagram for all team members since it’s similar to a regular flowchart but provides more detail. |
| Use Case-format requirements | Step-by-step scenario of user interaction with the system being designed. This representation includes a description of this interaction’s metadata, such as scopes, preconditions, triggers, postconditions, relevant business rules, etc. |
| BPMN Model | Flowchart that depicts all business process execution stages from beginning to end. BPMN diagrams provide a detailed visual demonstration of the sequence of work activities and the movement of information flows required to execute the process. It’s one of the key business management tools. |
| Sequence diagram | Presents the object life cycle and the interaction of information system actors within a single scenario for a set of objects on a single time axis. |
| Integration specifications | Detailed description of integration scenarios, e.g. payment systems or online maps. Also includes additional information describing aspects of the integration: type, data models, parameters, and non-functional integration requirements. |
| Low-detail screen layouts | Project screen images. Should only include basic information about transitions and functions. |
| Screen transition diagram | Simple, convenient, and illustrative diagram suitable for modeling transitions between screens, displaying messages, system actions, and procedures. |
| Screen form specifications | Detailed description of user interface elements and their attributes, such as data type, dimension, masks, data source, etc. |
| User Story | Description of user requirements in one or two sentences. The sentences can describe the user need or a specific feature, while also talking about the benefits this feature brings to the user. |
Stage #4. Preparing implementation requirements
The analyst coordinates the drafted documents with all development teams and prepares them for implementation.
The documents need to be coordinated with:
● business stakeholders to confirm that the business needs it;
● developers and the architect to make sure that these requirements can be fulfilled within the specified time frame; and
● testers to test the requirements.
This stage involves the creation of the following documents.
| Document's name | Description |
|---|---|
| Structural model of functions | This is a hierarchical model that depicts the relations between the individual scenarios required to implement specific functions. These functions are there to obtain a certain business value. |
| Tasks in the task tracker | The analyst creates tasks in the task tracker so that the project manager can distribute those to the developers. |
How an Analyst Adds Value to the Project
An analyst's contribution is more than simply improving convenience for the team: they reduce total project development time and costs. Pros of working with an analyst:
1. Improves communication. Applies to both the team-level and external party communication. This reduces development costs related to meetings and discussions.
2. Simplifies documentation. All related reworks are either described in separate requirements documents or reuse previously agreed and implemented requirements.
Documentation is maintained in a homogeneous and straightforward way that helps retain requirements history. As a result, you can go back to any previous requirements and spend as little time as possible on subsequent software reworks.
3. Saves developers' time. Since code is written according to the agreed requirements, the developers don't have to waste time on unnecessary discussions. The questions like "How should it work?" and "What does the business want?" have already been figured out by the analysts who are better equipped to deal with collecting, identifying, documenting, and coordinating requirements.
A single analyst can provide information to a small team of developers, allowing the latter to concentrate on writing code. This reduces task switching time and other time expenditures for the developers, while decreasing the overall stress level for the team.
4. Reduces non-core workload for the project manager and product owner. They don't have to describe requirements in detail and set tasks for developers. As a result, the process does not slow down and requires no additional development stages. This is made possible thanks to homogeneous documentation compiled using unambiguous methodologies that apply to the entire project.
The documentation also helps team members understand how to work with requirements, what constraints to consider during development, and where they can be creative.
5. Clearly outlines the result. The customer receives the exact deliverable they needed, their requirements satisfied. Any blank spots and ambiguities are eliminated at the requirements identification stage. All deviations from the basic positive scenario are considered, with an algorithm of actions described for each deviation. This reduces development costs related to reworks and unnecessary revisions.
6. Reduces new employee adaptation time. Thanks to homogeneous and detailed documentation, new employees only need a minimum amount of time to start working effectively.
7. Clearly defines project time frames. The general-to-specific approach allows one to estimate the project time frames as early as at the initial stage with a certain degree of accuracy, which will further increase with a more detailed description.
8. Provides momentum to start the project. Some projects get stuck at the planning stage, and some never see the light of day at all. The reason for this can be an inexperienced team or the size of the project when neither the team nor the manager know where to start.
The analyst takes ideas and turns them into clear documentation that you can follow during development. Now with a plan and a structure, the project forges ahead.
The analyst's work can be a big boon in reducing the time and therefore the money spent on project development, while also allowing you to increase the size of the team. It gets the project under control, reduces the overall stress level for the team, and allows each team member to focus on their core responsibilities.
In 2023, quality product development is impossible without a complete and comprehensive analysis. It's important for customers to understand analytical approaches and ask the development company what methodologies they use.
In the following articles, we will discuss analytics using examples of specific fintech products. Subscribe to our LinkedIn so you don't miss them.
You have a project but no idea how much time and money it will require? Fill out the form and sign up for a free consultation.