Требования

Требования (Requirements)

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

Спецификация (specification): Документ, описывающий (в идеале - исчерпывающе, однозначно и доступно) требования, дизайн, поведение или иные характеристики компонента или системы. Зачастую в спецификацию включаются процедуры контроля исполнения. (ISTQB)

Спецификация компонента (component specification): Описание функций компонента в терминах его выходных значений для заданных входных значений при определенных условиях, а также требуемого нефункционального поведения (например, использование ресурсов). (ISTQB)

Спецификация проектирования теста (test design specification): Документ, описывающий тестовое условие (элементы покрытия) для элемента тестирования, детализированный подход к тестированию, и идентифицирующий соответствующие тестовые сценарии высокого уровня. (IEEE 829)

Спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. (IEEE 829)

Спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования.

Спецификация тестовых сценариев (test case specification): Документ, описывающий комплект тестовых сценариев - цель, входы, тестовые операции, ожидаемые результаты и предусловия выполнения для объекта тестирования. (IEEE 829)

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

Источники и пути выявления требований

Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник:

Интервью. Самый универсальный путь выявления требований, заключающийся в общении проектного специалиста (как правило, бизнес-аналитика) и представителя заказчика (или эксперта, пользователя и т.д.). Интервью может проходить в классическом понимании этого слова (беседа в виде «вопрос ответ»), в виде переписки и т.п. Главным здесь является то, что ключевыми фигурами выступают двое - интервьюируемый и интервьюер (хотя это и не исключает наличия «аудитории слушателей», например, в виде лиц, поставленных в копию переписки).
Работа с фокусными группами. Может выступать как вариант «расширенного интервью», где источником информации является не одно лицо, а группа лиц (как правило, представляющих собой целевую аудиторию, и/или обладающих важной для проекта информацией, и/или уполномоченных принимать важные для проекта решения).
Анкетирование. Этот вариант выявления требований вызывает много споров, т.к. при неверной реализации может привести к нулевому результату при объемных затратах. В то же время при правильной организации анкетирование позволяет автоматически собрать и обработать огромное количество ответов от огромного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты.
Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются с интервью, анкетированием, прототипированием и моделированием - в том числе для обсуждения результатов и формирования выводов и решений. Мозговой штурм может проводиться и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время сгенерировать большое количество идей, которые в дальнейшем можно не спеша рассмотреть с точки зрения их использования для развития проекта.
Наблюдение. Может выражаться как в буквальном наблюдении за некими процессами, так и во включении проектного специалиста в эти процессы в качестве участника. С одной стороны, наблюдение позволяет увидеть то, о чём (по совершенно различным соображениям) могут умолчать интервьюируемые, анкетируемые и представители фокусных групп, но с другой - отнимает очень много времени и чаще всего позволяет увидеть лишь часть процессов.
Прототипирование. Состоит в демонстрации и обсуждении промежуточных версий продукта (например, дизайн страниц сайта может быть сначала представлен в виде картинок, и лишь затем сверстан). Это один из лучших путей поиска единого понимания и уточнения требований, однако он может привести к серьезным дополнительным затратам при отсутствии специальных инструментов (позволяющих быстро создавать прототипы) и слишком раннем применении (когда требования еще не стабильны, и высока вероятность создания прототипа, имеющего мало общего с тем, что хотел заказчик).
Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регламентирующую документацию. Также к этой технике относится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания.
Моделирование процессов и взаимодействий. Может применяться как к «бизнес-процессам и взаимодействиям» (например: «договор на закупку формируется отделом закупок, визируется бухгалтерией и юридическим отделом…»), так и к «техническим процессам и взаимодействиям» (например: «платежное поручение генерируется модулем “Бухгалтерия”, шифруется модулем “Безопасность” и передаётся на сохранение в модуль “Хранилище”»). Данная техника требует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обработкой большого объема сложной (и часто плохо структурированной) информации.
Самостоятельное описание. Является не столько техникой выявления требований, сколько техникой их фиксации и формализации. Очень сложно (и даже нельзя!) пытаться самому «придумать требования за заказчика», но в спокойной обстановке можно самостоятельно обработать собранную информацию и аккуратно оформить ее для дальнейшего обсуждения и уточнения.

Уровни и типы требований

Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления требований на этом уровне является общее видение (vision and scope) - документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требований:
- Нужен инструмент, в реальном времени отображающий наиболее выгодный курс покупки и продажи валюты;
- Необходимо в два-три раза повысить количество заявок, обрабатываемых одним оператором за смену;
- Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе договоров.
Пользовательские требования (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объема работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования (use cases), пользовательских историй (user stories), пользовательских сценариев (user scenarios). Несколько простых, изолированных от контекста и друг от друга примеров пользовательских требований:
- При первом входе пользователя в систему должно отображаться лицензионное соглашение;
- Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе;
- При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде черновика или публикацию.
Бизнес-правила (business rules) описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-правил:
- Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть отредактирован или удален;
- Публикация статьи возможна только после утверждения главным редактором;
- Подключение к системе извне офиса запрещено в нерабочее время.
Атрибуты качества (quality attributes) расширяют собой нефункциональные требования и на уровне пользовательских требований могут быть представлены в виде описания ключевых для проекта показателей качества (свойств продукта, не связанных с функциональностью, но являющихся важными для достижения целей создания продукта - производительность, масштабируемость, восстанавливаемость). Атрибутов качества очень много, но для любого проекта реально важными является лишь некоторое их подмножество. Несколько простых, изолированных от контекста и друг от друга примеров атрибутов качества:
- Максимальное время готовности системы к выполнению новой команды после отмены предыдущей не может превышать одну секунду;
- Внесенные в текст статьи изменения не должны быть утеряны при нарушении соединения между клиентом и сервером;
- Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса.
Функциональные требования (functional requirements) описывают поведение системы, т.е. ее действия (вычисления, преобразования, проверки, обработку и т.д.). В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»). Несколько простых, изолированных от контекста и друг от друга примеров функциональных требований:
- В процессе инсталляции приложение должно проверять остаток свободного места на целевом носителе;
- Система должна автоматически выполнять резервное копирование данных ежедневно в указанный момент времени;
- Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на соответствие требованиям RFC822.
Нефункциональные требования (non-functional requirements) описывают свойства системы (удобство использования, безопасность, надежность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы. Несколько простых, изолированных от контекста и друг от друга примеров нефункциональных требований:
- При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов;
- Ни при каких условиях общий объем используемой приложением памяти не может превышать 2 ГБ;
- Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.

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

Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта. Несколько простых, изолированных от контекста и друг от друга примеров ограничений:
- Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800x600 до 1920x1080;
- Не допускается использование Flash при реализации клиентской части приложения;
- Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript.
Требования к интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой. Несколько простых, изолированных от контекста и друг от друга примеров требований к интерфейсам:
- Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON;
- Протоколирование событий должно вестись в журнале событий операционной системы;
- Соединение с почтовым сервером должно выполняться согласно RFC3207 («SMTP over TLS»).
Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования. Несколько простых, изолированных от контекста и друг от друга примеров требований к данным:
- Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB;
- Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную;
- Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.

Свойства качественных требований (требования к самим требованиям)

Завершенность (completeness). Требование является полным и законченным с точки зрения представления в нем всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершенностью:
- Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде» - каков алгоритм шифрования?);
- Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т.д.» - что мы должны понимать под «и т.д.»?);
- Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»).
Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершенности и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью:
- В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» - здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах);
- Требование допускает разночтение в силу грамматических особенностей языка (например: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» - здесь описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы). Такое нарушение атомарности часто влечёт за собой возникновение противоречивости;
- В одном требовании объединено описание нескольких независимых ситуаций (например: «когда пользователь входит в систему, ему должно отображаться приветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» - все эти три ситуации заслуживают того, чтобы быть описанными отдельными и куда более детальными требованиями).
Непротиворечивость, последовательность (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Типичные проблемы с непротиворечивостью:
- Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» - тогда как он успешно вошёл в систему, если не имел такого права?);
- Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» - так всё же красной или синей?);
- Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» - разрешение есть у экрана, у окна есть размер).
Недвусмысленность (unambiguousness, clearness). Требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью:
- Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объемов данных» - насколько «больших»?) Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно (adequate), быть способным (be able to), легко (easy), обеспечивать (provide for), как минимум (as a minimum), быть способным (be capable of), эффективно (effectively), своевременно (timely), применимо (as applicable), если возможно (if possible), будет определено позже (to be determined, TBD), по мере необходимости (as appropriate), если это целесообразно (if practical), но не ограничиваясь (but not limited to), быть способно (capability of), иметь возможность (capability to), нормально (normal), минимизировать (minimize), максимизировать (maximize), оптимизировать (optimize), быстро (rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), большой (large), гибкий (flexible), устойчивый (robust), по последнему слову техники (state-of-the-art), улучшенный (improved), результативно (efficient). Вот утрированный пример требования, звучащего очень красиво, но совершенно нереализуемого и непонятного: «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно»;
- Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» - ФС здесь обозначает файловую систему? Точно? А не какой-нибудь «Фиксатор Сообщений»?);
- Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» - и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности.
Выполнимость (feasibility). Требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью:
- Так называемое «озолочение» (gold plating) - требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).
- Технически нереализуемые на современном уровне развития технологий требования (например: «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»).
- В принципе нереализуемые требования (например: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»).
Обязательность, нужность (obligatoriness) и актуальность (up-to-date). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета (см. «проранжированность по…»). Также исключены (или переработаны) должны быть требования, утратившие актуальность. Типичные проблемы с обязательностью и актуальностью:
- Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет;
- Требованию выставлены неверные значения приоритета по критериям важности и/или срочности;
- Требование устарело, но не было переработано или удалено.
Прослеживаемость (traceability). Прослеживаемость бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability matrix). Типичные проблемы с прослеживаемостью:
- Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрестных ссылок;
- При разработке требований не были использованы инструменты и техники управления требованиями;
- Набор требований неполный, носит обрывочный характер с явными «пробелами».
Модифицируемость (modifiability). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а ее изменение не приводит к нарушению иных описанных в этом перечне свойств. Типичные проблемы с модифицируемостью:
- Требования неатомарны (см. «атомарность») и непрослеживаемы (см. «прослеживаемость»), а потому их изменение с высокой вероятностью порождает противоречивость (см. «непротиворечивость»);
- Требования изначально противоречивы (см. «непротиворечивость»). В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость;
- Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов).
Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования. Типичные проблемы с проранжированностью состоят в ее отсутствии или неверной реализации и приводят к следующим последствиям:
- Проблемы с проранжированностью по важности повышают риск неверного распределения усилий проектной команды, направления усилий на второстепенные задачи и конечного провала проекта из-за неспособности продукта выполнять ключевые задачи с соблюдением ключевых условий;
- Проблемы с проранжированностью по стабильности повышают риск выполнения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности);
- Проблемы с проранжированностью по срочности повышают риск нарушения желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию.
Корректность (correctness) и проверяемость (verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. К типичным проблемам с корректностью также можно отнести:
- опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную аббревиатуру в другую также осмысленную, но не имеющую отношения к некоему контексту; такие опечатки крайне сложно заметить);
- наличие неаргументированных требований к дизайну и архитектуре;
- плохое оформление текста и сопутствующей графической информации, грамматические, пунктуационные и иные ошибки в тексте;
- неверный уровень детализации (например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту);
- требования к пользователю, а не к приложению (например: «пользователь должен быть в состоянии отправить сообщение» - увы, мы не можем влиять на состояние пользователя).

Источники требований:

Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения);
Нормативное обеспечение организации (регламенты, положения, уставы, приказы);
Текущая организация деятельности объекта автоматизации;
Модели деятельности (диаграммы бизнес-процессов);
Представления и ожидания потребителей и пользователей системы;
Журналы использования существующих программно-аппаратных систем;
Конкурирующие программные продукты.

Виды документов требований:

Спецификация требований к программному обеспечению (SRS - Software Requirement Specification): представляет собой документ, подготовленный группой системных аналитиков (system analysts), который используется для описания программного обеспечения, которое будет разработано, основной бизнес-цели и функциональности определенного продукта, а также того, как он выполняет свои основные функции. В организациях, которые используют SRS, они обычно очень похожи на то, что описывается в PRD и FSD. SRS - это основа любого проекта, поскольку он состоит из структуры, которой будет следовать каждый член команды. SRS также является основой контракта с заинтересованными сторонами (пользователями / клиентами), который включает в себя все подробности о функциональности будущего продукта и о том, как он должен работать. SRS широко используется разработчиками программного обеспечения в процессе разработки продукта или программы. SRS включает как функциональные, так и нефункциональные требования, а также варианты использования. В идеальном документе SRS учитывается не только то, как программное обеспечение будет взаимодействовать с другим программным обеспечением или когда оно встроено в оборудование, но также потенциальных пользователей и способы их взаимодействия с программным обеспечением. Он также содержит ссылки на таблицы и диаграммы, чтобы получить четкое представление обо всех деталях, связанных с продуктом. Документ SRS помогает членам команды из разных отделов оставаться в единстве и обеспечивать выполнение всех требований. Этот документ также позволяет минимизировать затраты и время на разработку программного обеспечения.;
Спецификация бизнес-требований (BRS - Business Requirement Specification): BRS - это спецификация бизнес-требований, цель которой - показать, как удовлетворить бизнес-требования на более широком уровне. Документ BRS является одним из наиболее широко распространенных документов со спецификациями. Это очень важно, и BRS обычно создается в самом начале жизненного цикла продукта и описывает основные цели продукта или потребности, которые клиент хочет достичь с помощью определенного программного обеспечения или продукта. Он обычно создается бизнес-аналитиком (business analyst) на основе спецификаций других заинтересованных сторон и после тщательного анализа компании-клиента. Обычно окончательная версия документа проверяется клиентом, чтобы убедиться, что ожидания всех заинтересованных сторон бизнеса верны. BRS включает в себя все требования, запрошенные клиентом. Как правило, он состоит из цели продукта, пользователей, общего объема работ, всех перечисленных функций и возможностей, требований к удобству использования и производительности. В этот тип документа не включены варианты использования, а также диаграммы и таблицы. BRS используется в основном высшим и средним менеджментом, инвесторами в продукты, бизнес-аналитиками;
Спецификация функциональных требований (FRS - Functional Requirement Specification): документ, в котором описаны все функции, которые должно выполнять программное обеспечение или продукт. Фактически, это пошаговая последовательность всех операций, необходимых для разработки продукта от начала до конца. FRS объясняет подробности того, как определенные программные компоненты будут вести себя во время взаимодействия с пользователем. Этот документ создан квалифицированными разработчиками и инженерами и считается результатом тесного сотрудничества между тестировщиками и разработчиками. Основное отличие от документа SRS заключается в том, что FRS не включает варианты использования. Он также может содержать диаграммы и таблицы, но это не обязательно. Этот документ является наиболее подробным, поскольку в нем подробно объясняется, как программное обеспечение должно функционировать (включая бизнес-аспекты, соответствие требованиям, требования безопасности), поскольку оно также должно удовлетворять всем требованиям, упомянутым в документах SRS и BRS. FRS помогает разработчикам понять, какой продукт они должны создать, а тестировщики программного обеспечения лучше разбираются в различных тестовых примерах и сценариях, в которых ожидается тестирование продукта;
Документ бизнес-требований (BRD - Business Requirements Document, Business Needs Specification, Business Requirements): BRD фокусируются на определении бизнес задач проекта. BRD определяет одну или несколько бизнес задач стоящих перед пользователями, которые могут быть решены с помощью продукта компании. После этого предлагается решение - обычно это новый продукт или усовершенствование существующего продукта в нужной части. Он также может включать какой-то предварительный бизнес анализ - прогноз прибылей, анализ рынка и конкурентов, а также стратегию продаж и продвижения. Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком. В маленьких компаниях это может быть даже директор или владелец фирмы;
Документ требований рынка (MRD - Market Requirements Document): MRD фокусируется на определении требований рынка к предлагаемому новому продукту. Если BRD определяет круг проблем и предлагает вариант их решения - то MRD более подробно описывает детали предлагаемого решения. Он может включать несколько или все нижеприведенные аспекты:
- Функциональные возможности, необходимые для решения бизнес задач;
- Анализ рынка и конкурентов;
- Функциональные и нефункциональные требования;
- Приоритезацию требований и функциональных возможностей;
- Варианты использования;
Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком. Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в следующей - и может содержать более 50 страниц;
Документ требований к продукту (PRD - Product Requirements Document): PRD фокусируется на определении требований к предлагаемому новому продукту. Если MRD фокусируется на требованиях с точки зрения нужд рынка, PRD фокусируется на требованиях с точки зрения самого продукта. Обычно он более детально описывает возможности и функциональные требования и может даже содержать скриншоты и лэйауты пользовательских интерфейсов. В организациях, где MRD не включает детализацию требований и варианты использования, PRD закрывает эту брешь. Обычно он пишется Менеджером по продукту, Бизнес аналитиком или Продуктовым аналитиком;
Функциональная спецификация (FSD - Functional Specifications Document): FSD детально определяет функциональные требования к продукту с фокусировкой на реализации. FSD может определять продукт последовательно форму за формой и одну функциональную возможность за другой. Это документ, который уже может непосредственно использоваться командой разработчиков для создания продукта. Если MRD и PRD фокусируются на требованиях с точки зрения потребностей рынка и продукта, FSD фокусируется на определении деталей продукта, в форме, которая может быть использована разработчиками. FSD может также включать законченные скриншоты и детальное описание пользовательских интерфейсов (UI). Обычно он пишется Системным аналитиком, Архитектором решения или Главным разработчиком - т.е. автор обычно сам относится к разработчикам;
Спецификация продукта (PSD - Product Specifications Document): PSD - это наименее популярная аббревиатура, но в тех организациях, которые используют эти документы, они обычно соответствуют по содержанию и объему Функциональной спецификации (Functional Specifications Document FSD) описанный выше;
Спецификация функционального дизайна (FDS - Functional Design Specification);
Спецификация технического дизайна (TDS - Technical Design Specification);
…

Техники тестирования требований см. в теме “Тестирование документации” в видах тестирования.

Источники:

Доп. материал:

Критерии качества требований и как им следовать
IEEE Guide to the Software Engineering Body of Knowledge. Chapter 1.
Software Requirements Engineering: What, Why, Who, When, and How By Linda Westfall
Карл Вигерс «Разработка требований к программному обеспечению»
Святослав Куликов “Тестирование программного обеспечения. Базовый курс”. Раздел 2.2.8. “Типичные ошибки при анализе и тестировании требований”.
«File Converter» Project Requirements SAMPLE
Системные требования и требования к программному обеспечению
Ицыксон В.М. ПТППО - Управление требованиями
Почему требования так важны для тестировщика
Сколько вопросов задавать по ТЗ
Сбор требований по TROPOS

Пользовательские истории (User stories)

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

В индустрии разработки ПО слово «требование» определяет нашу цель, что именно нужно клиентам и что заставит нашу компанию развивать свой бизнес. Будь то продуктовая компания, которая производит программные продукты, или сервисная компания, которая предлагает услуги в различных областях программного обеспечения, основной базой для всех из них является требование, а успех определяется тем, насколько хорошо эти требования выполняются. Термин «требование» имеет разные названия в разных методологиях проекта. В Waterfall это называется Requirement/Specification Document, в Agile или SCRUM требования документируются в виде «Epic» и «User Story». В модели Waterfall документы с требованиями представляют собой огромные документы на сотни страниц, поскольку весь продукт реализуется за один этап. Но это не относится к Agile / SCRUM, потому что в этих случаях требования предъявляются к небольшим функциям или фичам, поскольку продукт готовится поэтапно.

Пользовательская история определяет требования к любой функциональности или фиче, в то время как критерии приемки (Acceptance Criteria) определяют критерии готовности (Definition of done) для пользовательской истории или требования.

Пользовательская история - это требование для любой функциональности или фичи, которое записано в 1-2 строки. Пользовательская история обычно является самым простым из возможных требований и касается одной-единственной функции/фичи.

Формат:

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

Например, “Как пользователь WhatsApp, я хочу, чтобы значок камеры в поле ввода чата позволял захватывать и отправлять изображения, чтобы я мог щелкнуть и поделиться своими фотографиями одновременно со всеми своими друзьями.”

Это стандартный формат, но далеко не обязательный или единственно-возможный. Главное в пользовательской истории - это ценность, которую пользователь получит от функции, т.е. User Story - это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду.

Job Stories

В целом Job Stories - схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности. Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.

“Тело” JS делится на три части:

Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение;
Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции;
Expected Outcome: описывает, что получит юзер после использования функции.

Job Stories могут писаться по двум форматам:

В одну строку: When X I want to Y so I can Z" или "When X, actor is Y so that Z;
В три строки:
- When X
- I want to Y
- So I can Z.

Пример: When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.

Источники:

Доп. материал:

Смотрите также:

Требования (Requirements)

Пользовательские истории (User stories)

On this page