Статья предназначена для бизнес- и системных аналитиков, формулирующих требования к информационным системам.
Эта информация также будет полезна разработчикам и другим лицам, работающим в сфере программного обеспечения.
В статье рассматривается формирование и документирование требований.
В частности, рассматривается случай, когда аналитику сообщают: «все ваши требования бесполезны, потому что они не объясняют разработчику, что нужно сделать и, главное, почему» .
Давайте посмотрим на процесс, как это обычно происходит. Аналитик получает запрос на изменение функционала в виде заявки в техподдержку, технического задания или прямой жалобы клиента.
Суть запроса в том, что в системе что-то плохо и надо подумать, как это исправить.
Или что вам нужно сделать еще одну такую возможность здесь, на этом экране.
Или необходимо «у пользователя была возможность сделать это» .
Часто аналитик просто записывает требование в том виде, в каком оно пришло: в виде нескольких предложений или пользовательской истории, формирует из этого задачу на изменение (или несколько задач) и отправляет ее разработчику.
Далее происходит то, что описано в последнем предложении предыдущего абзаца.
Давайте разберемся, почему.
Проблема №1 .
Что не понятно разработчику? Ему непонятно, какие экраны в системе менять, какие кнопки, поля, вкладки и API и т.д. нужно дорабатывать/создавать под требования клиента.
То, что исходит от аналитика, функциональные требования , и разработчику необходимо функциональная спецификация (другие названия: реализация, проектирование) с подробным описанием необходимых изменений.
Например, вместо описания функциональности с детализацией уровня «Когда пользователь нажимает «ОК», диалоговое окно закрывается, и основное окно, которое было там до появления диалогового окна, оказывается в фокусе».
(функциональная спецификация) разработчик получает описание с подробностями уровня «Пользователь должен иметь возможность закрыть диалоговое окно и вернуться в главное окно» (функциональное требование).
В последнем описании отсутствуют две детали реализации: * окно закрывается при нажатии кнопки ОК, * фокус автоматически возвращается в главное окно.
Даже если разработчик самостоятельно придумает эти недостающие детали, их отсутствие в тексте исходного задания создаст проблемы.
Например, тестировщик не поймет, что проверять в рамках той или иной задачи.
Как правило, в таких случаях тестировщики идут/звонят разработчикам и просят рассказать «что именно было сделано» в рамках этой задачи.
Чтобы определить точное поведение этой функциональности в будущем, например, когда появится дефект (ошибка) или когда станут необходимы изменения, разработчикам потребуется изучить исходный код этой ревизии».
где именно все работало правильно », а у тестировщиков — найти подходящий тест-кейс.
Все это влечет за собой дополнительные временные затраты по сравнению с простым чтением функциональной спецификации, которая могла быть записана аналитиком в исходной задаче.
Многие аналитики сознательно не описывают функциональную спецификацию и ограничиваются только требованиями, поскольку хотят оставить свободу выбора решения за разработчиком.
А многие разработчики даже требуют (!), чтобы задача не содержала деталей реализации и чтобы у них была свобода выбора, как именно реализовать функциональное требование.
Причин этому две: 1) желание разработчика знать, зачем вообще что-то менять; 2) наличие нескольких способов реализации одного и того же функционального требования в системе, из которых (по чистой случайности) аналитик выбрал не самый простой.
Есть и третья причина — собственное эго разработчика, но в этой статье мы ее обсуждать не будем.
Первая причина — «желание знать почему» — обсуждается ниже.
Что делать со вторым — основные моменты функционального задания рекомендуется обсудить с разработчиком.
Причем, по возможности, делайте это _до_ исправления уточнения в тексте задачи.
Если возможности обсудить нет (например, если разработчики находятся в 10 часовых поясах от вас или в компании-подрядчике), то все равно нужно прописать в задании техническое задание, а уже потом отправлять его разработчику для одобрение.
Эффективность такого подхода будет выше, поскольку время аналитика, затраченное на последующее переписывание задачи, все равно будет меньше, чем время, затраченное несколькими людьми на выяснение точного поведения системы, вызванное отсутствием спецификации задачи.
.
Часто возникает вопрос: должен ли аналитик в задаче описывать требования к базе данных, например, структуру таблиц, названия полей и т.п.
? Короткий ответ - нет. Аналитик должен указать только ту часть программного обеспечения, которая видна пользователю.
Это пользовательский интерфейс, публичные API и видимые параметры оборудования, например, размер монитора.
Да, в этой статье речь идет о программном обеспечении, но поскольку в «чистом» виде его почти никто не использует и пользователь всегда взаимодействует с программой через аппаратный уровень, в ТЗ должны быть указаны допустимые параметры этого слоя.
Еще одна распространенная ошибка как аналитиков, так и разработчиков — описание деталей реализации (по сути, функциональной спецификации) в _комментариях_ к задаче.
Более того, зачастую к одному и тому же функционалу создается несколько комментариев (это называется обсуждением).
Должно ли это быть причиной того, что нам вообще не следует использовать комментарии? Конечно нет, но промежуточные договоренности по функциональному заданию, а тем более финальные, должны быть зафиксированы в тексте задания, а не где-то еще.
И еще раз отметим, что лучший способ договориться — позвонить разработчику и обсудить основные детали голосом, а уже потом прописать их в задании.
Проблема №2. Почему это непонятно разработчику? "почему" ? Потому что проблема в том, что не хватает чего-то под названием бизнес-требование (другие названия: проблема или постановка задачи ), или, что еще чаще, исходная проблема пользователя все еще не ясна из описания бизнес-требований, поскольку описание слишком сильно относится к самому программному обеспечению, а не к бизнесу или ситуации пользователя.
Один из примеров неясного описания проблемы: «В справочниках системы реализовано поле «Английское название», но это поле ни разу не заполнялось.
Наличие пустых полей в справочниках не устраивает заказчика, т.к.
указывает на неактуальность справочников» .
Ну справочники неактуальны, и что? Кто от этого страдает? Имея небольшую дополнительную информацию, мы можем лучше описать проблему: «Администраторы клиентов тратят дополнительное время на контроль актуальности классификаторов, представленных в виде справочников.
Происходит это из-за наличия в списке элементов справочника дополнительных полей, по поводу которых непонятно, заполнять их или нет».
Что изменилось? Во-первых, стали очевидны конкретные люди, у которых проблема (администраторы).
Во-вторых, стало понятно измерение проблемы (затраты времени).
Если вы еще и понимаете, как часто проверяются классификаторы (тратится лишнее время), то вы уже можете определить приоритет проблемы (и задачи).
А если еще объяснить, почему классификаторы вообще должны быть актуальны, то получится совершенно идеальное описание.
Описание проблемы еще называют «постановкой проблемы» (см.
ссылку выше) и, хотя Голдсмит перечисляет целых 6 шагов для ее определения, имеет смысл упростить его всего до 3: Шаг 1. Описание категории пользователя; Шаг 2. Выявление и описание бизнес-проблемы пользователя, которая либо не может быть решена, либо требует дополнительных времени/денег, либо влечет за собой наказание за нарушение закона; Шаг 3. Описание недостатка в программном обеспечении, не позволяющего решить бизнес-задачу.
Это рекомендуемый порядок описания проблемы, так как никто не хочет читать лишние слова - описание ПО.
В заключение, подводя итог этим проблемам, хотелось бы отметить, на что при документировании требований аналитику следует тратить время, а на что нет. Критически важны только две вещи: документирование проблемы пользователя и документирование функциональной спецификации изменения.
Эти два пункта должны присутствовать в каждой задаче для разработчиков и тестировщиков.
Это гарантированно решит проблему, заявленную в начале статьи.
На все остальные действия, связанные с управлением и документированием требований, таких как функциональные и нефункциональные требования, пользовательские истории, сценарии использования, затрачиваемое время должно быть минимизировано, поскольку ничто из этого не объясняет самого важного: 1) что именно разрабатывать/ тест, 2) кому пользователи выиграют от этих действий и в чем их текущая проблема.
Функциональные требования необходимы, когда описание проблемы (бизнес-требования) не может охватить функциональную спецификацию, решающую проблему, из-за ее объема.
В результате создается промежуточный, более компактный слой требований, который в конечном итоге все же приводит к появлению спецификации.
Но поскольку этот слой требований является промежуточным, его желательно пропустить — это экономит время.
P.S. Шаблон описания проблемы в JIRA. Задачи (но не ошибки) форматируются в соответствии со следующими шаблонами полей.
Краткое содержание , Проблема , Описание .
Все 3 поля обязательны.
Краткое содержание :
Проблема :.Описание :
Где : .Теги: #требования #менеджер задач #спецификации #управление проектами #GTDЗадача реализации :
-
Что Мы Знаем О Лучших Ноутбуках
19 Oct, 24 -
Микрокосм, Демо-Версия
19 Oct, 24 -
Эффективные Знакомства
19 Oct, 24 -
Защитите Свой Ipod!
19 Oct, 24 -
Мой Первый Виджет
19 Oct, 24 -
Новый Детский Телефон От Firefly Mobile.
19 Oct, 24
