Как написать функциональные требования - Правописание и грамматика

Как писать функциональные требования

Время на прочтение
5 мин

Количество просмотров 111K

Привет, Хабр!

Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.

На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.

Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.

В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.

Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.

В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.

Функциональные требования: что это такое и зачем они нужны

Для начала давайте разберемся, что такое функциональные требования.

Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.

Функциональные требования, как правило, состоят из:

User story — показывает, чего вы ожидаете от команды разработки
Use cases — показывают сценарии использования фичи
Wireframes — средство визуализации своей идеи

Сегодня мы сосредоточимся на User story и Use cases.

User story

User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.

Как правило используется шаблон:

As a/an <Название роли>, I want to <Цель, Действие>, so that <Ожидаемый результат>, to do <Что нужно сделать разработчику>

Существуют различные примеры применения этой методологии. Например, так это работает в Trello:

В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.

Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.

Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.

Задачи пользователя:

Загружать изображения
Вставлять изображения в шаблон письма
Удалять изображения

Для каждой задачи нужно написать свой use case — описание того, как пользователь взаимодействует с интерфейсом.

Примеры use case’ов:

Загрузка изображений:

Email-маркетолог заходит в свой личный кабинет Retail Rocket
Email-маркетолог открывает раздел «Галерея»
Email-маркетолог загружает изображения через drag&drop или с помощью клика по кнопке «Выбрать файлы»
Изображения загружаются
Пользователь видит уведомление об успешной загрузке изображений

Удаление изображений:

Пользователь кликает на изображение
Изображение выделяется
Выделение можно снять при помощи клика на область за пределами выделенного изображения
Пользователь нажимает на иконку «три точки»
Появляется контекстное меню
Пользователь выбирает в нем ссылку «Удалить файл». Если было выделено несколько изображений, то удалятся все
Изображение удаляется

Таким же образом расписываются все сценарии использования, что дает разработке четкое понимание, как выглядит взаимодействие пользователя с продуктом или фичей, и что для этого нужно сделать.

Почему функциональные требования так важны

Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.

Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.

Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:

нужно ли удаление файла вообще?
будет ли это ручное удаление или автоматически стираются самые старые файлы при загрузке новых, если превышен лимит пространства для хранения?
удаление происходит из списка файлов или нужно открыть файл?
файл удаляется навсегда или есть корзина для файлов, где они хранятся какое-то время? если нужна корзина, то сколько файлы в ней хранятся?
должно ли быть пакетное удаление файлов или можно удалять только одному?
файл удаляется с помощью отдельной иконки (как выглядит эта иконка?) или через пункт меню (как он будет называться? на каком месте в списке действий расположен?)
и т.д.

И ведь это всего лишь один из пунктов задачи, а уже столько вопросов. И на выяснение каждого требуется время и усилия с обеих сторон.

Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.

Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.

А как вы подходите к постановке задач разработчикам?

Директор по продукту Гульфия Курмангалеева

Источник

Что такое функциональные требования: примеры, определение, полное руководство

Что такое функциональные требования? Этот вопрос часто ставит в тупик как владельцев бизнеса, так и разработчиков. Функциональное требование можно рассматривать как особенность продукта, которую обнаруживает пользователь. Это может быть очевидная функция, например, большая кнопка «Добавить в корзину». Но это также может быть и менее очевидная функция, например, правильный расчет налога с продаж для онлайн-покупки пользователя. В этом полном руководстве мы разобьем функциональные требования на их простейшие формы и приведем примеры каждого типа. Мы также определим, что каждый тип требований означает для вашего бизнеса и как их создать.

Что такое функциональные требования?

Функциональное требование — это заявление о том, как должна вести себя система. Он определяет, что система должна делать, чтобы удовлетворить потребности или ожидания пользователя. Функциональные требования можно рассматривать как функции, которые обнаруживает пользователь. Они отличаются от нефункциональных требований, которые определяют, как система должна работать внутри (например, производительность, безопасность и т. д.).

Функциональные требования состоят из двух частей: функции и поведения. Функция — это то, что делает система (например, «рассчитать налог с продаж»). Поведение определяется тем, как это делает система (например, «Система должна рассчитать налог с продаж путем умножения покупной цены на налоговую ставку»).

Типы функциональных требований

Вот наиболее распространенные типы функциональных требований:

Деловые правила
Сертификационные требования
Требования к отчетности
Административные функции
Уровни авторизации
Отслеживание аудита
Внешние интерфейсы
Управление данными
Правовые и нормативные требования

Создание функциональных требований:

При создании функциональных требований важно помнить, что они должны быть конкретными, измеримыми, достижимыми, актуальными и привязанными ко времени (SMART). Другими словами, ваши функциональные требования должны:

Уточните, что должна делать система
Быть измеримым, чтобы вы могли сказать, делает ли это система
Быть достижимым в установленные вами сроки
Будьте релевантны вашим бизнес-целям
Будьте привязаны ко времени, чтобы вы могли отслеживать прогресс

Следуя этим рекомендациям, вы можете быть уверены, что ваши функциональные требования ясны и помогут вашей команде разработчиков создать правильный продукт.

Примеры:

Чтобы дать вам лучшее представление о функциональных требованиях, давайте рассмотрим несколько примеров.

Пример # 1

: Пользователь должен иметь возможность войти в систему, используя свое имя пользователя и пароль.

В этом примере функция — «вход», а поведение — «Система должна позволять пользователю входить в систему, используя свое имя пользователя и пароль».

Пример # 2

: Система рассчитывает налог с продаж для покупки пользователя.

В этом примере функция — «рассчитать налог с продаж», а поведение — «Система должна рассчитать налог с продаж путем умножения покупной цены на налоговую ставку».

Пример # 3

: система отправляет пользователю электронное письмо с подтверждением после того, как он успешно разместил заказ.

В этом примере функция — «отправить электронное письмо с подтверждением», а поведение — «система должна отправить электронное письмо с подтверждением пользователю после того, как он успешно разместил заказ».

Как видите, функциональные требования — это конкретные утверждения о том, что должна делать система. Они отличаются от нефункциональных требований, которые определяют внутреннюю работу системы (например, производительность, безопасность и т. д.).

При создании функциональных требований важно помнить, что они должны быть конкретными, измеримыми, достижимыми, актуальными и ограниченными по времени (SMART). Следуя этим рекомендациям, вы можете быть уверены, что ваши функциональные требования ясны и помогут вашей команде разработчиков создать правильный продукт.

Чем функциональные требования отличаются от нефункциональных требований?

Функциональные требования, как следует из названия, описывают функции разрабатываемой системы. Это описание того, какой будет система и как она будет функционировать для удовлетворения потребностей пользователей. Они обеспечивают четкое описание того, как система должна реагировать на конкретную команду, функции и ожидания пользователей.

Нефункциональные требования объясняют ограничения и ограничения разрабатываемой системы. Эти требования никак не влияют на функциональность приложения. Кроме того, существует обычная практика разделения нефункциональных требований на различные категории, например:

Пользовательский интерфейс
Надежность
Охранник
Производительность
Обслуживание
Стандартный

Подклассификация нефункциональных требований является хорошей практикой. Это помогает при создании контрольного списка требований, которые должны быть выполнены в разрабатываемой системе.

Нефункциональные требования так же важны, как и функциональные. Если функциональные требования определяют, что должна делать система, то нефункциональные требования описывают, как она будет это делать. Например, новое приложение должно предоставить нам окончательный список всех подключенных пользователей. Это часть функциональных требований. Если в требовании говорится, что система будет работать только в системах Windows и Linux, это будет частью нефункциональных требований.

Единственная разница между ними заключается в том, что система не может функционировать, не удовлетворяя всем функциональным требованиям. С другой стороны, система даст вам желаемый результат, даже если она не удовлетворяет нефункциональным требованиям.

Вывод:

Функциональные требования являются ключом к успеху любого проекта по разработке программного обеспечения. Создавая функциональные требования, вы гарантируете, что каждый в вашей команде понимает, что нужно создать, и может соответствующим образом расставить приоритеты в своей работе. В следующем посте мы обсудим, как создавать функциональные требования с помощью Платформа ALM для требований Visure. Если вы хотите узнать больше о функциональных требованиях или приступить к их самостоятельному созданию, запросите бесплатную 30-дневную пробную версию на платформе Visure Requirements ALM уже сегодня.

Источник

Writing functional requirements for a huge software application is not an easy task. This article describes different levels of s/w requirements: general scenarios, use cases, algorithms and checks, object types’ descriptions, and how they are connected to each other. It shows a way to describe requirements so that developers can effectively use them for their work on all system layers: database, application server, GUI.

Introduction

Once a friend of mine said that instead of reading requirements, he usually invited an analyst to a cup of tea, they sat down together and the analyst told him what should be implemented. My friend is an intelligent person and a good programmer, and the reason why he gets knowledge of the requirements in this way is not because he is too lazy to read the documentation, but because even after going through it, he is usually not sure what should be implemented. In this article, I want to describe a way to write requirements for a software product so that developers not only use them, but also participate in their writing. Based on my experience, I would like to show the way to write software requirements to almost completely describe what should be implemented.

About Our Project

The aim of our project was to create a part of an internal ERP system for one of the largest Russian distribution companies from scratch. The system was designed to replace the old one written in the late 90s. As a result, the platform and one of the business modules were implemented. The product consisted of about 120 business object types, 180 database tables, 30 printing forms.

Note the approach shown below is mostly suitable for enterprise systems which are being built using an object-oriented approach: CRM, ERP, accounting, document management systems, etc.

Our project documentation consisted of the following parts:

The common part
- Glossary
- Business roles
Requirements
- Business requirements
  - General scenarios
  - Use cases
  - Algorithms and checks
- System requirements
- Non-functional requirements
- Integration requirements
- User interface requirements
Implementation
Testing
End user documentation
Management

The common part described terms and business roles used in the project. The rest of the documentation including, for example, test cases are based on the definitions given here.

Business requirements are what business users needed, they consisted of several levels: general scenarios, use cases, and data processing algorithms. You can find how to develop them in the book Software Requirements by Karl Wigers.

System requirements described methods and properties of all object types in our system.

In this article, I will discuss these three parts in detail. Also to those who want to know more about Non-functional requirements, I can recommend the excellent book, Architecting Enterprise Solutions: Patterns for High-Capability Internet-based Systems by Paul Dyson and Andrew Longshaw.

Let’s take a closer look at the glossary and discuss why it is so important.

Glossary

A glossary is a list of terms used in a project and their definitions. Very often, discussions between project members about the particular functionality come to a standstill. The situation is even worse when after a long talk, people go to their workplaces with different understanding of what they have just talked about and what needs to be done. In many cases, this happens because the team members didn’t agree on the precise meaning of some terms. Sometimes, even the simplest words cause problems: what a user or a client is, what the difference between a role and a group is, etc. To eliminate such problems, we tried to give each term a definition as precise as possible.
Let’s discuss the term User as an example. Wikipedia gives the following definition:

A user is a person who utilizes a computer or network service.

It didn’t suit us because our system stores data not only about users who can login into it, but also about inactive and even deleted users, i.e., about users who used the system before but cannot do it at the moment. Moreover, we have data about potential users, we can create an account for a client company’s employee who may (or may not) later get access to the system. Our definition:

A user is a person who had, has or possibly will have access to the system to perform operations.

Now a programmer, having read this definition, would immediately understand why the Login property in the User object type is optional.

Many terms are related to each other. The term Operation is used above, so here is its definition:

An operation is a set of actions that make up the content of one business activity. The operation must comply with the requirements of ACID (Atomicity, Consistency, Isolation, Durability). The set of operations of one module represents the client-server interface of this module.

As you may see, this definition is very important, it not only connects a user and his business activities with functionality that should be implemented, but imposes requirements on how this functionality should be implemented (this was determined earlier when the system architecture was developed) — business actions must be inside a transaction.

We kept working on the list of terms as we went along. We maintained its completeness, i.e., we tried to ensure that the documentation had no undefined terms. There were cases when we had to change definitions. For example, after several months of use, we decided to replace Counterparty with Company. The reason was very simple — it turned out that no one used the word Counterparty in conversations. And so, it had to be replaced with something more obvious.

Often, we had to interrupt our discussion and reread terms in order to understand if the discussed functionality fit our definitions. Sometimes, to maintain consistency of our requirements, we ultimately had to either change the implementation or rewrite definitions.

As a result, we had about 200 business and system term definitions in our list; and they were used not only in all the documentation, including, for example, the technical design developed by programmers, but also in conversations when we verbally discussed some functionality.

The glossary was the first part on which all our documentation relied. The second part was a description of business roles.

Business Roles

Since our system is an interactive one, there are only two subjects: users and the system. But in an enterprise application, users have different roles and permissions. Possibly the simplest example is the difference between a system administrator and other users. In a large system, there can be dozens of roles, a business analyst should think about them in advance, define them and specify them in general scenarios and use cases as actors, i.e., users that interact with the system in this or that scenario. The list of business roles was used to create user groups in the system and assign permissions to them. Test engineers tested the system using different roles.

Since the company already had well-established departments and functional responsibilities, we didn’t have to make up roles from scratch, we just based them on the analysis of the existing employee responsibilities. We assigned permissions to roles after development was finished and before deployment because only at this time the list of functional permissions became stable.

There are two examples below:

Business role	Abbreviation	Department	Responsibilities
Dealer Manager	DM	Sales department	DM sells goods to clients, creates client buying requests, bills and shipments in the system. Every DM has a particular list of clients he/she works with.
Clients department specialist	CDS	Clients department	CDS discusses shipment details with DMs and clients (shipment and delivery time, missing parts, etc.), prepares papers for shipments and logistic documents for delivery.

Now when we have all our terms defined and have clearly described who interacts with the system, we can discuss how to write requirements.

Levels of Requirements

One of the important concepts that we applied developing the requirements was dividing them into levels. Alistair Cockburn in his book Writing Effective Use Cases distinguishes five levels, but we used four. Here they are:

General scenarios — Cockburn’s white level
Use cases — Cockburn’s blue level
Algorithms and checks — Cockburn’s black level
System requirements — there is no such level in the book, in fact, it is under the black one

The structure of our requirements was a tree. General scenarios were refined by use cases, which, in turn, had links to checks and algorithms. Since we used a wiki software, we could easily implement such a structure. Use cases, algorithms and checks used the object types, their properties, and methods described in the system requirements.

On the one hand, this concept allowed us to describe the current piece of requirements in as much detail as necessary at a given level, relegating other details to the lower one. On the other hand, at each level, it was possible to go to the higher level to understand the context. This was also provided by the wiki functionality: often scenarios, use cases, algorithms and checks were written on separate pages, and the wiki allowed to see what pages link to the current one. If an algorithm was required in more than one use case, the algorithm was placed on a separate page. Usually our developers implemented such algorithms as dedicated methods.

The picture below shows the requirements related to the Printing document task (PDT) object type on different levels. I will discuss them later.

It is worth mentioning that while system requirements described all object types without exception, we didn’t need to write use cases for all of them. Many of the object types represented lists of something (countries, months, time zones, etc.) and were used similarly. This allowed us to save our analysts’ time.

An interesting question is which stakeholders and project team members use which requirement level. Future end users can read general scenarios, but use cases are too complicated for them. Because of this, our analysts just discussed them with end users and didn’t ask them to read or review use cases. Programmers usually need algorithms, checks and system requirements. You definitely can respect a programmer who reads use cases. Test engineers need all levels of requirements, since they test the system at all levels.

In comparison with, for example, MS Word documents that are still widely used, Wiki allowed our requirements to be changed by several team members at the same time. Note at the same moment different parts of requirements were in different states: from ‘In Work’ to ‘Implemented’.

Let’s talk about general scenarios, the topmost requirement level.

Business Requirements

General Scenarios

The root page of our requirement tree consisted of general scenarios, each of which described one of 24 business processes to be implemented in this ERP module. The scenarios were located on the page in the order in which they occurred in the company’s actual workflow: from creating a shipment with sold goods to delivering it to a client. Some specific or side scenarios were placed on separate pages.

A general scenario is a sequence of steps taken by the user and by the system to achieve a specific goal. It provides an outline, a summary of the company’s process and does not have to mention every detail, they are described in use cases related to this scenario. Our general scenarios contained steps performed not only inside the system, but also outside it to show users’ work in its entirety, with the complete sequence of steps necessary to achieve the business goal.

Other reasons why we need general scenarios are:

consolidating knowledge about the company’s business processes
having an agreement on business processes with future users
being sure that requirements are complete, nothing is missing
having the starting point for looking for a particular use case or algorithm

Below is a business scenario example:

Printing documents, performed by Clients department specialist

The purpose is to print and deliver the client’s shipment documents

The user performs batch printing of shipment documents, i.e., chooses a Printing document task from the list by a shipment number, changes its state to ‘In Work‘ and prints the documents.
The user checks that documents have been printed correctly and changes the Selection task’s state to ‘Ready‘.
If the company should deliver the shipment to the client, CDS puts the prepared documents in separate piles depending on city or regional delivery.
If the client picks up the shipment itself, CDS gives the prepared documents to the client’s representative.

As you can see, only half of the steps are performed in the system. Also, it seems that we could simplify the work of the user if at the second step, the system, not the user, would change the Selection task’s state to ‘Ready’.

At the first step, the link ‘Printing document task’ pointing to the object type in system requirements is superfluous since no one who reads a general scenario wants to read details about an object type. At the same time, the link ‘batch printing of shipment document’ is very important because it leads to the use case that formally describes the user’s and the system’s actions.

Let’s go down one level, to use cases, and see what is written in the ‘Batch printing of shipment documents‘ use case.

Use Cases

Our use cases had the following template:

Header with the following fields
- State, one of these: In Work, Ready to Review, Approved
- Business roles (of the users that interact with the system in this scenario)
- Goal
- Preconditions
- Minimal Guarantees
- Success Guarantees
- Link to the UI screen form (designed by a UI designer)
- Link to the test case (added by a test engineer)
Main scenario
Possible extensions to the main scenario

Use cases consisted of numbered steps of actions, each of which usually began with the word ‘User‘ or ‘System‘, because as you remember, there are only two actors. Numbering was important because it allowed us to refer to a particular step in questions and comments related to this use case. Each step is a simple sentence in the present tense.

And now, here is the use case the ‘Printing documents‘ general scenario above refers to.

Batch printing of shipment documents
State: Approved
Users: Clients department specialist
Goal: Have shipment documents printed
Preconditions: UI shows the list of printing document tasks
Minimal Guarantees: Printing document task is still in the ‘Created’ status
Success Guarantees: Shipment documents have been printed, the printing document task moved to the ‘Ready’ status.
UI: Batch printing for N shipments
Checklist: Batch printing of shipment documents (checklist)
Main scenario

User selects the printing document task (PDT) in the ‘Created’ status and presses the ‘In Work’ button.
System changes PDT’s status to ‘In Work’ according to Algorithm for changing PDT’s status to ‘In Work’ and refreshes the list.
User presses the ‘Batch printing’ button.
System shows the ‘Batch printing for N shipments’ screen
User selects a Kit.
System shows the Kit’s specification.
User makes sure that the number of documents in the Kit is correct, corrects it if necessary, presses the ‘Print’ button
System runs the Algorithm for creating documents for batch printing and prints created documents
User makes sure all necessary documents are printed and presses the ‘To Ready’ button
System changes PDT’s status to ‘Done’ according to Algorithm for changing PDT’s status to ‘Done’ and refreshes the list.

As you see, the scenario is very detailed, in fact, it can be used as a test case. It follows all the rules on how to write requirements: each requirement should describe only one thing and be unambiguous, its start and end are clearly defined, it doesn’t contradict other requirements, it is written because users need it, it can be implemented and verified.

Sometimes analysts create screen forms and write use cases based on them, explaining this by the fact that this is clearer. There is some truth in it, but we held the position that the user interface is the business of a UI designer. First, an analyst describes what should happen, and then a UI designer draws a sketch of a screen form or a Web page. Sometimes, after that we had to change the use case. This is nothing to worry about, because our aim is to design all parts of the systems so that users could do their work in the most convenient way. And each member of the project team, whether an analyst or a UI designer, having specific knowledge and contributing to the common cause, has an impact on the work of other members of the project team. Only together, joining forces, we can achieve an excellent result.

As you can see, our scenario refers to three algorithms: Algorithm for changing PDT’s status to ‘In Work’, Algorithm for creating documents for batch printing and Algorithm for changing PDT’s status to ‘Done’. The first of them is shown in the next section.

Algorithms and Checks

When we wrote algorithms, we ran into a funny problem. Analysts tried to include all possible checks. However, the result was very poorly readable and, as a rule, some details were missed anyway (probably this happened because there was no compiler -). Therefore, we decided that the analyst should describe only what is important for the business logic, the programmer who would implement it had to provide all necessary checks in the code. This is a kind of challenge for programmers, but I’m sure that a project team can create a solid system only if all of them, including programmers and test engineers, know about the business processes they are implementing. Having good written requirements is one thing, but even this doesn’t allow programmers to be ignorant of what the system does in general and how it helps its users in their business.

Here is our algorithm.

Algorithm for changing PDT’s status to ‘In Work’

State: Approved
Main scenario

If PDT’s status = ‘Created’ or ‘Ready’, System:
1. Sets User = <current user>
2. Sets Status = ‘In Work’
3. Recalculates Shipper’s number

The algorithm indicates only one check but obviously when a programmer writes the related code, he/she should implement checks on input parameters, throw an exception if the current user is not defined, etc. Since algorithms of moving a PDT between different statuses are very similar, the programmer can decide to write one only non-public method for changing PDT’s status to all possible values. In this case, at the API level, the same operations remain, but all of them call the same parameterized method. Choosing the best implementation of algorithms is a part of a programmer’s work.

And finally, we go down to the deepest requirement level, at which all system objects are described in detail. We will see what our ‘Print document task‘ object type consists of. This level is so deep that many books about requirements do not mention it at all.

System Requirements

It is well known that Programs = Algorithms + Data Structures. Thus, by and large, all that a programmer needs to know are the data structures and the algorithms that manipulate them.

We used the object-oriented approach and since it is based on the concepts of classes, our data structures are classes with fields and methods. Since the word ‘class‘ is specific to programming here I use ‘object type‘ instead.

Every object type description consisted of the following parts:

Object type definition from the glossary
Object type properties
Object type operations and their permissions
Data related to this object type
Additional information

Let’s start from the second bullet since definitions were already discussed in the ‘Glossary’ section.

To describe object types, we used tables because they help to organize information, more visual, and easily extensible.

The first table included object type properties and their attributes that were necessary to create data structures in the database and implement this object type on the application server. We used the following attributes:

Name	The object type name used by end users and project team members. For example: “I changed the bill number” — Number is a property of Bill. Throughout the documentation, we used references to object type properties as “`Object Type.Property`”.
Data Type	We used the following data types: `Datetime`, `Date`, `Time`, `GUID`, `String`, `Enum`, `Integer`, `Money`, `BLOB`, `Array()`, `Float`, `Timezone`, `TimeSpan`. Each data type had a reflection on all system levels: in the database as a DB field’s type, on the application server as a type of C# programming language, and in the UI where there were several types of controls associated with each data type so that we could use, for instance, a dropdown or a combobox for `Enum`s. Each type had a definition so that programmers knew what to implement. For example, `Money` was defined in this way: includes two parts — a positive or negative float number accurate to the 4^th decimal place, and a currency, the Russian ruble by default.
Editable	Yes or No depending on whether users can change an object type property value in the `Edit` operation. If `No`, this restriction was implemented on the application server and in the UI.
Nullable	Yes or No depending on whether the property can have no value. For example, in our system, Boolean properties must have one of two possible values, but `String` properties have `NULL` by default. If `No`, this restriction was implemented on the database level and on the application server.
Unique	Yes or No depending on whether a property value is unique. Often, uniqueness was defined for a set of properties in this case `Yes+` was set for all of these properties. This restriction was implemented on the database level as a database index and on the application server.
Comment	The property description: what it means, what it is for, how it is used. If the property value is calculated, the comment refers to the calculation algorithm.

In addition to these attributes, the table included two more columns that were filled by server-side programmers when they had implemented the object type:

The object type property name in the code
The database field name

Both of these attributes are optional, because, for example, the property of an object type may not be stored in the database but be calculated like a bill amount.

I want to highlight that programmers took part in requirement development. This is important for many reasons. Firstly, in this way, programmers were better aware of the requirements, moreover, the requirements became not just a piece of paper written by some analyst. Secondly, we had the API documentation at once. Thirdly, at any moment, we could clearly understand the current state of every object type’s implementation, that became especially important when requirements were being modified. Of course, this methodology required programmers to be more disciplined, which in fact was a positive factor.

Also, because of these columns, programmers of different application levels could always understand the relation between the object type property in requirements, the related database field and the application server API.

As I already wrote, a table representation is very extensible. For example, for some object types for integration with a legacy system, we had an additional column where we described the data migration algorithm. Also, we used special icons to indicate how this property looks in the UI. At one time, we had a column with database index names so that programmers would not forget to create them for unique properties. If necessary, you can add more columns.

Here is the typical object type description in our system:

The second table described the object type’s operations and related permissions. Every operation had a unique name on the application server (the Operation column) and a short menu name in UI (the Short name column). To perform an operation, the necessary permission should be granted to a user (the Permission column). For some operations, the Comments column described their algorithms or had a link to them. The API column was filled in by programmers. As in object type’s descriptions, this was necessary to document the API, to increase the programmers’ involvement in requirement development and to visualize the current state of this object type’s development. Here is an example:

The description of the PDT status Enum was also here:

Value	Description	Sort order	Active	XEnums.PrintTaskStatus
Created	Initial status	1	1	Created
In Work	Somebody is working on the PDT	2	1	InProgress
Ready	PDT is finished	3	1	Ready

Here is a table of possible PDT’s transitions between statuses, and corresponding operations:

Source status Target status	Created	In Work	Ready
Created	—	To Work	—
In Work	Cancel	—	To Ready
Ready	—	To Work	—

As you see, the PDT object type is simple, for complex cases, we created more sophisticated diagrams.

Right after deployment of the system, it should contain some data. For example, the administrative user, the list of currencies and countries and so on and so on. This information was described in the Data section.

Also, we had the Additional information section with relations between the object type and the legacy system that we migrated from.

Summing up, the system requirements for an object type included all information necessary to implement it: a database table structure and related constraints, a domain object’s fields and methods, all necessary algorithms, as well as deployment data. The structure of the description was easy to understand and extensible.

Many may say that such detailed requirements are time consuming and not necessary. But without them, how would a programmer know what exactly needs to be implemented? Is the phrase, “Please implement the User object type” enough to code? How much tea should be drunk with an analyst to get information about 40 (we had so many) properties of the object type User? Who, if not an analyst or designer, should make an effort to describe all object types?

At the bottom line, I want to say that the glossary and business roles, general scenarios, use cases, algorithms, checks, and system requirements, all together allowed us to implement and deploy a huge part of the ERP system in a short time. Yes, requirement management takes time and effort, but good requirements allow us to greatly decrease programming and testing time.

Tasks for Developers

Now, after I explained how our requirements were written, let me describe how we formulated tasks for server-side programmers.

Standard Task #1

Title: Implement the object type <object type name>

Description: The link to the wiki page with the object type’s system requirements

A programmer should do the following:

Create database objects (tables, primary and foreign keys, triggers, etc.)
Implement the domain object (as well as internal application server classes like a repository, service, etc.)
Write the code to populate the database with initial data

Everything above can be done based on the link provided. The programmer should update the object type’s property table by providing database table field names and object type property API names.

Standard Task #2

Title: Implement operations and necessary permissions of the object type <object type name>

Description: The link to the wiki page with the object type’s system requirements

On the wiki page, a programmer can find the operation’s names, permissions and in the Comment column necessary to implement algorithms and checks.

Standard Task #3

Title: Change the object type <object type name> and its operations

We created tasks of this type if we had changed this object type’s requirements. The task description included the description of the changes or just a link to a version comparison page.

The Tool to Manage Requirements

It was Atlassian Confluence that helped us to successfully implement requirement development and management. In this last section, I want to point out several of its important advantages:

Possibility of remote work
Links. As you saw above, links allowed us to have different pieces of the requirements on different pages and at the same time, they were connected to each other and together formed the single document.
Notifications when something is changed. This is one of the most important instruments for team work. For example, having received such a notification the project manager can create tasks for developers and test engineers know that it is necessary to update checklists.
Comments. Many of our pages had a big number of comments. It is very convenient to work with comments in Confluence because it supports threads. Also, you can use its rich text editor to highlight something in your comment.
The powerful rich text editor.
Page history, ability to compare different versions, rollback to an old version.
Ability to view and reorganize pages in the tree hierarchy.

Of course, we also ran into several problems:

As soon as the whole documentation uses the same names of object types and their properties, it would be very useful to have a tool to automatically change the changed name across all the pages.
No statistics. For example, every page had a status. But we couldn’t automatically collect statuses of all pages and have a picture of the current requirement development state.
We had to create complex diagrams in another application, save them in PNG format and add them to a Confluence page. Besides that, it was necessary to attach the source file for further modifications.
I failed to find a way to export a page hierarchy to MS Word. Export to XML and PDF had glitches. I hope Atlassian has already fixed these issues.
It is not possible to collapse comment threads. This becomes necessary when you want to somehow hide a thread with a big number of comments because the discussion is already finished.

History

5^th May, 2020: Initial version

This member has not yet provided a Biography. Assume it’s interesting and varied, and probably something to do with programming.

Источник

Introduction

About Our Project

Note the approach shown below is mostly suitable for enterprise systems which are being built using an object-oriented approach: CRM, ERP, accounting, document management systems, etc.

Our project documentation consisted of the following parts:

The common part
- Glossary
- Business roles
Requirements
- Business requirements
  - General scenarios
  - Use cases
  - Algorithms and checks
- System requirements
- Non-functional requirements
- Integration requirements
- User interface requirements
Implementation
Testing
End user documentation
Management

The common part described terms and business roles used in the project. The rest of the documentation including, for example, test cases are based on the definitions given here.

System requirements described methods and properties of all object types in our system.

Let’s take a closer look at the glossary and discuss why it is so important.

Glossary

A user is a person who utilizes a computer or network service.

A user is a person who had, has or possibly will have access to the system to perform operations.

Now a programmer, having read this definition, would immediately understand why the Login property in the User object type is optional.

Many terms are related to each other. The term Operation is used above, so here is its definition:

The glossary was the first part on which all our documentation relied. The second part was a description of business roles.

Business Roles

There are two examples below:

Business role	Abbreviation	Department	Responsibilities
Dealer Manager	DM	Sales department	DM sells goods to clients, creates client buying requests, bills and shipments in the system. Every DM has a particular list of clients he/she works with.
Clients department specialist	CDS	Clients department	CDS discusses shipment details with DMs and clients (shipment and delivery time, missing parts, etc.), prepares papers for shipments and logistic documents for delivery.

Now when we have all our terms defined and have clearly described who interacts with the system, we can discuss how to write requirements.

Levels of Requirements

General scenarios — Cockburn’s white level
Use cases — Cockburn’s blue level
Algorithms and checks — Cockburn’s black level
System requirements — there is no such level in the book, in fact, it is under the black one

The picture below shows the requirements related to the Printing document task (PDT) object type on different levels. I will discuss them later.

Let’s talk about general scenarios, the topmost requirement level.

Business Requirements

General Scenarios

Other reasons why we need general scenarios are:

consolidating knowledge about the company’s business processes
having an agreement on business processes with future users
being sure that requirements are complete, nothing is missing
having the starting point for looking for a particular use case or algorithm

Below is a business scenario example:

Printing documents, performed by Clients department specialist

The purpose is to print and deliver the client’s shipment documents

The user performs batch printing of shipment documents, i.e., chooses a Printing document task from the list by a shipment number, changes its state to ‘In Work‘ and prints the documents.
The user checks that documents have been printed correctly and changes the Selection task’s state to ‘Ready‘.
If the company should deliver the shipment to the client, CDS puts the prepared documents in separate piles depending on city or regional delivery.
If the client picks up the shipment itself, CDS gives the prepared documents to the client’s representative.

Let’s go down one level, to use cases, and see what is written in the ‘Batch printing of shipment documents‘ use case.

Use Cases

Our use cases had the following template:

Header with the following fields
- State, one of these: In Work, Ready to Review, Approved
- Business roles (of the users that interact with the system in this scenario)
- Goal
- Preconditions
- Minimal Guarantees
- Success Guarantees
- Link to the UI screen form (designed by a UI designer)
- Link to the test case (added by a test engineer)
Main scenario
Possible extensions to the main scenario

And now, here is the use case the ‘Printing documents‘ general scenario above refers to.

User selects the printing document task (PDT) in the ‘Created’ status and presses the ‘In Work’ button.
System changes PDT’s status to ‘In Work’ according to Algorithm for changing PDT’s status to ‘In Work’ and refreshes the list.
User presses the ‘Batch printing’ button.
System shows the ‘Batch printing for N shipments’ screen
User selects a Kit.
System shows the Kit’s specification.
User makes sure that the number of documents in the Kit is correct, corrects it if necessary, presses the ‘Print’ button
System runs the Algorithm for creating documents for batch printing and prints created documents
User makes sure all necessary documents are printed and presses the ‘To Ready’ button
System changes PDT’s status to ‘Done’ according to Algorithm for changing PDT’s status to ‘Done’ and refreshes the list.

Algorithms and Checks

Here is our algorithm.

Algorithm for changing PDT’s status to ‘In Work’

State: Approved
Main scenario

If PDT’s status = ‘Created’ or ‘Ready’, System:
1. Sets User = <current user>
2. Sets Status = ‘In Work’
3. Recalculates Shipper’s number

System Requirements

It is well known that Programs = Algorithms + Data Structures. Thus, by and large, all that a programmer needs to know are the data structures and the algorithms that manipulate them.

Every object type description consisted of the following parts:

Object type definition from the glossary
Object type properties
Object type operations and their permissions
Data related to this object type
Additional information

Let’s start from the second bullet since definitions were already discussed in the ‘Glossary’ section.

To describe object types, we used tables because they help to organize information, more visual, and easily extensible.

Name	The object type name used by end users and project team members. For example: “I changed the bill number” — Number is a property of Bill. Throughout the documentation, we used references to object type properties as “`Object Type.Property`”.
Data Type	We used the following data types: `Datetime`, `Date`, `Time`, `GUID`, `String`, `Enum`, `Integer`, `Money`, `BLOB`, `Array()`, `Float`, `Timezone`, `TimeSpan`. Each data type had a reflection on all system levels: in the database as a DB field’s type, on the application server as a type of C# programming language, and in the UI where there were several types of controls associated with each data type so that we could use, for instance, a dropdown or a combobox for `Enum`s. Each type had a definition so that programmers knew what to implement. For example, `Money` was defined in this way: includes two parts — a positive or negative float number accurate to the 4^th decimal place, and a currency, the Russian ruble by default.
Editable	Yes or No depending on whether users can change an object type property value in the `Edit` operation. If `No`, this restriction was implemented on the application server and in the UI.
Nullable	Yes or No depending on whether the property can have no value. For example, in our system, Boolean properties must have one of two possible values, but `String` properties have `NULL` by default. If `No`, this restriction was implemented on the database level and on the application server.
Unique	Yes or No depending on whether a property value is unique. Often, uniqueness was defined for a set of properties in this case `Yes+` was set for all of these properties. This restriction was implemented on the database level as a database index and on the application server.
Comment	The property description: what it means, what it is for, how it is used. If the property value is calculated, the comment refers to the calculation algorithm.

In addition to these attributes, the table included two more columns that were filled by server-side programmers when they had implemented the object type:

The object type property name in the code
The database field name

Both of these attributes are optional, because, for example, the property of an object type may not be stored in the database but be calculated like a bill amount.

Here is the typical object type description in our system:

The description of the PDT status Enum was also here:

Value	Description	Sort order	Active	XEnums.PrintTaskStatus
Created	Initial status	1	1	Created
In Work	Somebody is working on the PDT	2	1	InProgress
Ready	PDT is finished	3	1	Ready

Here is a table of possible PDT’s transitions between statuses, and corresponding operations:

Source status Target status	Created	In Work	Ready
Created	—	To Work	—
In Work	Cancel	—	To Ready
Ready	—	To Work	—

As you see, the PDT object type is simple, for complex cases, we created more sophisticated diagrams.

Also, we had the Additional information section with relations between the object type and the legacy system that we migrated from.

Tasks for Developers

Now, after I explained how our requirements were written, let me describe how we formulated tasks for server-side programmers.

Standard Task #1

Title: Implement the object type <object type name>

Description: The link to the wiki page with the object type’s system requirements

A programmer should do the following:

Create database objects (tables, primary and foreign keys, triggers, etc.)
Implement the domain object (as well as internal application server classes like a repository, service, etc.)
Write the code to populate the database with initial data

Everything above can be done based on the link provided. The programmer should update the object type’s property table by providing database table field names and object type property API names.

Standard Task #2

Title: Implement operations and necessary permissions of the object type <object type name>

Description: The link to the wiki page with the object type’s system requirements

On the wiki page, a programmer can find the operation’s names, permissions and in the Comment column necessary to implement algorithms and checks.

Standard Task #3

Title: Change the object type <object type name> and its operations

We created tasks of this type if we had changed this object type’s requirements. The task description included the description of the changes or just a link to a version comparison page.

The Tool to Manage Requirements

It was Atlassian Confluence that helped us to successfully implement requirement development and management. In this last section, I want to point out several of its important advantages:

Possibility of remote work
Links. As you saw above, links allowed us to have different pieces of the requirements on different pages and at the same time, they were connected to each other and together formed the single document.
Notifications when something is changed. This is one of the most important instruments for team work. For example, having received such a notification the project manager can create tasks for developers and test engineers know that it is necessary to update checklists.
Comments. Many of our pages had a big number of comments. It is very convenient to work with comments in Confluence because it supports threads. Also, you can use its rich text editor to highlight something in your comment.
The powerful rich text editor.
Page history, ability to compare different versions, rollback to an old version.
Ability to view and reorganize pages in the tree hierarchy.

Of course, we also ran into several problems:

As soon as the whole documentation uses the same names of object types and their properties, it would be very useful to have a tool to automatically change the changed name across all the pages.
No statistics. For example, every page had a status. But we couldn’t automatically collect statuses of all pages and have a picture of the current requirement development state.
We had to create complex diagrams in another application, save them in PNG format and add them to a Confluence page. Besides that, it was necessary to attach the source file for further modifications.
I failed to find a way to export a page hierarchy to MS Word. Export to XML and PDF had glitches. I hope Atlassian has already fixed these issues.
It is not possible to collapse comment threads. This becomes necessary when you want to somehow hide a thread with a big number of comments because the discussion is already finished.

History

5^th May, 2020: Initial version

This member has not yet provided a Biography. Assume it’s interesting and varied, and probably something to do with programming.

Источник

Как писать функциональные требования +8

Управление разработкой, Управление проектами, Управление продуктом, Блог компании Retail Rocket

Рекомендация: подборка платных и бесплатных курсов таргетированной рекламе — https://katalog-kursov.ru/

Привет, Хабр!

Функциональные требования: что это такое и зачем они нужны

Для начала давайте разберемся, что такое функциональные требования.

Функциональные требования, как правило, состоят из:

User story — показывает, чего вы ожидаете от команды разработки
Use cases — показывают сценарии использования фичи
Wireframes — средство визуализации своей идеи

Сегодня мы сосредоточимся на User story и Use cases.

User story

Как правило используется шаблон:

As a/an <Название роли>, I want to <Цель, Действие>, so that <Ожидаемый результат>, to do <Что нужно сделать разработчику>

Существуют различные примеры применения этой методологии. Например, так это работает в Trello:

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Use cases

Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.

Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

Задачи пользователя:

Загружать изображения
Вставлять изображения в шаблон письма
Удалять изображения

Для каждой задачи нужно написать свой use case — описание того, как пользователь взаимодействует с интерфейсом.

Примеры use case’ов:

Загрузка изображений:

Email-маркетолог заходит в свой личный кабинет Retail Rocket
Email-маркетолог открывает раздел «Галерея»
Email-маркетолог загружает изображения через drag&drop или с помощью клика по кнопке «Выбрать файлы»
Изображения загружаются
Пользователь видит уведомление об успешной загрузке изображений

Удаление изображений:

Пользователь кликает на изображение
Изображение выделяется
Выделение можно снять при помощи клика на область за пределами выделенного изображения
Пользователь нажимает на иконку «три точки»
Появляется контекстное меню
Пользователь выбирает в нем ссылку «Удалить файл». Если было выделено несколько изображений, то удалятся все
Изображение удаляется

Почему функциональные требования так важны

нужно ли удаление файла вообще?
будет ли это ручное удаление или автоматически стираются самые старые файлы при загрузке новых, если превышен лимит пространства для хранения?
удаление происходит из списка файлов или нужно открыть файл?
файл удаляется навсегда или есть корзина для файлов, где они хранятся какое-то время? если нужна корзина, то сколько файлы в ней хранятся?
должно ли быть пакетное удаление файлов или можно удалять только одному?
файл удаляется с помощью отдельной иконки (как выглядит эта иконка?) или через пункт меню (как он будет называться? на каком месте в списке действий расположен?)
и т.д.

А как вы подходите к постановке задач разработчикам?

Директор по продукту Гульфия Курмангалеева

Источник

Анна Вичугова | Анна Гасраталиева

Алгоритм описания функциональных требований к системе в формате Use Case

Существуют разные формы представления функциональных требований: пользовательская история (user story), каноническая форма с привязкой к CRUDL-операциям и модели данных (классический формат описания требований), а также описание сценариев использования (Use Case).

Use Case до сих пор является одной из самых популярных форм представления функциональных требований как среди российских компаний, так и за рубежом. Поэтому именно о них и пойдет речь в нашей статье.

В официальной литературе на русский язык Use Case принято переводить как вариант использования (сокращённо ВИ), хотя в разговорной речи и проектных документах достаточно часто употребляется ещё и транслитерация термина Use Case, то есть говорят и пишут юскейс.

В связке с понятием варианта использования идёт термин Use case scenario, который переводится как сценарий варианта использования или пользовательский сценарий.

Технически, разница есть, то есть Use case это не тоже самое, что Use case scenario. Например, «Купить Товар» — Use case, и у него есть Use case scenario (пошаговое описание того, как именно купить товар: 1. Выбрать товар, 2. Добавить в корзину, 3. Оплатить).

Однако в литературе и документации вы достаточно часто будете сталкиваться с тем, что и пошаговый сценарий тоже называют юскейсом. Так происходит потому, что сам по себе, без описания сценария, юскейс, как правило, мало кого интересует.

В этой статье мы будем придерживаться термина UC, иногда заменяя его на другие, чтобы упростить восприятие статьи читателем.

Итак, Use case (UC) — это популярная форма представления функциональных требований к ПО в виде пошагового сценария взаимодействия актора (пользователя или внешнего сервиса) с проектируемой системой, включая описание метаданных этого взаимодействия: области применения, предусловия, триггеры, постусловия, релевантные бизнес-правила и пр.

Давайте рассмотрим на примере, как описать UC и избежать ошибок в работе с этим методом.

Воркшоп «Use Case: основы»

Воркшоп будет полезен начинающим системным аналитикам, которые хотят:

научиться писать Use Cases,
строить диаграмму сценариев использования,
формировать пакеты и реестр Use Cases,
не допускать типичных ошибок.

Алгоритм описания функциональных требований к системе

Типовую последовательность разработки функциональных требований в форме UC можно представить следующим образом:

Определить Акторов — тех, кто взаимодействует с системой
Выявить и составить список UC — задач, которые стейкхолдеры смогут решить с помощью системы
Для каждого юскейса определить приоритет — важность UC по отношению к другим вариантам использования
Для каждого важного юскейса определить контекст применения, конечную цель и результат
Описать основной поток каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
Дополнить основной поток расширениями, исключениями и циклами
Собрать воедино результаты шагов 4−6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой

Теперь давайте рассмотрим каждый шаг поподробнее.

1. Определить акторов, которые взаимодействуют с системой

Актором может быть несколько разных пользовательских ролей и/или внешние сервисы, которые будут интегрироваться с проектируемой системой, то есть получать из неё данные или вносить их в неё.

Например, если рассматривать мобильный телефон как систему, то актором будет человек — пользователь мобильного телефона. Результат этого шага можно оформить в виде таблицы или диаграммы ролей.

2. Для каждого актора составить список задач, которые он сможет решить с помощью системы

Мы советуем делать это в виде реестра юскейсов — единой таблицы, показывающей распределение юскейсов по акторам.

Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.

Из названия вариант использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее.

Для повышения наглядности можно сделать это в табличном виде или UML-диаграммы вариантов использования (она же Use case diagram, диаграмма прецедентов).

Обычно для продуктов и проектов в сфере B2C исходные данные для этого извлекаются из изучения интересов, потребностей и пользовательского опыта людей (клиентов, экспертов предметной области) и конкурентного анализа, а также CJM-карты.

Для B2B-продуктов и проектов исходными данными для юскейсов, как правило, являются отраслевые и корпоративные регламенты, описание бизнес-процессов и запросы стейкхолдеров.

Давайте сформируем реестр юскейсов. Например, ранее для пользователя мобильного телефона мы определи функциональные возможности «Сделать звоноки» и «Отправить СМС». Они реализуют единую пользовательскую потребность: «Связаться с другим человеком», поэтому их можно объединить в один юскейс.

Юскейсы «Поиграть в казуальную Игру» и «Посмотреть фотографии» относятся к потребности «Скоротать время».

Таким образом, для данного примера с мобильным телефоном реестр юскейсов может выглядеть следующим образом:

3. Для каждого UC определить его приоритет

Реализация юскейсов в коде — трудоёмкая работа, поэтому надо понимать, с каких лучше начать в первую очередь, а до каких очередь может не дойти никогда.

Реестр юскейсов может использоваться для приоритизации пользовательских функциональных требований с целью их ранжирования по степени важности, которая определяет порядок реализации.

Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW. Он получил своё название не в честь российской столицы, а как сокращение следующих 4 категорий:

Must — то, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям. Чаще всего этот приоритет называется 1-я очередь и обозначается цифрой 1
Should — требования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must. Это приоритет номер 2
Could — желательные требования, которые можно сделать, если останется время и будут ресурсы. Это приоритет номер 3
Would — требования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта. Это приоритет номер 4

В нашем примере с мобильным телефоном приоритизировать юскейсы можно так, как показано в таблице 2.

Справедливости ради стоит отметить, что метод MoSCoW в качестве базиса приоритизации выбирает менеджерскую точку зрения, то есть не учитывает технические зависимости между требованиями, которые определяются при трассировке требований, то есть. их связей друг с другом.

Впрочем, тема трассировки и приоритизации требований достаточно обширна и заслуживает отдельной статьи.

4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат

Это можно оформить в виде списка или таблицы, например в Notion:

5. Раскрыть содержание основного потока каждого юскейса высокого приоритета в виде пользовательского сценария

Напомним, что пользовательский сценарий — это последовательность шагов, которая приведёт к достижению конечной цели юскейса, получению нужного актору результата.

Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.

Как может выглядеть черновик сценария основного потока юскейса:

1. Пользователь даёт команду совершить звонок
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь сообщает номер абонента
4. Система убеждается в корректности указанного номера телефона
5. Система вызывает абонента с указанным номером телефона
6. Система убеждается, что звонок начался
7. Система передаёт голос собеседников в ходе разговора

Для наглядности можно нарисовать эту линейную последовательность шагов в виде простого процесса в нотациях EPC, BPMN (рис.1), UML activity или sequence, а также блок-схемы алгоритма по ГОСТ 19.701−90.

Последовательность шагов в виде BPMN-диаграммы

Воркшоп «BPMN для людей:

основы самой популярной нотации

для описания бизнес-процессов»

Воркшоп для ИТ-специалистов, которые хотят научиться описывать логику выполнения бизнес-процессов с помощью формальной нотации — BPMN. Читателями таких диаграмм будут люди, а не сервисы.

На практике подавляющая часть сценариев описывается только текстовым описанием. Пример такого описания мы разберём с вами ниже.

6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами

На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.

Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).

Расширенная BPMN-диаграмма юскейса с исключениями и альтернативными потоками

7. Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой

На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:

Имя
Приоритет
Область действия
Контекст
Актор
Цель
Предусловия
Результат (постусловие)
Основной поток
Расширения или альтернативные потоки
Бизнес-правила

Давайте разберем каждый элемент этой структуры поподробнее.

Эту структуру можно представить в текстовом виде или, для наглядности, в виде таблицы. Давайте завершим описание этого юскейса так, как мы делаем это на реальных проектах, то есть полностью опишем happy path и альтернативные сценарии.

Пример 1. UC «Сделать Звонок»

При описании юскейсов на реальном проекте мы рекомендуем в первую очередь учитывать текущие нужды и предпочтения ваших стейкхолдеров (заказчика, разработчиков, тестировщиков и так далее).

Главная задача любого юскейса состоит в том, чтобы создать общее понимание взаимодействия у пользователя системы, у заказчика и у всей проектной команды. Поэтому зацикливаться на «правильном» формате будет неэффективно, гораздо лучше ориентироваться на нужды потребителей вашей документации, а значит, нужно поговорить с ними, показать наработки и согласовать удобный всем формат.

Как структурировать UC из набора
исходных ФТ

Задача:
Рассмотрим пример информационной системы, которая позволяет клиенту выбрать один или несколько обучающих курсов, заключить договор на участие в них и оплатить сумму через онлайн-оплату.

Если у клиента есть промо-код на скидку по конкретному курсу, сумма в договоре будет снижена на размер скидки.

Таким образом, мы имеем следующий базовый, стартовый набор функциональных требований к информационной системе управления договорами на обучение:

FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора
FRQ4 Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключенному договору через шлюз онлайн-оплаты
FRQ5 Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку

Формируем описание в формате UC, применяя алгоритм:

Шаг 1. Определяем акторов. Судя по требованиям, с системой взаимодействует клиент и шлюз оплаты.

Шаг 2. Сформируем реестр юскейсов. Для этого мы можем, например, представить имеющийся набор функциональных требований в виде UML-диаграммы вариантов использования (UML Use case diagram).

Исходная UML-диаграмма use case

Чтобы составить реестр юскейсов, давайте выделим из ранее представленных юскейсов именно те, что имеют бизнес-ценность для пользователя без привязки к системе.

Упрощённая UML-диаграмма use case

Давайте также сопоставим получившиеся юскейсы и функциональные требования в таблице ниже.

При формировании реестра юскейсов для пользователя мобильного телефона мы можем выделить такие функциональные возможности как «Сделать Звонок» и «Отправить СМС». Оба этих юскейса отражают непосредственное взаимодействие актора с системой, направленное на достижение определённой бизнес-цели, это системный юскейс.

Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.

Реестр вариантов использования:

Шаг 3. Определить приоритеты системных юскейсов

Поскольку юскейсы в рассматриваемой части системы тесно связаны между собой, ранее рассмотренный метод приоритизации MoSCow не совсем подходит для этого случая. Здесь целесообразнее расставить приоритеты с точки зрения технических зависимостей данных юскейсов между собой: сперва должны быть реализованы требования относительно возможности заключить договор, чтобы потом проводить оплату по заключённому договору.

Шаги 4−7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см. ниже). По аналогии будет описан и UC «Заключить Договор».

Пример 2. UC «Оплатить Договор»

Для нашего примера вариант использования «Оплатить Договор» может выглядеть так:

У нас получилось представление варианта использования в виде подробного описания взаимодействия актора с проектируемой системой по заданному шаблону, включая последовательность шагов основного потока, приводящего к достижению пользовательской цели в заданном бизнес-контексте, альтернативные поток, пред- и постусловия.

Такой формат хорошо подходит для реализации, если в юскейсе описана конкретная привязка к модели данных, указаны сущности и атрибуты, над которыми выполняются операции.

Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.

Кроме того, у нас получилось слишком много шагов в юскейсе, что является сигналом к его разделению на несколько. В данном случае можно было бы, например, вынести в отдельный юскейс работу с промо-кодами.

Пример 3. UC «Обновить Анкету»

Достоинства и недостатки UC как формы представления требований

Основными преимуществами UC являются следующие:

Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ;
Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось

Обратной стороной этих достоинств являются следующие недостатки:

Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
На детальную проработку каждого UC уходит много времени. Например, у меня это занимает в среднем от 30 минут; добиться существенного повышения скорости работы можно за счёт повторного использования типовых юскейсов (опытный аналитик или отдел могут создать библиотеку своих юскейсов)
Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)

Откуда взялся такой формат как Use Case

Разумеется, не мы изобрели юскейсы как формат описания требований. Существуют общепризнанные мировые эксперты в этой области, а также книги-первоисточники, к которым стоит обращаться в случае возникновения споров и недопонимания. Скажем о них пару слов, чтобы вы знали, куда обратиться при необходимости.

Исторически функциональные требования, представляющие поведение системы, описывались в виде отдельных функций. Например, так:

FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору

В 1986 году Ивар Якобсон (шведский учёный, который вместе с Гради Бучем и Джеймсом Рамбо стоял у истоков ООП и UML) предложил альтернативную форму представления функциональных возможностей системы. Вместо описания функциональных требований к системе в виде отдельных функций Якобсон предложил объединить их по контексту, а затем превратить в набор вариантов использования (ВИ), который будет обеспечивать полноту и неизбыточность требований.

Якобсон обнаружил, что отдельные системные ФТ обычно не представляют большой самостоятельной ценности для заказчика, менеджера, пользователя, так как являются слишком мелкими единицами функциональности. Подход Якобсона позволил вместо сотен-тысяч системных функций применять единицы-десятки юскейсов, что гораздо удобнее в целях управления, планирования и сдачи ИТ-продукта/системы. Кроме того, он хорошо стыкуется с задачами тестирования и создания пользовательской документации. Подробнее об этом см в статье.

В 2001 году Алистер Коберн, эксперт в разработке ПО, расширил и уточнил идеи Якобсона, выпустив книгу «Современные методы описания функциональных требований к системам» (Writing Effective Use Cases). Книга получилась достаточно подробной, содержащей множество примеров. Помимо техник описания самих UC, работа Коберна включает также связанные вопросы о контексте, границах и основных компонентах проектируемой системы, то есть так называемый scope системы.

Эти и другие аспекты работы с требованиями были изложены в книге ещё одного автора, широко известного в системном и бизнес-анализе. В 2003 году Карл Вигерс (Karl Wiegers) написал 2-е издание своей книги «Разработка требований к программному обеспечению» (Software Requirements), где рассмотрены не только техники разработки требований, но и вопросы управления ими, включая сбор, документирование, трассировку, работу с изменениями и анализ рисков. Эта книга почти вдвое объёмнее труда Коберна и больше подходит для начинающих аналитиков.

UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: ЧТО система должна сделать, чтобы актор достиг своей цели, а НЕ КАК это должно быть сделано.

Благодаря отсутствию привязки к элементам пользовательского интерфейса, ВИ становятся повторно используемыми требованиями, которые остаются актуальными при изменении платформы или других особенностей реализации.

Несмотря на повсеместное распространение гибких методологий разработки ПО, UC как подход к описанию функциональных требований очень активно применяется на практике. В отличие от пользовательских историй (User Story), другой популярной формы представления требований, UC охотно принимают в реализацию — в основном благодаря структурированному формату и детальной проработке бизнес-логики с привязкой к модели данных.

Полный реестр UC и структурированное описание каждого из них позволяет разработчикам воплотить описанные структуры данных и алгоритмы их обработки. Таким образом, большая трудоемкость при разработке вариантов использования на этапе анализа и спецификации требований окупается сокращением времени на этапе реализации и тестирования. Кроме того, реестр юскейсов можно использовать для оценки трудоёмкости проекта — менеджеры проектов часто приходят к аналитикам и тимлидам с этим вопросом.

В завершение статьи хотелось бы напомнить: если ваш юскейс решает проблемы разработки ПО, то есть создаёт общее понимание требований у заказчика и всей проектной команды, то вы написали хороший юскейс. Следование формату само по себе не самоценно.

Воркшоп «Use Case: основы»

Воркшоп будет полезен начинающим системным аналитикам, которые хотят:

научиться писать Use Cases,
строить диаграмму сценариев использования,
формировать пакеты и реестр Use Cases,
не допускать типичных ошибок.

Анна Вичугова

Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
Сертифицированный специалист и администратор СЭД Directum (2011

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

Анна Гасраталиева

Системный аналитик, выпускающий редактор Systems. Education

Профессиональные интересы: телекоммуникации, интеграции, управление задачами, управление людьми, обучения

Источник

Чтобы составить Техническое Задание на разработку ПО, вам необходимо определить, какие задачи стоят перед вашим интернет-магазином или маркетплейсом, и каким образом будет организовано взаимодействие с посетителями. Чтобы получить такое понимание, нужно учесть интересы целевой аудитории и тех, кто будет работать с сайтом внутри компании. Другими словами, потребуется оформить требования.

Функциональные и бизнес-требования, закрепленные в документе, помогают лучше оценить сроки выполнения работ и бюджет, а также избежать необходимости исправлять ошибки в случае недопонимания между заказчиком работ и разработчиком. Давайте рассмотрим, что представляют собой функциональные и бизнес-требования, как правильно их оформлять, и как передавать исполнителю работ.

Что такое бизнес-требования

Бизнес-требования представляют собой обобщенные задачи ко всему проекту. Их нужно писать понятно для руководителей и других заинтересованных лиц компании, которые не знают всей специфики веб-разработки.

Что входит в бизнес-требования

Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
Анализ конкурентов
Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах) . Ускорить обработку заказов через автоматизацию работы менеджеров.
Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 0,8% до 1,1%. Втрое увеличить количество вендоров. Поднять прямые онлайн-продажи без похода в магазин на 30% за полгода.
Пользовательские требования, то есть какую задачу должен решить пользователь на сайте. Купить шампунь, если речь идет о покупателе на сайте. Организовать доставку в другую страну, если пользователь — другая компания. Увеличить заработок для вендора. Иметь доступ только к заказам для менеджера по продажам и так далее.

Как бизнес-требования влияют на итоговый продукт?

Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

Требование А. Чтобы привлечь вендоров, владелец маркетплейса может предложить продавцам продолжать работать в собственных системах, интегрировав эти системы в маркетплейс. Вендорам не придется изучать интерфейс новой для себя системы, а владелец будет иметь все необходимые данные на своей платформе. Таким образом, способом реализации продукта станет интеграция с сервисами вендора по API.
Требование Б. По условию франшизы за определённой территорией может быть закреплен только один продавец / территориальный представитель, который будет работать с заказами покупателей из данного региона. Продажа товаров на данной территории другими представителями бренда запрещена по условиям договора. Способ реализации: определение геолокации покупателя, сортировка товаров и отображение актуальных остатков для конкретной локации, привязка покупателя к продавцу для дальнейших заказов.
Требование В. Владелец сайта-каталога (где можно просматривать товары, но нельзя покупать их) хочет создать интернет-магазин без перехода на новую платформу. В связи с этим, требуется внедрить функционал оформления заказа из платформы CS-Cart таким образом, чтобы для покупателя это выглядело «бесшовно», как будто он и не покидал существующий сайт. Способ реализации: интеграция технологии единого входа — SSO — при которой пользователь переходит из одной системы в другую без повторной аутентификации.

Почему нужно конкретно и четко оформить бизнес-требования?

Четкое формулирование бизнес-требований:

Позволяет управлять ожиданиями. Исполнитель узнает об ожиданиях клиента и может предложить лучшее решение
Помогает точнее выполнить оценку объема работ
Экономит время исполнителя и заказчика на процесс сбора требований

Вы можете использовать следующие уточняющие вопросы, помогающие и заказчику, и исполнителю структурировать информацию.

Опишите ваш продукт / услугу. Что будет являться товаром? Какие его характеристики? Как будет считаться его стоимость?
Роли пользователей (администратор, продавец покупатель) и какие действия может выполнять каждый из них? Есть ли какие-либо зависимости / ограничения?
CJM (путь покупателя по сайту) : какими будут действия покупателя по приобретению вашего продукта? Какие соответствующие действия должен будет выполнять продавец / администратор?
Регистрация пользователей: какие данные должны предоставить пользователи для регистрации?
Как будет выглядеть личный кабинет (профиль) покупателя для пользования услугой? Какие действия он сможет выполнять?
Понадобится ли интеграция со сторонними системами? Какими?

Итак, бизнес-требования – это общие задачи, решаемые сайтом. После сбора бизнес-требований идет этап определения функциональных требований.

Что такое функциональные требования?

Примеры функциональных требований:

Вендор регистрируется в системе: система регистрирует данные вендора на входе и на выходе отображает их на странице всех вендоров.
Присвоение уникального номера заказу: система обрабатывает заявки на заказы. Приходит заказ, система присваивает ему номер и на выходе выдает список заказов.
Расчет доставки: система по API запрашивает данные у сервиса доставки и выдает рассчитанную стоимость доставки на странице заказа.
Поддержка мобильных кошельков: в странах Среднего Востока и Северной Африки система принимает оплату с мобильного телефона.

Нефункциональные требования. Важные особенности

Помимо функциональных, существуют нефункциональные требования. К ним относят дополнительные признаки сайта, необходимые для его устойчивой работы. Нефункциональные требования не имеют отношение к основному функционалу. Это правила и ограничения, предъявляемые ко всей системе или продукту.

Нефункциональных требований очень много. Вот некоторые из них.

Дизайн, UX/UI. Добавить дополнительную кнопку на чекауте. При переходе на страницу продукта пользователь видит все вариации продукта.

Требования к коду: cделать модификацию на JS, работа в репозитории клиента, использовать указанные заказчиком библиотеки при реализации модификации.

Настройка процессов непрерывной доставки и улучшения кода. CI и CD процессы призваны автоматизировать проверку и доставку разработанного ПО заинтересованным лицам.

Адаптация готовых решений. Вы можете выбрать готовые модули на маркетплейсе и с его помощью быстро закрыть какое-то функциональное требование, например, с помощью модуля Google Analytics Enhanced Ecommerce следить за событиями покупки на сайте прямо в админке платформы. Но бывают случаи, когда модули приходится дорабатывать под нужды конкретного проекта.

Контент. На продуктовые страницы добавить ссылки на юридические документы. Такое требование часто озвучивают владельцы немецких маркетплейсов.

Производительность сайта. Магазин должен выдерживать нагрузку в 1000 посетителей онлайн одновременно.

Кто собирает требования?

Сбором первичных требований занимается менеджер отдела продаж. К этому процессу, могут также подключаться:

✔ Стороннее агентство, нанятое заказчиком

✔ Штатный аналитик заказчика

✔ Наша команда в рамках услуги “Проектирование”

Как происходит сбор требований?

Обычно сбор требований происходит через интервью, переписку или в специальных системах типа Notion, Trello и т. д. Приведем алгоритм сбора требований:

Предоставление общих требований к продукту или брифование для составления MVP.
Если запрос описан четко и конкретно, менеджер обсуждает требования с техническим экспертом.
Дается грубая оценка реализации.
Если нужны уточнения, используются уточняющие вопросы, проводится дооценка сроков и стоимости работ.

Кто участвует в сборе требований?

В зависимости от потребностей проекта, можно и нужно привлекать следующих заинтересованных лиц:

Вендоры и отдел привлечения вендоров (для маркетплейсов)
Бухгалтерия (чтобы понимать, какие отчеты нужны, как проводить платежи)
Юридический отдел (если есть юридические ограничения, которые нужно учесть при создании интернет-магазина) .
Маркетинг (для реализации механики промо акций)
IT-отдел (при наличии, поскольку ему придется поддерживать готовую систему после сдачи работ)
Специалисты по безопасности
Сторонние эксперты

Вспомогательные материалы, предоставляемые заказчиком

Дополнительные материалы помогают исполнителю лучше понимать процесс принятия решений в компании и организовать работу наиболее эффективным образом. К таким материалам можно отнести:

Примеры конкурентов и реализации желаемого функционала
Блок-схема с описанием бизнес-процессов, функциональности
CJM-карта
Архитектурная диаграмма
Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя)
Дизайн-макеты
План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т. п.
Список ролей участников проекта и схема принятия решения
User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя) .

Какие ошибки допускают заказчики в ходе сбора информации?

Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor) , но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart) . До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который плохо выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.

Насколько детализированными должны быть требования?

Важно соблюдать баланс между подробностью и избыточностью. Если требования слишком детализированные, лучше сообщить исполнителю бизнес-цель и примерное видение. Так разработчик сможет подобрать подходящий вариант реализации.

Пример 1. Форма для регистрации интуитивно понятна.

Как нужно: Форма для регистрации имеет два поля: ФИО и телефон. Также, необходимо обеспечить посетителю возможность входа через социальные сети.

Пример 2. Магазин не должен тормозить.

Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.

Выводы

Завершите сбор требований до формирования спецификации на разработку магазина. Так вы вложите меньше усилий и средств и уменьшите время создания разработки.
Ставьте задачи конкретно. Так вероятность создания магазина, выполняющего все возложенные на него задачи, выше. Всегда дополняйте конкретные функциональные обобщенными бизнес-требованиями. Так, совместно с разработчиком, вы сможете выработать оптимальный путь решения задачи
Участвуйте в сборе требований. Только заказчик имеет глубокое представление о специфике своего бизнеса. В случае с некрупной организацией, имеет смысл нанять сторонних специалистов или обратиться к команде разработчика. Какой бы путь ни был выбран, принимайте активное и непосредственное участие на всех этапах. Так вы гарантируете, что все особенности бизнеса будут учтены.

Источник

Как писать функциональные требования

Функциональные требования: что это такое и зачем они нужны

User story

Use cases

Почему функциональные требования так важны

Что такое функциональные требования: примеры, определение, полное руководство

Что такое функциональные требования?

Типы функциональных требований

Создание функциональных требований:

Примеры:

Чем функциональные требования отличаются от нефункциональных требований?

Вывод:

Introduction

About Our Project

Glossary

Business Roles

Levels of Requirements

Business Requirements

General Scenarios

Use Cases

Algorithms and Checks

System Requirements

Tasks for Developers

Standard Task #1

Standard Task #2

Standard Task #3

The Tool to Manage Requirements

History

Introduction

About Our Project

Glossary

Business Roles

Levels of Requirements

Business Requirements

General Scenarios

Use Cases

Algorithms and Checks

System Requirements

Tasks for Developers

Standard Task #1

Standard Task #2

Standard Task #3

The Tool to Manage Requirements

History

Как писать функциональные требования +8

Функциональные требования: что это такое и зачем они нужны

User story

Use cases

Почему функциональные требования так важны

Что такое бизнес-требования

Что входит в бизнес-требования

Как бизнес-требования влияют на итоговый продукт?

Почему нужно конкретно и четко оформить бизнес-требования?

Что такое функциональные требования?

Примеры функциональных требований:

Нефункциональные требования. Важные особенности

Кто собирает требования?

Как происходит сбор требований?

Кто участвует в сборе требований?

Вспомогательные материалы, предоставляемые заказчиком

Какие ошибки допускают заказчики в ходе сбора информации?

Насколько детализированными должны быть требования?

Рекомендации заказчику, пишущему требования

Выводы