Требования к ПО на пальцах
Время на прочтение
5 мин
Количество просмотров 75K
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
- Зачем нам что-то делать? (нужно больше золота)
- Что мы будем делать? (все как у людей, но дешевле)
- Как мы это сделаем? (с блокчейном и датасаентистами, естественно)
- Когда мы это сделаем? (вчера, а отрефакторим «потом»)
А теперь подробнее.
Если вы когда-либо просили что-то сделать — значит вы создавали требования. Они могли быть в форме устного пожелания, письма, технического задания, таски или чего угодно.
Так что требования — они повсюду.
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP!!!!” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Например
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Например
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Например
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
Например
- Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов — это бизнес-требование. А возможно, и бизнес-правило.
- Из бизнес-требования следует, что у пользователя должна быть возможность прикрепить фото к анкете — это пользовательское требование. То есть требование, описывающее действия пользователя.
- Получается, что система должна иметь функционал прикрепления фото к анкете — это уже функциональное требование, описывающее поведение системы. Или как должна работать система, чтобы выполнять исходное пользовательское требование.
- Будем хранить все фото в формате base64 в отдельной таблице в БД. Это — нефункциональные требования.
- Фото в очень хорошем качестве нам не нужно, а также мы не хотим покупать много памяти для сервера. Поэтому сделаем ограничение на размер загружаемого фото: не более 10Мб.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Спасибо за внимание и удачного проектирования.
Фундаментальное описание требований к ПО и подходов к их выявлению и сбору от тестировщика Noveo Вадима: пост освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «темным» местам. Приятного прочтения!
Вадим
Noveo Test Engineer
Мы с вами как тестировщики каждый день работаем с требованиями. Суть нашей работы — выяснять, соответствует ли разрабатываемая система требованиям заказчика, рынка и отраслевым стандартам. Более того, в наши обязанности входит проверка требований на соответствие критериям качества. В идеальном мире мы с вами были бы просто гарантом качества — судьями, дающими объективную оценку. Но, к сожалению, мир не идеален, и строгое распределение участников проекта на роли чаще всего не представляется возможным. В эпоху повсеместного использования гибких методологий разработки мы с вами должны обладать знаниями, позволяющими выполнять задачи не только контроля качества.
Цели этого поста заключаются в следующем:
- Определить, что такое требование, какие типы и уровни требований выделяют.
- Понять, какие существуют методы сбора и выявления требований.
- Предоставить почву для дальнейшего изучения сферы системного и бизнес-анализа.
Требования
Начнем с требований как таковых:
- Что они из себя представляют?
- Какие виды требований выделяются?
- Как они согласуются?
- Какие источники требований можно выделить?
Определение требования
Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?
Вопрос, что считать требованием к ПО, является сугубо дискуссионным. Но так или иначе нам с вами необходима отправная точка для изучения темы, поэтому обратимся к уже устоявшимся определениям:
Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).
Требования к ПО — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований (Википедия).
Из определений можно выделить следующие пункты, которые относятся к требованиям:
- Спецификация — документ, устанавливающий требования.
- Реализация — интерпретация требований в виде разработанной системы (одни и те же требования можно реализовать различными способами).
- Описание поведения системы (то, как система должна работать при различных входных условиях).
- Описание свойств / атрибутов / качеств системы.
Как видно выше, устоявшиеся термины не отражают всю полноту понятия «требование к ПО», поэтому также стоит отметить следующее: требования охватывают как видение пользователя, так и внешнее поведение системы, а также представление разработчика о некоторых внутренних характеристиках. Они включают как поведение системы в определенных условиях, так и свойства, которые делают систему полезной и удовлетворяющей конечных пользователей.
Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.
Уровни и типы требований
Требования к ПО состоят из трех уровней:
- Бизнес-требования.
- Пользовательские требования.
- Функциональные требования.
Отдельно вне иерархии выделяют нефункциональные требования. Они так или иначе всегда представлены на всех уровнях требований и прямо или косвенно влияют также на все из них. Далее подробнее разберем каждый уровень требований отдельно.
Бизнес-требования BRQ
Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.
Бизнес-требования описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему.
Бизнес-требования — это верхний уровень абстракции требований к системе. Они не относятся напрямую к реализации проекта, а в первую очередь отражают цели бизнеса, абстрагированные от реализации системы. В конечном итоге бизнес-требования формируют документ концепции и границ.
Если кратко, документ содержит определение следующих понятий:
- Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
- Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
- Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
- Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.
Примеры бизнес-требований:
Сократить время обработки заказа на 50% (цель) — система должна предоставить интерфейс, упрощающий создание заказа (концепция).
Увеличить клиентскую конверсию до 35% (цель) — в системе должны быть представлены механизмы побуждения клиента к заказу (концепция).
Говоря о сборе и выявлении требований, нельзя опускать вопрос, в каких источниках искать требования. Под источниками требований подразумевается любой источник информации, используя который мы можем сформулировать требование.
Источники бизнес-требований (где искать?):
- Внутренняя документация компании (положения, инструкции, приказы).
- Документация по предметной области (профильные литература и статьи, исследования).
- Нормативная документация (законы и иные правовые акты, государственные стандарты).
- Продукты конкурентов.
Стейкхолдеры (у кого спрашивать?):
- Инициатор проекта.
- Руководитель проекта (менеджер проекта).
- Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
- Бизнес-аналитик.
P.S. Список стейкхолдеров меняется от проекта к проекту, для каждого проекта необходимо отдельно определять список заинтересованных/ответственных лиц. Списки, представленные мной, являются сугубо примерами из моей практики.
QA и разработчики, как правило, не участвуют в сборе и анализе бизнес-требований. Но нам важно понимать верхнеуровневые цели, которые преследует проект, так как пользовательские и функциональные требования — это следствие выявления, анализа и декомпозиции бизнес-требований. Работая с бизнес-требованиями, вы в первую очередь погружаетесь в предметную область заказчика. На мой взгляд, это очень важно для всех участников проекта. Если член команды погружен в предметную область заказчика, существенное количество вопросов отпадет, а следовательно, сокращается и время, потраченное на коммуникации.
Пользовательские требования URQ
Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).
Пользовательские требования определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе (Википедия).
Пользовательские требования также часто именуются фичами.
Фича (функциональность) — функционально обобщенные части системы, решающие отдельные задачи пользователей или интерпретирующие бизнес-процессы (и их артефакты), которые будут реализованы в рамках системы.
Исходя из вышеописанных определений, пользовательские требования содержат:
- Цели и задачи пользователей.
- Сценарии использования — способ решения задачи пользователей.
- Как следствие, описание самих пользователей системы:
- пользовательские роли,
- уровни доступа.
В конечном итоге пользовательские требования формируют «Документ пользовательских требований». Пользовательские требования могут быть представлены в виде:
- текстового описания,
- вариантов использования, сценариев использования (Use Case),
- пользовательских историй (User Story),
- диаграммы вариантов использования.
Как правило, пользовательские требования описываются по следующему шаблону:
Пользователь должен иметь возможность + {тезис}.
Пример пользовательского требования:
Пользователь должен иметь возможность добавить объект в избранное (функциональность).
Источники пользовательских требований требований (где искать?):
- Анализ и декомпозиция бизнес-требований.
- Описание бизнес-процессов.
- Артефакты бизнес-процессов:
- документы входные/выходные,
- стандарты,
- регламенты,
- обрабатываемые данные,
- иная информация, используемая и/или производимая в бизнес-процессе.
- Отраслевые стандарты.
- Реализованные проекты, проекты конкурентов.
Стейкхолдеры (у кого спрашивать?):
- Бизнес-аналитик, системный-аналитик.
- Конечные пользователи — люди, взаимодействующие с системой напрямую.
- Косвенные пользователи — люди, использующие результаты работы системы, не взаимодействуя с ней напрямую.
- Представители пользователей.
- Менеджер проекта.
- Руководитель структурного подразделения заказчика.
Этот уровень требований напрямую входит в круг обязанностей QA-инженера. В задачи QA на этом уровне входит:
- Определение соответствия описания требований критериям качества.
- Анализ требований для проработки сценариев тестирования.
- При достаточном уровне компетенций в предметной области:
- определение соответствия требований устоявшимся отраслевым стандартам (например: системе не достаёт фичи, которая в рамках предметной области системы является обязательной);
- определение соответствия требований с утвержденными бизнес-требованиями. Ответ на вопрос: «Решает ли пользовательское требование бизнес-цели проекта и задачи пользователей?«.
Функциональные требования FRQ
Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.
Функциональные требования определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований.
Функциональные требования самые низкоуровневые. Являются результатом декомпозиции верхнеуровневых требований и описывают атомарные функции, которые должны быть реализованы в системе.
Пример функциональных требований:
Пользователь должен иметь возможность добавить объект в избранное (URQ):
FRQ 1 — Добавить в избранное.
FRQ 2 — Удалить из избранного.
FRQ 3 — Редактирование дополнительных атрибутов.
FRQ 4 — Обращение к объекту из меню избранного.
Источники требований (где искать?):
- Анализ пользовательских требований.
- Таски.
- Прототипы интерфейса (мокапы).
- Отраслевые стандарты.
- Внешние системы и документация к ним (интеграции).
Стейкхолдеры (у кого спрашивать?):
- Бизнес-Аналитик.
- Системный аналитик.
- Архитектор.
- Менеджер проекта.
- Разработчики.
Нефункциональные требования NFRQ
Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
На мой взгляд, это крайне исчерпывающее определение. Как вы могли заметить, нефункциональные требования не входят в основную иерархию требований. Их выделяют от других типов требований, так как нефункциональные требования:
- Выявляются и формулируются на всех уровнях иерархии требований.
- Напрямую или косвенно влияют на формирование каждого уровня требований.
Совет: Чаще всего нефункциональные требования отвечают на вопрос «Как? Каким образом?».
Пример нефункциональных требований, которые являются основной идеей проекта: Тик Ток.
С точки зрения разработки функциональный скоуп проекта не является уникальным:
- смотреть контент,
- предлагать ротацию контента на основе алгоритмов,
- создавать контент.
Все эти фичи так или иначе были представлены в других проектах. Ключом успеха проекта в данном случае является его UI/UX. А UI/UX сам по себе не отвечает за функции системы, а отвечает за то, каким образом будут реализованы эти функции.
SRS
В конечном итоге все требования консолидируются в одном документе «Спецификации требований к системе». Выше вы можете видеть структуру документа SRS. Ни в коем случае нельзя воспринимать её как жесткий стандарт (хотя таковой имеется: ISO/IEC/IEEE 29148:2011). Я предлагаю вам использовать эту структуру как чек-лист для определения полноты описания системы. Стоит отметить, что внутренние стандарты документирования и полноты требований меняются от проекта к проекту, но набор типов требований всегда будет идентичен. Кто-то опускает бизнес-требования, для кого-то пользовательские требования тождественны функциональным. В конечном итоге все требования — лишь абстракция, и каждая команда подбирает под себя удовлетворительный уровень детализации этой абстракции.
Выявление требований
Выявление требований — итеративный процесс, состоящий из следующих этапов:
- Подготовка к выявлению.
- Выявление.
- Утверждение результатов.
Подготовка к выявлению требований
В процессе подготовки к выявлению требований необходимо ответить на следующие вопросы:
1. Что необходимо выяснить? — Анализируем имеющуюся информацию о системе:
а. Анализ текущего описания требований к системе.
b. Анализ текущей реализации системы.
c. Выявление недостающих и/или недостаточно описанных требований.
2. У кого? Где? — Определить источник требований:
а. Собрать список доступных источников, таких как:.
i. Документация.
ii. Артефакты бизнес-процессов и/или текущей реализации системы.
b. Определить список стейкхолдеров, которые могут выступать источником требований к системе.
3. Каким образом? — Выбрать оптимальный метод выявления требований.
Выявление требований. Интервью
Самый популярный и, возможно, эффективный метод выявления требований. Представляет из себя беседу с заказчиком.
Подготовка к интервью
Подготовка к интервью состоит из следующих этапов:
1. Собрать информацию о собеседнике(ах):
а. Роль в проекте?
b. За какие вопросы ответственен?
2. Подготовить вопросы:
a. Сформулировать проблематику интервью.
b. Сформулировать вопросы.
c. Подготовить дополнительные вопросы.
3. Определить тайминг встречи.
a. Нужно стараться уложиться в один час. Чаще всего человек начинает терять концентрацию после 40 минут непрерывной беседы.
b. Для каждого вопроса определить необходимое время на обсуждение.
c. Если вы не успеете задать все вопросы в рамках одной встречи, назначьте несколько встреч.
4. Согласовать календарь встреч.
a. Если предполагается несколько встреч — то не обходимо составить график встреч.
b. Для каждой встречи указать проблематику, вопросы, которые будут обсуждаться, длительность.
От себя рекомендую подготовить файл с вопросами и планом интервью. Для примера — вот шаблон, который использую я:
Протокол интервью
Проект:{}
Дата проведения:{}
Интервьюер: {Кто проводит интервью}
Интервьюируемый:{Кому задаём вопросы}
Проблематика:{Тема интервью}
Вопрос № 1:
Тайминг вопроса:
Текст вопроса:
Таймкод:
Ответы на вопрос:
Стейкхолдер 1 —
Стейкхолдер 2 —
Проведение Интервью
Проведение интервью — сложный навык, который требует времени и практики. Но просто задавать вопросы, я думаю, будет не сложно. Итак, ниже список рекомендаций, которые помогут вам провести интервью:
1. Всегда ведем запись встречи.
a. Спрашиваем собеседника, не против ли он вести запись разговора.
b. Включаем запись после согласия собеседника.
2. Small talk для разрядки.
a. Как настроение?
b. Как погода?
c. И т.д. и т.п.
d. Но не затягиваем, пара вопросов из вежливости, не более.
3. Начинаем с объявления проблематики.
4. Стараемся следовать плану встречи. Вопросы задаём последовательно.
5. Желательно в плане указываем тайм-код, в какую минуту разговора задан вопрос, чтобы упростить дальнейшую обработку протокола.
6. Стараемся раскрывать вопросы дополнительными вопросами. Беседа должна быть живой, не должна скатываться в сухой формат вопрос-ответ, иначе проще отправить собеседнику опросник и не тратить его время на встречу.
7. В конце обсуждения не лишним будет подтвердить позицию собеседника закрытым типом вопроса.
a. Например: Я правильно вас понял, что необходимо реализовать функционал следующим образом {Тезис}?
Обработка результатов Интервью
После проведения интервью необходимо письменно зафиксировать полученную информацию. Рекомендую делать это сразу после интервью. Итак:
1. Заполняем протокол встречи.
a. Читать краткий протокол встречи намного проще, чем смотреть часовую запись в поисках ответов.
2. Направляем участникам встречи результаты в формате «Вопрос — Зафиксированное решение».
b. Это необходимо для получения от заказчика письменного утверждения результатов встречи.
Плюсы и минусы метода
Плюсы метода:
- Наиболее эффективный способ метод сбора требований.
- Меньшая вероятность недопонимания между собеседниками.
- Большая вероятность выявления «скрытых» требований.
Минусы метода:
- Могут возникнуть сложности согласования требований от разных стейкхолдеров.
- Высокие временные затраты.
- Качество проведения интервью напрямую зависит от интервьюера.
Выявление требований. Анкетирование
Метод анкетирования подразумевает создание анкеты (списка вопросов) и её рассылку большому количеству опрашиваемых.
Подготовка
Подготовка к анкетированию состоит из следующих этапов:
1. Собрать контакты опрашиваемых стейкхолдеров.
2. Подтвердить готовность стейкхолдеров участвовать.
3. Подготовить анкету:
a. Анкета должна содержать вводную. Нельзя заставлять опрашиваемого отвечать на вопросы без контекста. Но если вы уверены, что опрашиваемые погружены в контекст, этот пункт можно сократить до обозначения проблематики (общей темы вопросов).
b. Задавать можно как открытые, так и закрытые вопросы.
c. Но лично я рекомендую предоставлять опрашиваемым варианты ответа даже в формате открытого вопроса. То есть обозначаем проблематику, предлагаем варианты решения, а также оставляем за опрашиваемым возможность раскрыть свою позицию. По сути аналог варианта «Другое» в опроснике.
Проведение
- Рассылаем анкету опрашиваемым.
- Контролируем сроки опроса (должен быть внутренний дедлайн).
- Ответы, по мере поступления, консолидируем в одном документе (каналы связи с опрашиваемыми могут быть разными, но место хранения требований всегда должно быть одно).
Обработка результатов
- Анализируем ответы.
- Фиксируем требования.
- Утверждаем требования с ответственными лицами.
Плюсы и минусы метода
Плюсы:
- Большой охват опрашиваемых.
- Сравнительно небольшие временные затраты.
- Возможность повторного использования анкеты (бриф на стандартизированный проект).
Минусы:
- Не подходит для выявления «неявных» требований.
- Невозможно заранее учесть все необходимые вопросы.
Выявление требований. Мозговой штурм
Мозговой штурм предполагает сбор команды разработки и представителей заказчика на совместную встречу. Этот метод позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно. Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения проблемы. С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований.
Подготовка
1. Формулируем проблематику:
а. Необходима краткая и емкая формулировка, которая оставит поле для размышления экспертов.
b. Проблематика озвучивается экспертам заранее, чтобы у них было время «на подумать».
2. Подготавливаем дополнительные материалы для отработки идей — например, макеты системы.
3. Формируем группу экспертов.
4. Согласовываем дату и время.
Проведение
1. Ведем запись-протокол. Уведомляем участников о том, что ведется запись.
2. Озвучиваем регламент встречи:
a. Тема,
b. Тайминги,
c. Правила.
3. Эксперты озвучивают идеи по очереди.
4. Эксперты должны озвучивать любые идеи, касающиеся проблематики.
5. Каждая идея фиксируется и обсуждается.
6. В некоторых источниках утверждается, что нужен полный запрет на критику. На мой взгляд, это приводит только к сбору сырых идей, без их отработки. «В споре рождается истина».
7. Коллективное комбинирование собранных идей.
Обработка результатов
- Анализируем идеи.
- Формализуем и описываем (то есть готовим развернутое описание).
- Утверждаем идеи с ответственными.
Плюсы и минусы метода
Плюсы:
- Большая вероятность выявить WOW-требования (придумать крутую фичу).
- При наличии на мозговом штурме специалистов, ответственных за разные аспекты системы, увеличивается глубина проработки отдельных требований. То есть низка вероятность придумать нереализуемую фичу.
Минусы:
- Ограниченный круг стейкхолдеров, которых можно привлечь.
- Необходима жесткая модерация. При отсутствии контроля за проведением встречи мозговой штурм быстро превращается в неэффективный балаган.
- Необходима высокая вовлеченность участников в проект (грубо говоря — необходима инициатива со стороны экспертов).
Другие методы выявления требований
- Анализ документации — изучение и анализ существующей документации, которая напрямую или косвенно касается разрабатываемой системы.
- Анализ системных интерфейсов, API и базы данных — анализ систем, которые будут взаимодействовать с разрабатываемой системой.
- Анализ пользовательского интерфейса — анализ интерфейсов, функционально похожих (или идентичных) на разрабатываемую систему (отраслевые стандарты UI/UX). Также к этому относится анализ интерфейсов систем, входящих в IT-экосистему заказчика.
- Моделирование процессов, поведения системы и пользователей — моделирование процессов и схем данных помогает структурировать и упорядочивать информацию о проекте.
- Повторное использование требований — многие элементы систем имеют стандарты исполнения. Например: регистрация — авторизация пользователей.
- Вовлечение представителя заказчика в команду разработки — вовлечение заказчика в работу над проектом является одним из постулатов Agile. В целом наличие представителя заказчика в команде разработки экономит уйму времени на коммуникации.
- Презентации, демо и т.п. — представление требований/реализации системы заказчику. Данный способ помогает уточнить требования, а также выявить скрытые и/или избыточные требования. Пример: демонстрация мокапов будущей системы пользователям.
- Работа в «Поле» (наблюдение) — наблюдение за деятельностью и процессами будущих пользователей.
- Обучение — процесс, в котором заказчик или любой другой человек из организации заказчика, знающий процесс, обучает аналитика по принципу «учитель — ученик».
Очевидный факт:
Только комбинируя методы, возможно добиться сбора требований, максимально отвечающих ожиданиям заказчика.
Материалы для самостоятельного изучения
Блоки знаний:
- Бизнес-анализ — раздел знаний, отвечающий за описание и формализацию бизнес-процессов. Прежде чем интерпретировать бизнес-процессы в виде ПО, необходимо их «правильно» описать и формализовать.
- Моделирование бизнес-процессов — изучение различных нотаций описания бизнес-процессов. Неразрывно связан с бизнес-анализом.
- Системный-анализ — раздел знаний, отвечающий за анализ процессов непосредственно в самом ПО.
- Моделирование систем — изучение нотаций описания систем ПО. Неразрывно связан с системным анализом.
- Документирование требований — изучение различных сред документирования информации о проекте и системе.
- Управление требованиями (согласование, управление изменениями, трассировка требований) — отдельный процесс в системе знаний об анализе в ИТ. Является одним из самых сложных процессов на долгосрочных проектах с большим количеством итераций.
- Прототипирование — изучение различных инструментов для моделирования интерфейсов и архитектуры ПО. Например: Figma для верстки макетов интерфейсов.
Книги:
- Вигерс, Карл: Разработка требований к программному обеспечению. 3-е издание, дополненное / Карл Вигерс, Джой Битти. — Санкт-Петербург : БХВ-Петербург, 2019. — 736 с.
- Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст — 2017.
- Гэртнер, Маркус: ATDD — разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
- Gojko Adzic, David Evans — Fifty Quick Ideas to Improve Your User Stories — 2014.
- Майкл Мескон, Майкл Альберт, Франклин Хедоури — Основы менеджмента
- Хоп, Грегор Шаблоны интеграции корпоративных приложений (Signature Series) / Грегор Хоп, Бобби Вульф. — Москва : Вильямс, 2019. — 672 с.
- Кон, Майк Пользовательские истории. Гибкая разработка программного обеспечения / Майк Кон. — Москва : Вильямс, 2018. — 256 с.
- Паттон, Джефф Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон — Санкт-Петербург : Питер, 2019. — 288 с.
- Cockburn, Alistair Writing Effective Use Cases / Alistair Cockburn. — Addison-Wesley, 2001.
- USE-CASE 2.0
- Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. — Москва : Символ-Плюс, 2018. — 192 с.
- Гойко, Аджич Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке / Аджич Гойко. — Москва : Альпина Паблишер, 2017. — 86 с.
- Коберн, Алистер Быстрая разработка программного обеспечения/ Алистер Коберн. — Москва: Лори, 2002. — 336 с.
- Корнипаев, Илья Требования для программного обеспечения: рекомендации по сбору и документированию / Илья Корнипаев. — Книга по требованию, 2013. — 118 с. Книга
- Ми, Роберт Шаблоны корпоративных приложений / Роберт Ми, Мартин Фаулер. — Москва : Вильямс, 2018. — 544 с.
- Мартин, Роберт Чистая архитектура. Искусство разработки программного обеспечения / Роберт Мартин. — Санкт-Петербург : Питер, 2018. — 352 с.
- BABOK 3.0
- SWEBOK 3.0
Процесс разработки программного обеспечения может быть сложным и ответственным мероприятием. Одним из важнейших аспектов, определяющих успех любого проекта по разработке программного обеспечения, является качество технических требований. Составление надежного набора технических требований гарантирует, что все участники проекта находятся на одной волне и что конечный продукт будет соответствовать их ожиданиям. Эффективная коммуникация между заинтересованными сторонами, четкая постановка задачи и хорошо структурированный подход являются фундаментальными компонентами этого процесса. В этой статье вы узнаете о важности технических требований, значении эффективной коммуникации и о том, как создать надежные технические требования для проектов по разработке программного обеспечения.
Понимание цели и объема технических требований
Технические требования играют важнейшую роль в проектах по разработке программного обеспечения. Они предоставляют подробное описание функциональности, производительности, дизайна и ограничений разрабатываемой программной системы. Эта информация служит дорожной картой для команды разработчиков, помогая им понять, что именно им необходимо реализовать и как различные компоненты программного обеспечения должны работать вместе. Некоторые ключевые элементы технических требований включают:
- Функциональность: Характеристики и возможности программного обеспечения, например, что оно должно делать, какие действия оно может выполнять и какие интерфейсы оно предоставляет.
- Производительность: Время отклика, пропускная способность, масштабируемость и надежность программного обеспечения.
- Дизайн: Архитектура, пользовательский интерфейс и другие визуальные аспекты, определяющие внешний вид и функциональность программного обеспечения.
- Ограничения: Пределы и ограничения, накладываемые на программное обеспечение, такие как эксплуатационные, аппаратные или программные ограничения.
Основная цель технических требований — заложить основу для успешного проекта, прояснив желаемый результат и устранив любые двусмысленности. Это гарантирует, что все заинтересованные стороны, включая клиентов, менеджеров и разработчиков, имеют четкое представление о целях и видении, что помогает избежать недопонимания, напрасной траты ресурсов и упущений в проекте.
Важность эффективной коммуникации
Для успешной реализации проекта по разработке программного обеспечения крайне важна эффективная коммуникация. Непонимание между заинтересованными сторонами проекта, такими как менеджеры, разработчики и клиенты, может привести к недопониманию и нежелательному результату. Эффективная коммуникация может предотвратить многие распространенные проблемы в проектах по разработке программного обеспечения, в том числе:
- Нечетко сформулированные требования, приводящие к потере времени и ресурсов из-за изменений и переделок.
- Несогласованные ожидания и конечный продукт, который не отвечает потребностям конечных пользователей или не достигает целей проекта.
- Снижение уровня сотрудничества и командной работы, что влияет на общее качество проекта.
Одним из важнейших аспектов эффективной коммуникации при создании технических требований является использование единого языка и терминологии. Это помогает гарантировать, что все стороны понимают цели и ожидания проекта и могут легко ссылаться на конкретные компоненты или функции программного обеспечения. Еще одним важнейшим фактором эффективной коммуникации является вовлечение всех заинтересованных сторон в процесс сбора требований. Это гарантирует, что их потребности и ожидания будут учтены, в результате чего получится более полный и точный набор требований. Наконец, эффективная коммуникация предполагает предоставление четких, кратких и информативных требований. Это поможет избежать недопонимания и позволит разработчикам легче реализовать желаемые функции и спецификации, что в конечном итоге приведет к более успешному проекту.
Определение заинтересованных сторон проекта
Первым шагом в создании технических требований для разработки программного обеспечения является определение заинтересованных сторон проекта. К заинтересованным сторонам можно отнести всех, на кого влияет проект или кто в нем заинтересован. Это могут быть клиенты, конечные пользователи, менеджеры, разработчики и другие члены команды разработчиков программного обеспечения. Привлечение заинтересованных сторон на ранних этапах процесса планирования укрепляет их приверженность успеху проекта и помогает обеспечить учет потребностей каждого. Чтобы эффективно привлечь заинтересованные стороны, воспользуйтесь следующими советами:
- Составьте четкий план коммуникаций, включающий регулярные встречи, обновление статуса проекта и возможность обратной связи с заинтересованными сторонами.
- Поощряйте открытое обсуждение и предлагайте заинтересованным сторонам внести свой вклад, чтобы обеспечить учет всех точек зрения.
- Уделите внимание пониманию роли, потребностей и ожиданий каждой заинтересованной стороны, чтобы лучше учесть их проблемы и включить их вклад в технические требования.
Попробуйте no-code платформу AppMaster
AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле
Начать бесплатно
Определение проблемы и целей
После выявления заинтересованных сторон очень важно четко определить проблему, для решения которой создается программное обеспечение, и цели, которые ставятся перед проектом. Четко сформулированные проблема и цели будут направлять процесс разработки и помогут создать действенные, целенаправленные технические требования. При определении проблемы подумайте над следующими вопросами:
- Какие конкретные вопросы или проблемы должно решить программное обеспечение?
- Как проблема влияет на заинтересованные стороны, и каковы их ожидания от решения?
- Что будет означать успешное решение проблемы?
После определения проблемы наметьте цели программного обеспечения. Цели должны быть конкретными, измеримыми, достижимыми, актуальными и привязанными ко времени (SMART).
Сбор и структурирование информации
После четкого определения проблемы и набора целей следующим шагом будет сбор и структурирование соответствующей информации для разработки технических требований. Это включает в себя сбор данных о функциональности, производительности, дизайне и ограничениях программного обеспечения, а также о любых нефункциональных требованиях, таких как безопасность, удобство использования и масштабируемость. Сбор информации может быть осуществлен с помощью различных методов, включая:
- Опрос заинтересованных сторон, чтобы понять их потребности, ожидания и желаемые результаты.
- Проведение исследования рынка конкурентов, чтобы выявить лучшие практики и избежать потенциальных ошибок.
- Изучение существующей документации и ресурсов, таких как руководства пользователя, учебные материалы или другие соответствующие программные приложения.
- Консультации с экспертами в данной области или отраслевыми специалистами, которые могут дать дополнительное представление о проблеме и возможных решениях.
При структурировании информации следует разделить ее на категории, такие как функциональные требования, нефункциональные требования и ограничения. Это поможет создать четкую и организованную основу для написания документации по техническим требованиям. Кроме того, рассмотрите возможность использования визуальных представлений, таких как графики, диаграммы или макеты. Это поможет более эффективно передать сложные идеи и обеспечить четкое понимание заинтересованными сторонами и разработчиками желаемых функций и спецификаций.
Написание четких, кратких и последовательных требований
После сбора и структурирования необходимой информации настало время перевести ее в реальные технические требования. Чтобы обеспечить успех проекта, очень важно, чтобы требования были четкими, краткими и последовательными. При написании технических требований учитывайте следующие рекомендации:
- Будьте конкретны: Четко определите каждое требование с точными деталями, избегая расплывчатых или двусмысленных формулировок. Это гарантирует, что разработчики точно поймут, что от них требуется.
- Используйте согласованную терминологию: Используйте стандартный язык и терминологию во всей документации, чтобы все заинтересованные стороны понимали требования и могли легко ссылаться на конкретные компоненты или функции.
- Будьте проще: Излагайте информацию лаконично, избегая слишком сложных или длинных требований. Это гарантирует, что разработчики смогут реализовать желаемые функции эффективно и без путаницы.
- Учитывайте аудиторию: Помните, что разработчики, которые будут реализовывать требования, могут не обладать таким же уровнем знаний в данной области, как вы. Убедитесь, что ваши требования понятны человеку, менее знакомому с конкретной проблемой или отраслью.
- Структурируйте документ: Организуйте требования в логичном и удобном для выполнения порядке. Рассмотрите возможность использования подразделов, пулевых точек и нумерованных списков, чтобы сделать документ более удобным для чтения.
Следуя этим рекомендациям, вы сможете создать набор технических требований, которые эффективно передают цели и спецификации проекта, минимизируя риск неправильного толкования или путаницы.
Валидация и верификация технических требований
После составления технических требований необходимо обеспечить их точность и полноту путем валидации и проверки. Это помогает выявить любые ошибки, несоответствия или пробелы в требованиях и гарантирует, что они соответствуют целям и задачам проекта. Валидация включает проверку каждого требования, чтобы убедиться, что оно актуально, необходимо и удовлетворяет потребности заинтересованных сторон. Верификация, с другой стороны, включает проверку того, что каждое требование достижимо с помощью имеющихся технологий и ресурсов. Некоторые методы подтверждения и проверки технических требований включают:
Попробуйте no-code платформу AppMaster
AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле
Начать бесплатно
- Коллегиальный обзор: Предложить другим членам команды или экспертам в данной области проанализировать требования, чтобы выявить любые потенциальные проблемы или улучшения.
- Прототипирование: Разработка базового прототипа или макета программного обеспечения, чтобы проверить, точно ли требования представляют желаемый результат и насколько хорошо они отвечают потребностям заинтересованных сторон.
- Проходные испытания: Проведите ознакомительные мероприятия с заинтересованными сторонами и разработчиками, вовлекая их в процесс анализа и выясняя их мнение о требованиях.
Итеративное улучшение и обновление
При разработке программного обеспечения требования часто меняются по мере развития проекта. Очень важно понимать, что технические требования не являются статичными и могут нуждаться в обновлении или уточнении на протяжении всего процесса разработки. Итеративное совершенствование — это процесс постоянного пересмотра требований на основе обратной связи с заинтересованными сторонами, уроков, извлеченных из разработки, и любых изменений в целях, объеме или ограничениях проекта. Это помогает обеспечить соответствие конечного продукта целям проекта и эффективное удовлетворение потребностей заинтересованных сторон. Внедрять итеративные улучшения:
- Поддерживайте открытые каналы связи с заинтересованными сторонами, разработчиками и другими членами команды проекта, чтобы быть в курсе любых изменений, которые могут повлиять на требования.
- Регулярно анализируйте требования и сравнивайте их с текущим состоянием проекта, при необходимости внося изменения для устранения любых несоответствий или обновлений.
- Выделите в графике разработки время для пересмотра и обновления требований, учитывая, что со временем они могут измениться.
Следуя этим шагам, вы сможете создать надежные технические требования, которые заложат основу для успешного проекта разработки программного обеспечения и обеспечат соответствие конечного продукта ожиданиям всех участвующих сторон.
Использование платформ No-Code для упрощения процесса
Одним из способов упрощения процесса определения технических требований является использование no-code платформ, таких как AppMasterПлатформы No-code позволяют пользователям создавать приложения без написания кода, предоставляя удобный визуальный интерфейс для создания программных систем. No-code Платформы могут помочь упростить процесс создания технических требований несколькими способами:
- Визуальное представление: Предоставляя визуальный интерфейс для проектирования программного обеспечения, платформы no-code облегчают определение, структурирование и передачу желаемых функций и спецификаций. Это может значительно снизить вероятность недопонимания и улучшить сотрудничество между заинтересованными сторонами и разработчиками.
- Снижение сложности: Благодаря отсутствию необходимости писать код, платформы no-code упрощают процесс разработки, делая его более доступным для нетехнических заинтересованных сторон. Это может привести к разработке более четких и эффективных требований за счет привлечения более широкого круга точек зрения.
- Итеративная разработка: платформы No-code часто позволяют быстро создавать прототипы и проводить итеративные улучшения, позволяя разработчикам быстрее и эффективнее внедрять изменения и уточнения в требования, чем традиционные процессы разработки.
Использование такой платформы no-code, как AppMaster, позволяет сэкономить время, снизить вероятность недопонимания и в конечном итоге способствует общему успеху проекта разработки программного обеспечения.
Заключение
Создание надежных технических требований для разработки программного обеспечения является залогом успеха любого проекта и предполагает сочетание четкой коммуникации, четко определенных целей и структурированного подхода. Привлечение всех заинтересованных сторон, сбор и структурирование необходимой информации, а также следование лучшим практикам написания, проверки и обновления требований позволит вам заложить основу для успешного проекта разработки программного обеспечения. Кроме того, рассмотрите возможность использования платформ no-code, таких как AppMaster, для упрощения процесса и улучшения сотрудничества между заинтересованными сторонами и разработчиками. Платформы No-code помогут упростить процесс сбора требований и обеспечить более доступный подход к определению, проектированию и проверке программных приложений. При наличии правильных инструментов и методик ваш проект по разработке программного обеспечения будет иметь все необходимое для успеха.
В чем разница между функциональными и нефункциональными требованиями?
Функциональные требования описывают функции и возможности программной системы, например, что она должна делать, какие действия она может выполнять и какие интерфейсы она предоставляет. С другой стороны, нефункциональные требования описывают характеристики или атрибуты системы, такие как производительность, безопасность, удобство использования и масштабируемость. Оба типа требований необходимы для успеха проекта разработки программного обеспечения и должны быть включены в документацию по техническим требованиям.
Могут ли технические требования меняться в процессе разработки программного обеспечения?
Да, технические требования могут и часто меняются в процессе разработки программного обеспечения. Это может произойти по разным причинам, таким как изменение потребностей заинтересованных сторон, появление новых технологий или непредвиденные проблемы, возникающие во время разработки. Важно иметь процесс обработки изменений требований, включая валидацию, проверку и итеративное улучшение, гарантируя, что программное обеспечение остается в соответствии с целями и задачами проекта.
Могут ли технические требования измениться в ходе проекта по разработке программного обеспечения?
Да, технические требования могут и часто меняются в ходе проекта по разработке программного обеспечения. Это может происходить по разным причинам, например, из-за изменения потребностей заинтересованных сторон, появления новых технологий или непредвиденных проблем, возникающих в ходе разработки. Важно иметь процесс обработки изменений требований, включая валидацию, верификацию и итеративное совершенствование, чтобы программное обеспечение соответствовало целям и задачам проекта.
Как платформы no-code могут помочь с техническими требованиями?
No-code платформы, такие как AppMaster, упрощают процесс разработки программного обеспечения, позволяя пользователям создавать приложения без написания кода. Они могут помочь в разработке технических требований, предоставляя визуальный интерфейс для создания программных систем, облегчая определение, структурирование и передачу желаемых функций и спецификаций. Это позволяет сэкономить время, снизить вероятность недопонимания и улучшить сотрудничество между заинтересованными сторонами и командой разработчиков.
В чем разница между функциональными и нефункциональными требованиями?
Функциональные требования описывают характеристики и возможности программной системы, например, что она должна делать, какие действия она может выполнять и какие интерфейсы она предоставляет. Нефункциональные требования, с другой стороны, описывают характеристики или атрибуты системы, такие как производительность, безопасность, удобство использования и масштабируемость. Оба типа требований важны для успеха проекта разработки программного обеспечения и должны быть включены в документацию технических требований.
Что такое технические требования?
Технические требования — это документированная информация, необходимая для описания функциональности, производительности, дизайна и ограничений разрабатываемой программной системы. Они служат дорожной картой для разработчиков, чтобы понять и внедрить желаемые функции и спецификации, а также помогают заинтересованным сторонам и команде разработчиков эффективно общаться.
Что должно быть включено в технические требования?
Технические требования должны включать такую информацию, как функциональность, производительность, дизайн и ограничения программного обеспечения. Они должны четко определять проблему, цели, объем и любые заинтересованные стороны. Кроме того, требования должны быть структурированы и записаны четким, кратким и последовательным образом, с надлежащей проверкой и проверкой посредством повторяющихся циклов улучшения.
Как вы подтверждаете и проверяете технические требования?
Валидация и проверка технических требований включает в себя несколько процессов, в том числе проверку документации на предмет согласованности, полноты и ясности, обеспечение актуальности и необходимости каждого требования, проверку того, что требования достижимы с помощью доступных технологий и ресурсов, а также проверку их соответствия потребностям заинтересованных сторон. и ожидания. Это может также включать итерацию и обновление требований по мере необходимости на протяжении всего процесса разработки.
Как вы подтверждаете и проверяете технические требования?
Валидация и проверка технических требований включает в себя несколько процессов, в том числе анализ документации на предмет согласованности, полноты и ясности, обеспечение актуальности и необходимости каждого требования, проверку того, что требования выполнимы с помощью имеющихся технологий и ресурсов, а также проверку соответствия требованиям и ожиданиям заинтересованных сторон. Это также может включать итерации и обновление требований по мере необходимости на протяжении всего процесса разработки.
Почему важны технические требования?
Технические требования важны, потому что они служат основой для проектов разработки программного обеспечения. Они обеспечивают четкое и краткое описание желаемого результата, гарантируя, что заинтересованные стороны и разработчики находятся на одной странице, и что конечный продукт соответствует намеченным целям. Правильно написанные технические требования могут помочь избежать недопонимания, сократить количество переделок, сэкономить время и ресурсы и способствовать общему успеху проекта.
Как платформы без кода могут помочь с техническими требованиями?
Платформы No-code, такие как AppMaster, упрощают процесс разработки программного обеспечения, позволяя пользователям создавать приложения без написания кода. Они могут помочь с техническими требованиями, предоставляя визуальный интерфейс для создания программных систем, упрощая определение, структурирование и передачу желаемых функций и спецификаций. Это может сэкономить время, снизить вероятность недопонимания и улучшить сотрудничество между заинтересованными сторонами и командой разработчиков.
Какие общие проблемы возникают при создании технических требований?
Общие проблемы при создании технических требований включают нечеткую коммуникацию, недостаточное участие заинтересованных сторон, плохо определенные объем или цели, а также сбор слишком большого или слишком малого количества информации. Эти проблемы можно преодолеть, если следовать структурированному процессу, вовлекая все соответствующие заинтересованные стороны, четко определяя проблему и цели и используя эффективные методы коммуникации на протяжении всего проекта.
Каковы некоторые общие проблемы при составлении технических требований?
Общие проблемы при создании технических требований включают нечеткую коммуникацию, недостаточное участие заинтересованных сторон, плохо определенный объем или цели, а также сбор слишком большого или слишком малого количества информации. Эти проблемы можно преодолеть, следуя структурированному процессу, привлекая все заинтересованные стороны, четко определяя проблему и цели, а также используя эффективные методы коммуникации на протяжении всего проекта.
Что должно быть включено в технические требования?
Технические требования должны включать такую информацию, как функциональность, производительность, дизайн и ограничения программного обеспечения. Они должны четко определять проблему, цели, объем и всех заинтересованных лиц. Кроме того, требования должны быть структурированы и написаны ясным, кратким и последовательным образом, с надлежащим подтверждением и проверкой в рамках итерационных циклов совершенствования.
В этой статье на примерах расскажу о том, как писать и оформлять требования, чтобы их было просто использовать команде разработки и их все-таки дочитывали до конца.
Данный материал будет интересен бизнес- и системным аналитикам, менеджерам и владельцам продуктов, CEO небольших стартапов, в общем — всем, кому нужно писать требования к разработке фичей и ИТ-систем.
Здесь не будет базовой теории, что есть требование и что оно должно соответствовать SMART (надеюсь, вы это и так знаете). Скорее, я покажу некие best practice, как требования лучше оформлять в документации.
Начнем с обсуждения:
- Общих принципов написания «удобных» требований
- Использования таблиц
- Использования схем и диаграмм
Если тема окажется интересной, то в следующей статье посмотрим на использование более продвинутых инструментов, таких как:
- Подход Specification by Example
- Варианты использования
- Мокапы интерфейса
1. Пишите просто
Требования это не роман и удивлять слогом тут никого не нужно. Я еще не раз это повторю в статье, но тот кто читает ваши требования, должен напрягаться по минимуму.
Здесь, как и в дизайне интерфейсов, отлично работает правило: «Не заставляйте меня думать», про которое писал Стив Круг в одноименной книге.
Ниже я привел рекомендации, которые призваны упростить восприятие ваших требований:
- Используйте простой слог и слова, избегайте общих формулировок.
- Избегайте сложносочиненных предложений. В идеале, одно предложение = одна мысль.
- Если вы встречаете союзы «но», «или», то скорее всего, здесь скрыты два отдельных требования.
- Не используйте двойные отрицания.
- Для требованиий со структурой «если <условие>, то <результат>» пишите сначала результат, а потом — условие. Пример: «Система должна запрещать сохранение заказа, если хотя бы одного товара нет в наличии».
Пример — Упрощаем составное требование
Исходное требование:
«Должна быть возможность удалить конкретный товар или сразу все товары из корзины».
По сути, данное требование содержит два отдельных требования:
- «Должна быть возможность удалить конкретный товар из корзины».
- «Должна быть возможность удалить сразу все товары из корзины».
Такое разделение поможет не пропустить скрытое требование разработчику или QA и подскажет менеджеру, что здесь лучше завести две отдельные задачи.
2. Используйте форматирование
Сам текст должен быть хорошо отформатирован. Есть мнение, что разработчики «не читают» требования. Оно отчасти верно. Обычно это вызвано тем, что требования «неудобно» читать: плохая структура, сложный слог, слишком большие блоки текста — пока дочитываешь конец, забываешь началои т.д.
Используйте средства, которые доступны вам в любом редакторе:
- Списки
- Абзацы
- Полужирный шрифт
Например, если вы используете союз «и» (или несколько таких союзов), то лучше каждое условие написать с новой строки.
Пример — Применяем форматирование
Исходное требование:
«Необходимо перевести заказ в статус «Доставляется», если заказ оплачен и весь товар есть в наличии на складе.»
Давайте упростим восприятие этого требования. Получим следующее:
«Необходимо перевести заказ в статус «Доставляется», если:
- Заказ оплачен
- И весь товар есть в наличии на складе.
Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:
- Речь идет о заказе в статусе «Доставляется».
- Действие изменения статуса должно выполняться при соблюдении двух условий.
На первый взгляд все это очевидно, но в процессе рабочей деятельности, я постоянно сталкиваюсь с подобными недочетами. Я намерено не пишу «ошибки», так как формально оба требования равнозначны, но на практике, второй вариант воспринимается гораздо проще.
3. Упрощайте требования
Вы должны не только писать просто, но и оптимизировать свои требования, упрощать их. Этот принцип должен работать во всем. Когда вы пытаетесь передать информацию, она неизменно искажается, а часть ее теряется. И, чем больше передается информации, тем больше ее теряется в процессе передачи.
Пример — Оптимизируем длинное требование
Исходное требование:
«Заказ отображается в личном кабинете пользователя, если заказ находится в одном из статусов: «Новый», «Ожидает оплаты», «Оплачен», «Доставляется». Заказ в статусе «Доставлен» не должен отображаться в личном кабинете.»
Как можно его упростить:
«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен».
Во-первых, мы сделали само требование короче, а значит вероятность, что его прочитают стала выше.
Во-вторых, технические специалисты отлично считывают такие конструкции и вы, опять же, снимаете с них когнитивную нагрузку.
В-третьих, мы сделали требование универсальнее. При появлении в будущем нового статуса заказа, например, «Проверяется наличие на складе», второй пример будет актуален, а первый придется обновлять в спецификации.
4. Используйте таблицы
Запомните, таблицы — ваш главный «бро» 🙂
Таблицы позволяют хорошо структурировать информацию и не пропустить важное при изучении требований. Когда я пишу очередной блок требований я всегда задаю себе два вопроса:
- Как я могу упростить эти требования?
- Как эти требования можно оформить в табличном виде?
Почему таблицы лучше работают:
- Таблицы воспринимаются проще, чем сплошной текст. Меньше вероятность упустить важные детали при изучении требований.
- Таблицы проще изменять и дополнять информацией в будущем (новые колонки, новые строки).
- Удобно добавлять комментарии (в отдельной колонке), отделяя их от требований.
Рассмотрим пример части из ТЗ на большую государственную систему из открытых источников:
«Успешно авторизованный пользователь, входящий в группу пользователей c ролью «Исполнитель», должен попадать на «UI-006 Главная страница личного кабинета», а пользователь, входящий в группу пользователей с ролью «Наблюдатель» – на «UI-092 Главная страница Мониторинга (дашборд)» подсистемы «Мониторинг». Если пользователь в личном кабинете настроил страницу по умолчанию, то открываемая страница должна определяться на основе выбранной настройки.»
Если прочитать это требование внимательно и сделать пару заметок, то ничего сложного в нем нет, разобраться можно. Но давайте упростим восприятие этого требования, с помощью таблицы. Получим следующее:
«После успешной авторизации в системе, пользователю должна открываться стартовая страница, согласно условиям ниже:»
Если в дальнейшем у нас появится новая роль, то нужно будет всего лишь добавить еще одну строку в таблицу.
Таблицы для описания интерфейсов
Таблицы являются отличным инструментом для описания форм и пользовательских интерфейсов.
Пример формы редактирования из того же ТЗ:
Для описания требований к форме можно использовать таблицу ниже, в которой мы укажем для каждого поля:
- Тип поля.
- Значение поля при открытии формы.
- Ограничения на выбираемые данные.
- Можно ли редактировать поле и требования к валидации (если есть).
Для описания действий на форме (Сохранить и Отмена) лучше использовать отдельную таблицу, так как описания действий и полей формы сильно отличаются.
Когда использовать таблицы (спойлер — всегда!):
- Вы описываете два и более объектов со одинаковыми свойствами (поля формы; разделы сайта; роли пользователей и т.д.).
- Вы хотите описать реакцию системы при возникновении определенных событий.
- Вы описываете миграцию данных или маппинг полей между системами.
5. Используйте схемы
Схемы и диаграммы — это еще один отличный способ улучшить качество передачи знаний в команде разработки.
Нарисованную схему можно дополнитель текстовым описанием для каждого блока и/или процесса. Это работает намного лучше, чем резкий переход к текстовому описанию, так как схемы имеют свойство заинтересовывать, ведь все мы любим рассматривать картинки.
Далее я поделюсь схемами, которые использую чаще всего.
Контекстная диаграмма
Зачем нужна: Показывает как разрабатываемая система взаимодействует с внешними миром.
Внешний мир может быть представлен: другими ИТ-системами, пользователями или устройствами.
Когда использовать: На этапе проектирования системы, чтобы:
- Понять, с какими системами придется интегрироваться.
- Понять, какие интерфейсы ввода/вывода нужно реализовать.
P.S. Еще эту диаграмму очень любят архитекторы.
Я не сторонник строгих правил разработки диаграмм, но стараюсь придерживаться следующих рекомендаций для контекстной диаграммы:
- Разрабатываемая система изображается в виде круга в центре.
- По ее периметру изображаются внешние акторы (системы, пользователи, устройства) в виде прямоугольников.
- Стрелками рисуются потоки данных (в том числе физических объектов) от актора к системе и наоборот.
- Нужно показывать только основные потоки данных и/или операции.
Пример контекстной диаграммы из книги «Разработка требований к программному обеспечению» (Джой Битти, Карл Вигерс):
Схема бизнес-процессов (BPMN-диаграмма)
BPMN — это нотация описания бизнес-процессов в виде набора обозначений и ряда определенных правил.
Зачем нужна: Позволяет зафиксировать описание бизнес-процессов на этапе их дизайна и использовать это «знание» на этапе разработки и внедрения решения.
Когда использовать: Вообще, у BPMN довольно широкий спектр применения.
В контексте описания требований, чаще всего эта нотация используется для описания взаимодействий пользователей с системой и между собой. Становится видно, какие операции выполняет пользователь, а какие — система, и в какой последовательности. Можно показать процессы обработки ошибок.
При разработке BPMN-диаграмм (в контексте описания требований) главное — избавиться от перфекционизма.
Ваша основная задача — передать информацию, которой вы владеете, команде разработки с минимальными искажениями.
Качество ваших диаграмм будет зависеть от количества ранее созданных (волшебной пилюли, увы, здесь нет). На начальных этапах советую использовать базовые элементы:
- Start/End Events — начальное и конечное события.
- Activity — Действие, которое выполняет пользователь или система.
- Gates — Шлюзы. Используются для принятия решений и запуска параллельных процессов.
- Lanes — Дорожки, которые разграничивают разные типы пользователей и системы.
Пример описания бизнес-процесса обработки инцидентов:
Если вам интересна отдельная статья про примеры построения BPMN-диаграмм на реальных примерах, напишите об этом в комментариях.
Диаграмма состояний
Зачем нужна: показывает как объект переходит из одного состояния в другое.
Когда использовать:
- У объекта много состояний (2+), логика переходов зависит от определенных событий.
- С объектом могут совершать действия сразу несколько пользователей (например, редактирование заказа). Это поможет выявить исключительные ситуации, которые можно заранее продумать, а не фиксить потом на production.
Как и схемы в BPMN, диаграмма состояний отлично читается и техническими специалистами, и бизнес-пользователями, и экспертами.
Пример диаграммы состояний для объекта «инцидент» из BPMN-диаграммы выше:
Заключение
В заключение еще раз хотелось бы подчеркнуть мысль, что при разработке требований (и вообще при любой коммуникации) вы должны стараться максимально упростить «потребление» этой информации и снять когнитивную нагрузку с конечного пользователя (разработчика, владельца бизнеса и т.д.).
1. Введение —
Во введении объясняется значение SRS в целом, его возможности для вашей команды и его структура.
1.1. Цель
Здесь объясните цель и структуру документации по программному обеспечению SRS: типы требований, которые будут рассмотрены, а также персонал, который будет ее использовать.
Этот раздел должен быть коротким: достаточно 1-2 абзацев.
1.2. Целевая аудитория
Вы можете углубиться и объяснить, как заинтересованные стороны и команды будут работать с SRS, а также участвовать в ее разработке. Обычно это владельцы продукта, инвесторы, бизнес-аналитики, разработчики, иногда тестировщики и операционный персонал. Вся структура определяется вашим подходом к разработке программного обеспечения и организационной структурой команды.
1.3. Использование по назначению
Опишите, в каких ситуациях ваша команда будет использовать SRS. Обычно его используют в следующих случаях:
- проектирование и мозговой штурм новых функций
- планирование продолжительности проекта, спринтов, оценка затрат
- оценка рисков
- мониторинг и измерение успеха команды
- конфликтные ситуации, когда вовлеченные стороны имеют разное видение качественно выполненного продукта.
1.4. Объем
В этой части рассматривается объем продукта, поэтому вам необходимо дать краткий обзор системы — ее основное назначение, функции и положение. Это сравнимо с тем, как вы объясняете продукт на собрании заинтересованных сторон, за исключением того, что вам разрешено более глубоко вникать в технические особенности.
В этом разделе должны быть описаны:
- Ожидается, что все типы пользователей будут взаимодействовать с системой
- Все основные части архитектуры
1.5 Определения и сокращения
В вашем документе команда часто использует определенные слова. Устранение возможных недоразумений, подключение новых разработчиков и разрешение конфликтных ситуаций станет проще, если вы проясните значение этих слов.
Вышеупомянутые компоненты составляют определение. Определения предоставляют информацию о функции, базовых технологиях, целевых лицах, бизнес-объектах (пользователях, клиентах, посредниках) и заинтересованных сторонах. Вы можете использовать аббревиатуру для более быстрого написания SRS, если хотите. Документ будет доступен для чтения до тех пор, пока он включен в таблицу определений.
2. Общее описание
Во второй части вы описываете читателям основные функции продукта, целевых пользователей и возможности системы. Это описание концентрируется только на ключевых функциях и архитектуре программного обеспечения, не вдаваясь в подробности о надстройках и соединениях.
2.1 Потребности пользователей
Эта часть является вопросом выбора, поэтому некоторые организации предпочитают не включать ее в свою техническую документацию SRS. Мы считаем, что лучше прямо сейчас перечислить проблемы, которые вы хотите решить с помощью вашего функционала. Это пригодится позже при мозговом штурме и мониторинге функций. Вы можете вернуться к этому разделу в любое время в процессе разработки продукта и посмотреть, не отклонилась ли команда взаимодействия с пользователем с намеченного пути.
Потребности относятся к проблемам, которые пользователи смогут решить с помощью системы. Вы можете разделить эти потребности на подкатегории, если имеете дело с сильно сегментированной аудиторией. Старайтесь не вдаваться в подробности о потребностях каждого пользователя. Вам нужно оставить место для интерпретации на тот случай, если проблема окажется более серьезной, чем вы думали изначально.
2.2 Допущения и зависимости
Предположения — это предположения команды о продукте и его возможностях, которые будут правильными в 99% ситуаций. Естественно предположить, например, что платформа, помогающая водителям ориентироваться в ночное время, будет использоваться преимущественно в ночном режиме.
Каково значение предположений? Они позволяют в первую очередь сосредоточиться на наиболее важных функциях приложения. Это предположение помогает понять, что дизайнеры должны разработать интерфейс, подходящий для видения в темноте, для помощника вождения в ночное время. Некоторые пользователи, безусловно, могут открыть приложение в течение дня, но это далеко не так, поэтому вам не нужно сразу включать связанные элементы в прототип.
3. Особенности системы и требования
В этой части подробно рассматриваются характеристики продукта и критерии исполнения. Поскольку предыдущие два раздела посвящены продукту в целом, здесь вы найдете более подробное описание.
3.1 Функциональные требования
указываются в списке функций, которые будут выполняться в системе. Эти критерии касаются вопроса «что будет создано?» а не «как» и «когда».
Функциональные требования начинаются с описания требуемой функциональности в зависимости от того, насколько она важна для приложения. Если вы хотите сначала поработать над этим, вы можете начать с дизайна, но затем вам следует перейти к разработке. Функциональные требования не содержат подробностей о стеках технологий, поскольку они могут меняться по ходу проекта. Вместо того, чтобы концентрироваться на внутренней логике, функциональные требования сосредотачиваются на функциональности конечного пользователя.
3.2 Требования к внешнему интерфейсу
Функциональные требования составляют значительную часть спецификации системных требований. Чтобы охватить все необходимые функции системы, вам понадобится 4-5 страниц информации. Некоторые команды разбивают их по темам, чтобы документ было легче читать.
Как правило, компоненты проектирования SRS рассматриваются отдельно от серверной части и бизнес-логики. Это имеет смысл, поскольку дизайнеры, а не разработчики, занимаются большей частью этой области, а также потому, что именно здесь начинается процесс разработки продукта.
В зависимости от проекта требования к внешнему интерфейсу могут состоять из четырех типов:
- Интерфейс пользователя
- Программный интерфейс
- Аппаратный интерфейс
- Интерфейс связи
Требования к внешнему интерфейсу описывают элементы страницы, которые будут видны конечному клиенту. Они могут включать в себя список страниц, элементы дизайна, ключевые стилистические темы, даже художественные элементы и многое другое, если они необходимы для продукта.
3.3 Системные требования
Системные требования продукта определяют условия, при которых он может использоваться. Обычно они относятся к аппаратным спецификациям и функциям. Требования к оборудованию SRS часто определяются минимальным и максимальным диапазонами, а также порогом оптимальной производительности продукта.
Создание системных требований перед началом создания продукта может показаться сложным, но это необходимо. Разработчики должны придерживаться требований к оборудованию, чтобы им не пришлось перезапускать проект позже. Мобильные приложения (с множеством переменных, которые необходимо учитывать) и приложения, требующие высокой реактивности (игры, любой продукт с VR/AR или IoT), особенно уязвимы.
3.4 Нефункциональные требования
Для многих организаций эта часть SRS является самой сложной. Если функциональные требования касаются вопроса о том, что создавать, то нефункциональные стандарты определяют, как это сделать. Они устанавливают критерии того, насколько эффективно должна работать система. В эту область включены пороговые значения производительности, безопасности и удобства использования.
Настоящая ценность заключается в том, что трудно определить нефункциональные требования. Дать определение таким фразам, как «параллелизм» или «переносимость», сложно, поскольку они могут иметь различное толкование для всех вовлеченных сторон. В результате мы выступаем за присвоение каждому нефункциональному требованию оценки. Вы можете пересмотреть требования вашего проекта в любое время, чтобы увидеть, удовлетворяет ли текущая система первоначальным ожиданиям.