2024-11-21 19:12

Требования к ПО: что это, какими бывают и почему именно так — подробный гайд (часть 1)

Бизнес-анализ

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

Начнем с того, что бизнес-аналитики в IT (и не только) работают с требованиями. Этим наша работа не ограничивается, но в сухом остатке именно на них она концентрируется. Системные аналитики, если вашему миру не чужда такая роль, также работают с требованиями — вероятно, чуть иными требованиями (но не факт), но все же и их требования ложатся в картину, которую мы тут рассмотрим. То бишь если свести всех IT-аналитиков до условного минимума обязанностей, то их задача состоит в том, чтобы проработать и донести до команды разработки качественный набор требований к тому, какую IT-систему необходимо разработать для заказчика.

Для не особо знакомых с бизнес-анализом пара важных понятий, которые будут активно встречаться в тексте ниже:

Решение (Solution) — это то, что в рамках проекта реализует команда разработки. Если к нам пришли за разработкой нового ПО (программного обеспечения), решением будет целевая программная система. Если к нам пришли за тем, чтобы мы доработали что-то уже существующее, решением будет доработка существующей системы X. Решением также теоретически может быть и некий программно-аппаратно-человеческий комплекс, и сугубо неайтишные или не чисто айтишные вещи (если смотреть на бизнес-анализ шире, чем в контексте IT-разработки) — например, найм новых людей в команду, новые более эффективные процессы на стороне заказчика и т. п. Фокус бизнес-аналитика — на решении (аналитик в проекте — владелец информации о решении, которое команде необходимо реализовать). В сравнении, фокус менеджера проекта, например — на проекте (т. е. на людях, которые будут разрабатывать решение, ресурсах, сроках разработки, процессах и т. п.)

Заинтересованное лицо (Stakeholder) — человек или группа лиц, имеющие отношение к целевому решению. Это несколько упрощенное определение, но для наших целей будет достаточным. Т. е. это, например, заказчик (тот, кто платит нам за разработку решения), пользователи (те, кто будут непосредственно пользоваться решением), команда разработки (включая нас как аналитиков), государство, регламентирующее решение тем или иным образом. Решение касается всех этих людей и организаций, т. е. затронет их жизнь в каком-то ключе, либо они, в свою очередь, будут как-то влиять на разработку или жизнь решения.

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

Вначале дадим пару популярных определений того, что такое «требование»:

BABOK: Пригодное для практического использования представление потребности.

Ну такое себе, а потому поищем нечто менее абстрактное.

IEEE 610.12−1990:

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

Уже ближе к истине, но давайте переведем на человеческий, опустив мишуру:

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

Для понимания того, что такое требования, хватит — эти два аспекта покрывают все виды требований. При этом между собой эти определения связаны. Т. е. это не просто соседние формулировки, а комбинация: второе определение вытекает из первого — в решение нам необходимо вложить то, что стейкхолдеру нужно, чтобы стать по итогу счастливым. И концептуально наша задача как аналитиков тут проста: 1) понять, что нужно всем причастным к проекту людям или организациям, 2) заложить в целевое решение такие параметры, которые реализуют эти нужды.

Диспуты и размытые границы требований, упомянутые выше, касаются в основном краев (того, с чего начинаются и на чем заканчиваются требования). Например, финансовые цели заказчика касательно решения — это требования? Архитектура базы данных системы — требования? Интерфейс пользователя системы — требования? Ниже я приведу усредненную типовую вариацию ответа на эти вопросы, но давайте все же не забывать о том, что в командах приняты разные подходы. Я буду отмечать подобные моменты по тексту, но имеем в виду, что для кого-то ответы на вопросы выше — «да», в иных же местах — «нет». Детальнее об этом, но с расчетом на более глубокое погружение в бизнес-анализ, можно почитать тут. Для аналитика всегда важно как можно более точно нащупать границы требований для того контекста, в котором мы будем свою магию анализа применять. Это поможет минимизировать сомнения вида «а лезть ли мне в это?» — мы будем точно понимать, в какую часть стоит погрузиться, а какой займутся более компетентные в этом плане люди в команде.

Также важно понять, что требования — это условно «кто-то что-то требует от решения», и это простое заявление нужно аккуратненько уложить в голове. Например, описание того, как у заказчика что работает на текущий момент — это не требования. Бизнес-правила как некие действующие установки на уровне заказчика, отрасли или государства — не требования (детальнее об этом тут и тут). Это не значит, что аналитик не занимается изучением подобной информации. Это значит, что информация эта сугубо вспомогательна и нужна лишь для того, чтобы качественно проработать требования. Требования всегда направлены на решение и отвечают на условный вопрос (пусть и с вариациями в зависимости от типа требований) «что от решения нужно».

Теперь о том, какими требования бывают: как их классифицировать, понять виды и осознать, почему существует именно такая картина. Для тех, кто впервые с этим сталкивается, спойлер: универсальной и объективно верной классификации нет. Есть несколько теорий разной степени популярности. Будьте морально готовы к тому, что термин, который будете использовать вы, где-то трактуют иначе — к сожалению, такова реальность. Учитывая, что BABOK — наиболее популярный стандарт в области бизнес-анализа, возьмем его за базу, расшифруем и впоследствии уже детализируем от себя.

Итак, виды требований согласно BABOK:

Есть три уровня требований: Бизнес-требования, Требования заинтересованных лиц и Требования к решению. Последний уровень делится на Функциональные и Нефункциональные требования, а где-то рядом с ним еще крутится дополнительный, вспомогательный вид — Переходные требования. Именно в порядке, указанном на схеме, и прорабатываются требования, и далее мы увидим, почему.

Начнем с бизнес-требований (Business Requirements).

Бизнес-требования — это ответ на вопрос «Зачем заказчику нужно решение?». Заказчик — это тот, кто платит деньги за разработку и внедрение решения. А потому это можно перефразировать так: «Почему заказчик готов платить деньги за решение? В чем его мотивация?» Нам важно начать работу именно с этой точки, т. к. именно с реализации того, за что платят деньги, и удовлетворения того, кто их платит, нужно стартовать, и это то, что мы всегда держим в абсолютном приоритете по ходу проекта. Потребности и «хотелки» остальных всегда вторичны.

Бизнес-требования в минимальной комплектации формулируются в виде целей (бизнес-целей, как их принято называть), которые решение позволит заказчику достичь. В продвинутых случаях аналитик может усложнить их, добавив уровни (более точечные цели или задачи; так называемые критерии успеха и прочие поясняющие детали), но в любом случае итоговый набор информации будет направлен на ответ на вопрос выше и образно должен звучать как «Заказчик готов платить деньги для того, чтобы…»

Давайте на примерах разной направленности:

Вы покупаете себе микроволновку

Обеспечить возможность разогревать пищу

Типовая ошибка: Купить микроволновку (у нас получилась формулировка вида «реализовать решение, чтобы реализовать решение» — требование должно отражать мотивацию/потребность/итоговый бизнес-эффект для заказчика; бизнес-требования не должны формулироваться в терминах конкретного решения, чтобы не ограничивать анализ того, какие решения еще могут быть: купить газовую горелку, купить плиту, разводить костер — все это альтернативные варианты решений разной степени применимости)

Собственный продукт для массового потребителя: термометр для измерения экстремальных температур

Заработать 1000000$ на продаже продукта в течение года

Типовая ошибка: Дать рынку уникальный термометр (это не отражает мотивацию заказчика: дать, чтобы что? Заказчик платит деньги за то, чтобы просто дать что-то рынку в порыве голого альтруизма?)

Программная система: веб-приложение для заказа обедов в офис компании для сотрудников

Повысить удовлетворенность сотрудников работой в компании на 50% по итогам опроса в течение полугода с момента релиза

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

Каждый из примеров выше с разной степенью качества отражает мотивацию заказчика (вас как бенефициара покупки; стартапера; ответственного за внедрение системы питания в офис).

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

Как прорабатывать: про все описанное ниже можно детальнее почитать тут, тут и тут, однако ключевые вещи все же очертим:

На проработку бизнес-требований и ряда важной сопутствующей информации нацелен такой этап бизнес-анализа, как Стратегический анализ или Discovery.
Многими исполнителями этот этап (и этот вид требований, как следствие) осознанно или неосознанно пропускается, т. к. «не дело холопов копаться в мотивации барина — платит и платит». Подобное порой уместно и обосновано, а иногда – крайне вредно и опасно.
Для качественной проработки бизнес-требований начинать работу нужно с изучения бизнес-потребностей заказчика. Именно из них по итогу «выродятся» бизнес-требования.

Как по итогу выглядят: бизнес-цели (в идеале соответствующие SMART-критериям в плане качества) в рамках документа Vision and Scope (Документ об образе и границах решения) или как отдельные странички/набор информации в Confluence или иной системе, где аналитик хранит требования.

Что, если игнорировать: если заказчик не будет или будет халатно держать в фокусе бизнес-требования (т. е. ответственность в таком случае за эту часть мы перекладываем на него), то это потенциальная катастрофа: команда будет делать не то, что на самом деле нужно «инвестору» — либо в масштабе всего проекта, либо частично. Представьте, что вы пошли к врачу с задачей «направь меня на процедуру X», т. е. вы тут заказчик с решением, которое хотите от него получить. Если врач не затронет ваши бизнес-требования («зачем это вам нужно?») и не поставит под сомнение ваше решение, а послушно его исполнит («не вопрос, выпишу направление»), ценный ли для вас это вариант и, если да, то всегда ли? В IT-проектах вопрос ставится аналогично, причем сюда еще добавляется риск потратить впустую огромный бюджет. Т. е. если раскопки мотиваций заказчика уместны (исходя из услуг, которые оказывает исполнитель) и подобное аналитиком упускается, последствия могут быть максимально негативными. И даже если формально по контракту заказчик ничего исполнителю предъявить не сможет (врач сделал то, о чем его просили), его общее впечатление от инициативы в целом может остаться крайне отрицательным.

Следующий уровень требований — требования заинтересованных лиц (ЗЛ) (Stakeholder Requirements). Почему именно они идут следующими? Давайте вдумаемся: чтобы достичь поставленных бизнес-целей заказчика, что нужно сделать? Поразмыслив, мы придем к тому, что для этого необходимо реализовать такое решение, которое будет решать проблемы ключевых людей, причастных к нему, или соответствовать их пожеланиям/требованиям. Например, для того, чтобы заработать деньги на продаже масс-продукта, необходимо продать продукт, который будет приносить счастье его будущим пользователям и будет соответствовать требованиям маркетплейсов в плане размещения и государства в плане законодательства. Эта схема работает всегда: чтобы реализовать бизнес-требования заказчика, нужно реализовать требования причастных к решению стейкхолдеров.

Тут уместна аналогия с техникой Impact Mapping — по содержанию она как раз отражает всю нашу цепочку типов требований: на первом уровне Impact Map мы формулируем бизнес-требования, а второй и третий уровень — это ответы на вопросы «кто может поспособствовать или помешать достижению целей» (что примерно равно нашему понятию stakeholder) и «как мы хотим изменить их поведение, чтобы оно способствовало достижению бизнес-целей» (что примерно равно их требованиям — требованиям ЗЛ).

Требования ЗЛ — это формулировки нужд отдельных стейкхолдеров касательно целевого решения. Они направлены на реализацию их личных потребностей. По большей части требования ЗЛ состоят из требований пользователей (как ключевой категории стейкхолдеров помимо самого заказчика), причем ряд теорий даже называют этот уровень «требования пользователей» (User Requirements). Подобное не будет являться грубой ошибкой, но стоит помнить о том, что пользователями стейкхолдеры не ограничиваются, и в примере выше у нас фигурировали такие (маркетплейсы, государство). Но ключевой фокус у нас будет, конечно, на будущих пользователях решения.

Требования ЗЛ описывают 1) задачи, которые пользователи смогут решать с помощью решения, и 2) любые иные пожелания и требования, которые пользователи и иные стейкхолдеры предъявляют к решению. Ключевой вопрос, на которые такие требования отвечают: «Что необходимо пользователям и стейкхолдерам от решения? Что они смогут с помощью решения осуществить и каким они его хотят видеть?». Естественно, с добавлением «в контексте реализации бизнес-требований».

На данном этапе важно понять, что требования ЗЛ — это мостик между бизнес-требованиями(«что необходимо достичь заказчику») и требованиями к решению(«что команде разработки нужно заложить в решение»). Требования к решению (следующий, третий уровень требований) будут напрямую вытекать из требований ЗЛ и по большей части будут говорить о том же самом, что и требования ЗЛ, но с иной позиции: если требования ЗЛ — это «стейкхолдеру нужно получить от решения X; нужно уметь сделать с решением Y; нужно, чтобы решение соответствовало Z», то требования к решению, сформулированные на их базе — это «в решение нужно заложить свойство A, функцию B, параметр C». Иногда итоговые требования к решению могут практически дублировать требования ЗЛ, т. е. звучать максимально похоже; в других же случаях — детализировать их и выглядеть совершенно по-иному. Но главное, что из этой логики вытекает — требования ЗЛ имеют вспомогательный характер: они нужны для того, чтобы впоследствии сформулировать на их базе требования к решению, после чего сами по себе они уже не особо полезны.

И снова на примерах:

Вы покупаете себе микроволновку

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

Типовая ошибка: учитывая вспомогательный характер требований ЗЛ, серьезные ошибки в их формулировке совершить сложно — главное, чтобы они были как можно более полно собраны. Есть, однако, общая рекомендация: не спускаться на данном этапе на уровень требований к решению и не общаться со стейкхолдерами подобным языком (об этом также можно почитать тут и тут). Когда стейкхолдер говорит (или вы формулируете вопрос ему таким образом): «В решении должно быть…», он не отражает свою потребность/мотивацию — он формулирует то, каким он видит наполнение решения. А стоит всегда держать в голове, что за продумывание решения в сферически-вакуумном мире отвечает аналитик и команда разработки. И для подбора огненных решений необходимо понимание потребностей/мотиваций.

Микроволновка должна обладать цифровым интерфейсом.
Производитель микроволновки может реализовать требование вида «Нужно, чтобы с микроволновкой было удобно взаимодействовать» разными способами, т. е. в решение могут быть вложены разные требования: 1) Микроволновка должна обладать цифровым интерфейсом. 2) Микроволновка должна обладать голосовым интерфейсом и т. п. И вот как раз для того, чтобы не ограничивать себя и заказчика в том, как именно мы будем вкладывать в решение требования ЗЛ, и стоит как раз формулировать их в таких терминах, которые будут отражать мотивацию стейкхолдеров вместо концепции «мне нужно, чтобы в решении было X».

Собственный продукт для массового потребителя: термометры для измерения экстремальных температур

Пользователи: Нужно измерять температуру, причем в диапазоне от -100 до +100 градусов по Цельсию.
Нужно, чтобы продукт был удобным в контексте нахождения в экстремальных условиях.

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

Государство: Все термометры должны соответствовать стандарту X и пройти сертификацию Y.

Типовая ошибка: Термометр должен иметь большую кнопку, чтобы в перчатках в условиях Северного полюса по ней можно было точно жмякнуть (мы снова преждевременно спускаемся с уровня потребностей ЗЛ на уровень того, что нужно заложить в решение)

Программная система: веб-приложение для заказа обедов в офис компании для сотрудников

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

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

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

Типовая ошибка: Система должна позволять экспортировать заказы в виде Excel-файла.
Доступ к системе должен осуществляться по протоколу HTTPS (аналогичное примерам выше обоснование).

Где искать: в идеале — у будущих пользователей и любых иных стейкхолдеров. Но тут стоит понимать, что доступ к ним может быть затруднен. У заказчика может быть следующий посыл: «Думать о наполнении решения будем со мной — не стоит дергать конечных пользователей, сами справимся — я знаю, что им нужно». Причем иногда — например, для масс-продуктов — доступ к пользователям может объективно стать сложным или невозможным, т. к. продукт направлен не на конечный известный набор пользователей, а на открытый рынок. Подобное не есть желательная ситуация, и аналитику стоит-таки постараться выйти на конечных пользователей/стейкхолдеров или их представителей, но вполне может статься, что голосом ЗЛ будет заказчик, даже не планирующий пользоваться системой лично. Подобное несет серьезные риски для этого уровня требований (реализация не того, что действительно необходимо пользователям и иным стейкхолдерам), но не всегда является катастрофой — для некоторых проектов (как правило, небольших/простых) вполне себе может быть достаточным иметь заказчика в качестве источника требований ЗЛ, пусть и потенциально незначительно их искажающего.

Как прорабатывать:

Максимально полно определить стейкхолдеров. Понять, у кого из них могут быть требования, которые важно учесть. Выделить из них пользователей и разбить их на категории со схожими параметрами — например, по спектру задач, которые они будут с помощью решения выполнять. Не забыть про непрямых пользователей (пользующих решение опосредованно) и пользователей-«нелюдей» (например, стороннее ПО, пользующее наше решение через API).
Выйти на идентифицированных стейкхолдеров (далеко не обязательно на каждого поголовно —можно выделить типовых и доступных для вас представителей) и с помощью интервью, опросов, наблюдений и прочих техник извлечь требования в контексте очерченных выше вопросов.
Пользоваться в процессе извлечения требований чеклистом требований следующего уровня — требований к решению (для полноты). Учитывая, что требования к решению — это то, во что «выродятся» требования ЗЛ, логичным было бы зная, каков их конечный набор, взять их за базу уже на этом этапе и пройтись по ним как по чеклисту — чтобы убедиться, что мы ничего не упускаем, извлекая исходные требования ЗЛ.
Представить требования пользователей (те, которые касаются взаимодействия с решением) в виде набора User Stories (пользовательских историй) (см. User Story Map как пример того, как выработать набор User Stories) или Use Cases (вариантов использования) (см. Use Case Diagram как визуальный набор вариантов использования). В процессе при этом не лишним будет пользоваться прототипами (предварительными макетами интерфейса пользователя), чтобы работа по обсуждению шла нагляднее.

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

Никак. Т. е. извлекаем требования ЗЛ, сразу же перерабатываем их в требования к решению и фиксируем/храним уже только итоговые требования к решению.
Частично. Где уместно, в контексте требований к решению приводим и исходные требования ЗЛ. В частности, это решается самим форматом подачи информации, если аналитик использует User Stories или Use Cases: требования ЗЛ фигурируют в формулировках User Stories и в качестве названий для Use Cases. При этом для тех требований ЗЛ, которые нельзя оформить с помощью этих техник, идем по варианту из пункта 1.
Полностью фиксируем. В таком случае можно иметь отдельный документ с названием типа Stakeholder Requirements или отдельные странички/набор информации в Confluence, где и собрать их все, сгруппированные по стейкхолдерам-источникам. Ценность в этом по большей части только в трассировке, т. е. дабы в будущем понимать, откуда растут ноги у тех или иных требований к решению.

Что, если игнорировать: игнорировать подобные требования можно только, если вы по какой-либо причине перепрыгнули сразу к требованиям к решению, т. е. идете к заказчику с вопросами вида «Диктуй мне, что должно быть в решении» (или же сами для своего продукта начинаете генерацию того, чем должно быть наполнено решение, минуя данный этап). Ключевое последствие тут: решение, которым не пользуются, ибо нет нужных функций, неудобно, долго и т. п. (что, в свою очередь, значимо повлияет на достижение бизнес-требований). Учет потребностей будущих пользователей и ориентация наполнения решения именно на них — важный аспект работы аналитика, а для массовых продуктов — в принципе залог их жизнеспособности (почему опасно игнорировать потребности пользователей см. тут и тут) Дополнительные последствия могут включать игнорирование требований государства, отрасли, а также интересов команды разработки, поддержки и прочих стейкхолдеров, которых легко упустить, если явно о них не подумать.

Переходим к требованиям к решению (Solution Requirements). Если этическая миссия аналитика у нас в том, чтобы причинить счастье заказчику (помочь ему в реализации бизнес-требований), то ключевая с точки зрения трудозатрат задача — выработать качественный набор требований к решению и отдать его в команду разработки.

Требования к решению — это формулировки того, что нужно вложить в решение, чтобы реализовать требования ЗЛ.

Если вернуться к аналогии с техникой Impact Mapping, это четвертый уровень карты Impact Map: «что мы в плане решения можем дать или должны сделать, чтобы обеспечить желаемые изменения в поведении стейкхолдеров». Какую функцию мы должны заложить в систему, какие качественные параметры она должна демонстрировать, какой доступ со стороны пользователей система должна поддерживать и т. п. — в общем, любой аспект того, каким мы должны сделать будущее решение.

Давайте вернемся к определению термина «требование». Напомню:

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

С учетом уже известной информации несложно вывести логически, что первый пункт соответствует бизнес-требованиям и требованиям ЗЛ: у заказчика есть некая цель, направленная на решение проблемы; у стейкхолдеров — свои потребности/нужды. Второй пункт определения — это уже уровень требований к решению. Стоит только его дополнить, т. к. он слишком ограничен в исходной формулировке: «… и чтобы реализовать описанное в пункте 1». Мы не просто ради контракта что-то вкладываем в решение — мы делаем это в первую очередь ради реализации того, что необходимо стейкхолдерам.

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

В отличие от требований ЗЛ, требования к решению формулируются от лица решения, т. е. к ним явно или неявно можно добавить «в решении должно быть…; решение должно уметь…».

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

Где искать (актуально для всех требований к решению): концептуально их нигде искать не нужно. У нас как у аналитиков на этом этапе уже есть требования ЗЛ, и спроектировать наполнение такого решения, которое будет реализовывать эти требования — это наша задача. На практике же мы не работаем с такими требованиями изолированно от стейкхолдеров. Детали того, как именно в системе стоит реализовать то или иное требование ЗЛ, мы будет уточнять и отражать от тех же пользователей и иных стейкхолдеров, у которых мы собирали исходные требования ЗЛ.

Давайте пройдемся по каждому подвиду.

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

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

И снова к примерам:

Вы покупаете себе микроволновку

Функциональные возможности микроволновки:
1. Разогревание содержимого.
1.1. Настройка мощности.
1.2. Настройка времени.
1.3. Нагрев.
2. Открытие/закрытие.

1. Разогревание содержимого:
1.3. Нагрев.
1.3.1. В микроволновке должна быть возможно поместить в нее содержимое для нагрева.
1.3.2. Микроволновка должна позволять стартовать и остановить нагрев содержимого с установленной мощностью на установленный период.

Собственный продукт для массового потребителя: термометры для измерения экстремальных температур

Функциональные возможности термометра:
1. Измерение температуры.
2. Замена батарейки.
3. Пользовательские настройки.

1. Измерение температуры:
1.1. На термометре должна быть кнопка для старта измерения температуры.
1.2. При нажатии на эту кнопку пользователем термометр должен измерить температуру окружающей среды.
1.3. После завершения измерения термометр должен отобразить температуру на экране.

Программная система: веб-приложение для заказа обедов в офис компании для сотрудников

Функциональные возможности веб-приложения:
1. Аутентификация/авторизация (возможности войти в систему и выйти из нее, плюс назначение роли учетной записи).
2. Работа с заказами (просмотр заказов, создание, редактирование, отмена, экспорт списка в PDF-файл)
3. Работа с меню (импорт нового меню из Excel-файла, просмотр меню).
4. Домашняя страница (информация о системе).

1. Аутентификация/авторизация:
1.1. Когда пользователь открывает систему, система должна отобразить страницу «Вход», где пользователю необходимо ввести логин и пароль для входа в систему под своей учетной записью.
1.2. Когда пользователь подтверждает вход, система должна проверить следующее:
А) То, что данные были введены. В случае, если логин или пароль пусты, система должна отобразить «Укажите логин/пароль».
Б) Наличие учетной записи с указанными параметрами. В случае, если такая запись отсутствует, система должна отобразить «Неверные логин и/или пароль»
1.3. В случае успешного входа система должна присвоить пользователю роль, соответствующую учетной записи, и перенаправить его на страницу «Меню».

Продолжение — во второй части.