Требования- некая абстракция, в реальной практике они всегда существуют в виде какого-то представления: документов, моделей, формальной спецификации, списка и т.д. Требования важны т.к. они оседают в виде понимания нужд заказчика создаваемой системы, поскольку в программном проекте много различных аспектов, видов деятельности и фаз разработки, то это понимание может принимать очень разные представления. Каждое представление требований выполняет определенную задачу, фиксация между различными группами соглашений и используется для оперативного управления проектом или используется для верификации и модельно ориентированного тестирования.
Таким образом формализация требований в проекте может быть очень разной это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Может существовать параллельно несколько формализаций решающие различные задачи, например:
1. Неформальная постановка требований в переписке по электронной почте хорошо работает в небольших проектах при вовлеченности заказчика в разработку, однако электронные письма оказываются важными документами (уметь вести деловую переписку, подводить итоги, хранить важные письма и пользоваться ими при разногласии)
Мастер-класс по сбору и анализу требований
2. Требования в виде документа- описание предметной области и ее свойств, составление технического задания, функциональная спецификация для разработчиков.
3. Требования в виде графа с зависимостями в одном из средств поддержки требований. Такое представление удобно при частом изменении требований, отслеживании выполнения, при организации привязки к требованиям: людей, задач, теста, кода. Важно, чтобы была возможность легко создавать такие графы из текстовых документов и наоборот. Определение кратчайшего пути и есть понятие графа.
4. Формальная модель требований для верификации модельно ориентированного тестирования и т.д.
Каждый способ представления требований должен отвечать на следующие вопросы: кто потребитель, пользователь этого представления и с какой целью это представление используется.
Перечислим ряд ошибок, встречающихся при составлении технического задания и иных документов с требованиями:
1. Описание возможных решений вместо требований
2. Нечеткие требования, которые не допускают однозначную проверку, а также имеет оттенок советов, обсуждений, рекомендаций
3. Игнорирование аудитории для которой предназначено представление требований
4. Пропуск важных аспектов связанных с нефункциональными требованиями (например срок готовности смежных подсистем с которыми взаимодействуют данные, окружение подсистем и т.д.). Типичной проблемой при создании программно-аппаратных систем, когда аппаратура не поспевает вовремя и ПО невозможно оттестировать.
Цикл работы с требованиями
В своде знаний по программной инженерии (SWEDOK) определяются следующие виды деятельности при работе с требованиями:
1. Выделение требований- целенаправленная на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.
Эффективные техники для выявления требований / Экспертный стол Дениса Гобова
2. Анализ требований, целью которого является обнаружение и устранение противоречий и неоднозначности в требованиях, их уточнение и систематизация.
3. Описание требований- в результате этой деятельности требования должны быть оформлены в виде структурного набора документов и моделей, которые могут: периодически анализироваться, оцениваться с разных позиций и в итоге должен быть утвержден как официальная формулировка требований к системе
4. Валидация требований- решает задачу оценки принятности требований и их характеристик, на основе которых будут разработаны ПО, в силу непротиворечивости и полноты.
Конфигурационное управление
Файл- поименованная часть жестоко диска размеченная для хранения файла
Источник: vunivere.ru
Как мы ведём требования к ПО: формализация
Есть разные подходы к ведению требований к ПО: одни пишут полноценные сценарии использования, другие выбирают пользовательские истории, а третьи — вообще избегают формализации требований, считая это пустой тратой времени.
Но я так не считаю. Формализация — большой и важный этап разработки требований. В статье об этом расскажу: как происходит ведение требований у нас, какие этапы мы проходим, каких правил придерживаемся и что будет, если отклоняться от правил. Если вы системный или бизнес-аналитик, владелец продукта или просто работаете с требованиями к программному обеспечению, то эта статья для вас.
Прежде всего зададим контекст.
Под программным обеспечением будем понимать цифровой продукт, над созданием которого работает продуктовая команда.
Типовая команда продукта состоит из:
- владельца продукта (product owner);
- команды разработки: системный аналитик, разработчики и тестировщик;
- часто к ним подключается дизайнер, отвечающий за проектирование пользовательского интерфейса;
- и архитектор, который помогает с проработкой архитектуры будущего решения.
Большинство продуктовых команд работают по Scrum со спринтами по 1-2 недели. У каждого спринта есть цель, которая связана с какой-то ценностью, в первую очередь, для клиента.
В бэклог текущего спринта должны попадать задачи с понятными требованиями. В противном случае команде разработки потребуется время на их уточнение, что в условиях ограничения по времени повышает риск недостижения поставленной цели.
И здесь возникает формализация.
Этапы формализации требований
Мы избегаем неопределенности и берём в работу задачи только с понятными требованиями, настаиваем на их формализации.
Сейчас расскажу, как это происходит. Общая схема проработки требований выглядит примерно так.
Создание и развитие цифрового продукта направлено на удовлетворение определенных потребностей бизнеса. Чаще всего они имеют финансовое выражение — сводятся к росту прибыли, положительной разнице между доходами и расходами организации. Часть прибыли направляют на развитие бизнеса, что должно привести к ещё большему росту прибыли, часть которой также направляют на развитие и т.д. Если бизнес хочет результат, то он должен быть описан ясно и четко.
За определение потребностей бизнеса отвечает владелец соответствующего цифрового продукта (PO). Он общается с представителями бизнеса, изучает бизнес-процессы, проводит исследование рынка и формулирует бизнес-требования к продукту. У нас они обычно выражаются в виде документа Word (BRD) и эпиков (Epics) в Jira.
BRD содержит полное описание бизнес-требований, которым должен удовлетворять цифровой продукт. На основе данного документа и с учетом принятых архитектурных паттернов архитектор (Solution Architect) разрабатывает видение (Vision) архитектуры будущего решения. Ниже — общий вид BRD как пример.
Epics представляют собой набор отдельных бизнес-требований. Команда продукта (Product Team) проводит их анализ и декомпозицию на пользовательские истории (User Stories). Ниже — пример Epics и User Stories. Справа — Sab-Tasks (о них чуть дальше).
Каждая история характеризуется стейкхолдером, его потребностью и ценностью от её закрытия, критериями приёмки. Именно User Stories обычно и составляют основу бэклога текущего спринта команды.
Однако на данном этапе их ещё нельзя брать в работу. Требования не до конца определены.
На основе Vision для User Stories системный аналитик (SA) разрабатывает проектные решения (Specs).
Обычно они фиксируются на отдельной страничке в пространстве продукта в Confluence. Specs содержат дизайн технических решений, которые необходимо реализовать в цифровом продукте. Они должны быть понятны всем членам команды разработки. Пример Specs на скриншоте ниже.
При необходимости, для User Stories готовится дополнительный артефакт — дизайн пользовательских интерфейсов (UI). Для этого команда подключает к работе над продуктом дизайнера (Designer). Часто он ведёт разработку в Figma и помимо макетов пользовательского интерфейса готовит кликабельные прототипы для дальнейшей валидации требований. Ниже пример подобного UI.
На основе Specs и UI команда разработки (DevTeam) выполняет декомпозицию User Stories на подзадачи (Sub-Tasks) для каждого члена команды. Пример Sub-Tasks на картинке.
Таким образом, бизнес-требования и требования стейкхолдеров определены, дизайн пользовательских интерфейсов и технических решений готов, перечень подзадач для их реализации сформирован. Остаётся только выполнить оценку User Stories, приоритезировать бэклог продукта и спланировать текущий спринт.
Мы не торопимся, следуем принятому процессу, следим за качеством проработки требований.
Но что произойдёт, если отклониться от процесса? Об этом расскажу дальше.
Отклонение от процесса
Правила существуют, чтобы их нарушать. А процессы — чтобы от них отступать. Время от времени продуктовые команды отклоняются от описанного процесса в надежде выпустить новую фичу как можно быстрее. Тогда схема проработки требований сократится до такого состояния.
Отклонения обычно проявляются в отказе от разработки технических артефактов — Vision и/или Specs.
Первый артефакт опускают, когда команда разработки состоит из опытных специалистов, способных самостоятельно спроектировать архитектуру будущего решения, а само решение — это доработка существующего цифрового продукта. В этом случае сокращается срок проектирования, однако повышается риск того, что архитектурное решение будет противоречить принятым паттернам и его реализацию откажутся ставить в бой.
Specs бывают не востребованы при мелких доработках, когда каждому члену команды полностью понятно, что и как требуется реализовать, а внесённые изменения достаточно отразить в проектной документации. Однако в случае крупных доработок отсутствие Specs может потребовать дополнительного времени на уточнение требований и следовательно повышает риск недостижения цели спринта.
Я — руководитель системных аналитиков. Мои ребята распределены по продуктовым командам. Однажды пришлось выслушивать недовольство PO одной из команд, связанное с двукратным увеличением оценки сроков проекта. Первичная оценка составляла три месяца. Но когда половина этого периода закончилась, пришло осознание, что необходимо полгода.
На протяжении нескольких спринтов одни и те же User Stories оставались в работе. Тот факт, что они не закрывались, говорит о том, что они не были проработаны должным образом. А DevTeam не до конца понимала требования к цифровому продукту.
Отсюда мы вывели правило — любое отклонение от процесса должно быть осознанным и обоснованным.
и других способов ?
Обеспечивает за счет выбранной формы представления или контролирует , затратив на это приемлемые усилия, следующие требования:
Варианты формализации требований
Неформальная постановка требований. Спецификация требований в виде документов.
Формализации требований в проекте могут быть разными, существовать параллельно, решать различные задачи.
Требования в виде диаграмм (UML Use-Case, IDEF0, DFD, IDEF3, ER ).
Формальная модель требований. 
