aggregation of customer requirements and creation of technical specifications

Despite the developed IT market in Russia, not everyone understands what is meant by “project analytics” in custom development. The developer writes the code, the tester checks the correctness of the work, and what does the project analyst do?

In this article, I will tell you who an analyst is and what roles they can perform. In the development sphere, two key roles are usually distinguished: a business analyst and a systems analyst. Both of these specialists take part in pre-project analytics, which is key to the successful start of any IT project. Let's consider the generally accepted concepts of these roles.

A business analyst is a specialist who focuses on a product and related business processes. Their main task is to conduct business analytics of the project, analyze how to improve the product so that it brings more benefits and profit to the company. The analyst studies the market, user needs, competitors and offers product development strategies.

A systems analyst is an engineer who is responsible for an IT solution and its functionality. Translates business requirements into technical specifications, develops the system architecture, and defines the required functionality and interfaces. The systems analyst creates detailed requirements for the IT product, which are then used by the development team.

However, in IT chats you can often see requests for a “general analyst” or even “BA/SA” with a slash. The topic of what a Business Analyst can do that, for example, a System Analyst cannot constantly causes debate among professionals, so these concepts are often combined. If we still differentiate these roles, then, in simple terms, a business analyst communicates more with clients, and a system analyst translates their wishes into the language of developers.

In practice, on projects, especially small-scale ones, these two roles are combined and perform a full cycle of analytical work, including pre-project analytics. This is the approach we will consider using the example of the development of the product in question.

Why do you need analytics?

First, let's figure out why analytics is needed on a project at all. It is needed to correctly understand the customer's expectations, design a solution to the tasks set, and plan the budget correctly.

The purpose of analytics is to obtain the structure of the future product, as well as to form an action plan: what we do, why and how.

Using a project as an example, I will show what we mean by “general analytics” and how it helps to design a solution to the tasks at hand.

“IDEA” is a web service for managing ideas for collecting feedback and improving processes in a company.

The purpose of the service is to collect ideas, as well as employee opinions about them. The system allows for a structured storage of incoming proposals, as well as functions: discussion of decisions, voting, tracking the status of concept development.

Choosing an approach

There are different methods and approaches to analytics. You can read more about them on various resources. Our task is to show the best approach to analysis within a specific project. The aggregation method was best suited for the tasks of our solution.

The approach involves the following stages:

1. Collection and aggregation of requirements. Suitable in cases where the task is already generally clear. When it remains only to identify details from stakeholders, project them onto the target audience of the product being developed, and also take into account the shortcomings of competitors, industry trends;

2. Prototyping. It is necessary to form a visualization of the functional sections of the product. At this stage, we will find out how the solution will work without the costs of design and programming;

3. Documentation. Preparation of technical specifications containing a description of the project's operating mechanisms.

Collection and aggregation of requirements

First, we conducted an interview: we collected the customer’s wishes, asked a number of questions, and drew up a meeting protocol.

After collecting the information, we can proceed to the aggregation itself, which consists of 5 steps:

1. Presentation. These are the main characteristics of the future product. Its goals, objectives, as understood by the creators of the product;

2. Target personas. Here we start from users. We segment the market, highlight the needs of users;

3. Competitive analysis;

4. Structure. What screens do we need. What will be on them;

5. Ideas for the future.

Formation of a project vision

Let's go in order. To form an idea of ​​the project, it is necessary to record the goals, as well as the tasks of the system. Here, intellectual maps (Mind map) will come to our aid – a recording method that allows you to structure information, to isolate the most important.

The high-level details of the solution in this format can grow large. For such cases, it is more effective to use the Lean Canvas template. It has nine blocks:

1) Consumer segments — a list of target users. In our product, such a user is an employee who suggests and comments on ideas, as well as a manager who moderates;

2) Problem – we highlight the main problems, as well as their possible solutions. Existing alternatives for proposing ideas: discussing them in a corporate messenger, as well as surveys. The main problems include:

• No response recording;

• Distributed discussion;

• Lack of approval procedure;

• Lack of statistical metrics.

3) Unique value. Factors that distinguish the project from competitors' products. The uniqueness of this system can be highlighted by a personalized set of functions, as well as the procedure for collecting and implementing ideas;

4) Solution. Displays the means of solving problems. It is desirable to provide specific solutions to each of the identified problems, matching them with color for example;

5) Channels. Lists of incoming and outgoing channels on the way to clients. This is not so relevant for the IDEA project. In our case, they will be corporate communication channels;

6) Profit streams. List of profit sources. In our case, the service is internal: it is aimed at increasing employee loyalty, improving work processes, so we do not calculate the profit stream;

7) Cost structure. Reflects a list of fixed and variable costs. Here you can highlight the costs of development, product support, and since we chose a web service as a solution, then also hosting.

8) Key metrics. The main indicators are indicated here. We will highlight the number of approved, accepted, and implemented proposals, employee engagement;

9) Hidden advantage. Features that are difficult to buy or fake. This includes: in-house development staff, design system, the ability to train new employees, loading employees who are without a commercial project.

As a result, we have a formed vision of the product. Usually, it can fit on one A4 sheet.

Defining target persons

Segmenting groups of people, building a CJM user journey map on our service is redundant. “IDEA” is not designed for large masses, and user behavior is clear to us.

For such internal decisions it is enough to present a table of persons. It is important to reflect in it the needs of users, their achievements, means of achievement, functions and also the associated assumed scenarios.

Competitive analysis

The next step is to conduct a competitive analysis. Study the subject area, choose alternatives, compare pros and cons. Since our service has other goals, namely collecting ideas and employee opinions about them, at this stage it is enough to get acquainted with existing solutions and draw the necessary functionality.

Drawing up a project structure

With the resulting artifacts, the analyst can begin planning the product structure. Create functional sections, their elements, interrelationships, as well as the general logic of work.

For informational purposes, we selected a set of elements:

• Square objects are conventional screens of the system;

• Rounded rectangles – functionality;

• Other elements – description of functionality.

Once a notation has been selected, the analyst creates basic screens and capabilities.

After this, the main part of the structure is compiled – the ideas section: the general functionality available to both groups of roles.

After defining the section's capabilities, the analyst supplements it with details – capabilities for the “manager” user group.

The remaining sections of the system are compiled in a similar manner. The final step is to demonstrate the results obtained. If any edits arise, they are discussed and entered into the system. As a result of edits, some functions and ideas may be eliminated. The final step of aggregation is formed – ideas for the future (Backlog).

Results of requirements aggregation

During the aggregation of requirements, we determine:

• Goals and objectives of the project;

• Needs of the target audience;

• Interrelation of functions without contradictions;

• Volume of work;

• Structure of the prototype solution.

Vladimir Zavertailov – author of the book “Project Manager's Handbook”

Plan at least two weeks for requirements aggregation

Prototyping

The requirements aggregation is ready. We agreed with all interested parties, we proceed to prototyping.

Selection of method and means

To begin with, let's say that a prototype is a supposed visual representation of the system. It reflects the functional content of the product. As a rule, the final visual representation of the product is a design layout. However, projects are different, sometimes the design stage is skipped, because everything depends on the customer's wishes, since it is possible to use ready-made UI libraries based on the prototype.

Now let's move on to the methods and ways of creating a prototype. The main difference between the methods is the level of detail. It can be divided into three gradations: low, medium, high. It depends on the functional content, the depth of development, and the level of specification. Each level of detail has its advantages and disadvantages. A high level of detail promises large expenditures of time resources. The choice of prototype depends on the project.

1. Low detail. For example, “Wireframe” is a framework that displays:

• Main content groups (what the user should see);

• The structure of the information, as well as the navigation design (where the main pages will be located);

• Description, basic visualization of user interaction with the system interface (how the user will need to perform a particular action in the system).

2. Medium detail. For example, an interactive prototype is a medium-detail representation of the final product that simulates user interaction with the interface, but with limited functionality. The prototype may differ slightly from the final product. However, the result should be similar to the prototype in both behavior and key interface elements.

3. Highly detailed. For example, a mockup is a static design representation of medium to high fidelity. Often, a mockup is a draft of a design or the visual design itself.

   

I decided to use an interactive prototype to clearly demonstrate the functionality of the system. The result will be of medium-high detail, given the ease of use of the set of ready-made UI elements.

Today, there are many different tools available for creating prototypes. Their choice depends on what the project needs and what skills the analysts have. The most common tools for these purposes are:

• Miro is an online whiteboard that has visualization tools. It has enough features to build a prototype;

• Figma is a dedicated application for interface development and prototyping;

• Pixso is an analogue of Figma, which has recently gained popularity.

Prototyping

After the method and means of implementation have been selected, you can begin filling the prototype. The analyst creates the necessary screens from a set of UI elements, places triggers, links the screens and shows the resulting result to the customer. As a rule, before the result is approved, one to three demonstrations are held, depending on the volume and degree of fixation of the requirements.

Results of prototyping

• We compiled and agreed on the structure of the composite pages with the customer;

• Confirmed end-user convenience in terms of personas;

• Synchronized the visual representation of all project stakeholders;

• We worked out alternative implementations of less viable ideas.

Figma, the most common tool for interface development, was used as a prototyping tool. This stage took 37 hours.

Documentation

The prototype is ready and approved, which means it’s time to move on to the next stage – drawing up a software requirements specification, also known as a technical task or simply a technical task.

Description format and structure

The technical task has different templates, and its content is individual, depending on the tasks.

To implement the project in question, I decided to use a template that I developed myself.

Integration with external systems is not provided. The project has a small set of entities and is based on one conditionally linear process. Therefore, it is reasonable to use the following set of sections in the document to describe it:

Contents of sections

After you have chosen the structure and approved the artifacts, we move on to a detailed description of the subsections:

• General view of the product. A subsection containing updated data obtained at the aggregation stage;

• Project boundaries. The project scope is defined here: what should be included in its implementation and what should not. For example, the implementation is limited to the desktop version. When opening the project on a mobile device, the computer version is displayed, the system localization is Russian, etc.;

• User classes and characteristics. This section contains the final user groups, as well as their properties and capabilities;

• Documentation priorities. A memo that reflects artifacts in order of importance: which document’s requirements have priority in cases of discrepancy;

• Operating environment. A subsection with requirements for the environment in which the product being developed should function. For example, the system is deployed on its own server; the system works with specific browsers of the latest versions; the system is supported on screens with a resolution of 1366×768;

• Design and implementation limitations. Section with design requirements and implementation features. For example: the project design must be based on UI elements since there is no layout; independent user registration is not provided;

• Glossary. Appendix with a list of project terms;

• Diagrams. Section with diagrams. For a project, it is enough to display the life cycle of an idea. We use the state diagram of the “UML notation”;

  

For ease of navigation in the subsection, it is permissible to provide a general table of user scenarios, which are known as Use Case.

Next, based on the prototype, a description is made of each functional section of the product:

• Description. Text description of section screens, elements and actions available to users;

• Use cases. A description of the actions the user performs and how the system should respond to them;

  

• Functional requirements. Queries for capabilities, mechanics, entity attribute sets, field validation conditions, state changes, list sorting, etc.

In cases where it is difficult to present the requirements in an informative manner, it is permissible to place them in a separate document.

The document presents the requirements concerning notifications in a convenient and understandable form. Their interrelations and links are presented. Let's look at each column:

• Notification Type. Displays all alerts in the system. Those that do not have the “a” prefix are not displayed in the lists;

• Event. Contains triggers for generating notifications in the system;

• Notification template. The column contains links to templates for generating notifications;

• Addressees. Contains groups of persons to whom the system sends notifications of the presented types;

• TriggerIt presents the conditions for sending a letter to the corresponding users;

• Letter template. Links to message templates that are sent by email;

• Scenarios. References to UC use cases or functional requirements if no use cases are provided.

• Notification templates. Contains templates for generating descriptions of notifications within the system, as well as templates for letters generated and sent outside of it;

• Quality attributes. Non-functional system requirements;

• Links to documents. Sources for all resulting documentation.

The main difficulty in compiling a description is to understand how to present the requirements in the most informative and convenient way. To make it easy to read, you can use links to elements: pictures, specific requirements, etc.

Documentation Results

As a result of this stage, the requirements for each functional section of the system were recorded. For this purpose, the logic of its operation was described in detail.

At the documentation stage we used: google.docs, miro / figma.

During the stage, the consideration of the example took 80 hours.

Conclusion

Project analytics is needed to correctly understand the customer's expectations, determine the project scope, and plan the budget wisely. At the analytics stage, the project structure is formed. This is a complex process that lays the foundation for successful development. Using the IDEA project as an example, we examined the key stages: requirements aggregation, prototyping, and documentation. Each of these stages contributes to the formation of a clear vision of the product.

With the efforts of one analyst, it was possible to collect and structure the requirements, implement a visual representation of the product, and also form a technical task in a month. Of course, the final deadlines depend on the specific project, its conditions, user needs, the number of entities, their dependencies, the presence of integrations with external systems, etc.

It is important to note that the analytics process is flexible and can be adapted to the needs of a specific project. The use of various tools, from mind maps to specialized software, helps make this process more efficient.

As a result, we get not just a set of documents, but a clear understanding of what needs to be created, for whom and how it will work. This significantly reduces project risks, optimizes resources and increases the chances of creating a product that really solves the tasks set.

Remember that quality analytics is an investment in the success of a project. It allows you to save time and resources at the development stage, avoid misunderstandings between the customer and the contractor, and ultimately create a product that will satisfy all participants in the process.