Для чего нужны требования
Требования
В англоязычной литературе для запоминания признаков хороших требований используется аббривиатура SMART.
Необходимость. Если имеется сомнение в необходимости требования, необходимо просто задать себе вопрос: “А что плохого случится с системой, если данное требование не будет включено в перечень?”. Если у вас нет ответа на данный вопрос, то, вероятно, данное требование не нужно.
Проверяемость. Как только требование сформулировано, нужно определить, как его можно верифицировать. Для этого необходимо выбрать соответствующий критерий соответствия.
Достижимость. Чтобы быть достижимым, требование должно быть технически реализуемым в заданные сроки и по заданной цене, в условиях существования дополнительных ограничений. Если существует неопределенность в технической реализуемости требования, необходимо провести соответствующее исследование или дополнительное изучение вопроса. Если и после этого неопределенность остается, нужно сформулировать цель, а не требование. Понятно, что даже если требование технически выполнимо, оно может быть недостижимым из-за стоимостных, временных или других, например весовых ограничений. Бессмысленно формулировать требование на что-то невыполнимое, необходимо быть прагматичным.
Понятность. Каждое требование должно выражать единственную мысль, быть лаконичным и простым. Важно, чтобы требование было понятным и недвусмысленным. Для хороших требований часто достаточно простых предложений.
Требование должно формулироваться в положительной манере и никогда не начинаться с отрицания, оно должно быть грамматически правильным, без опечаток и пропусков. На всех уровнях системы, должна применяться одинаковая терминология.
Что такое требования и зачем они нужны
Что такое требования
Требования – это точно сформулированное описание совокупности полезных для пользователя характеристик, ожидаемых им от продукта. Продуктом в данном случае может являться предмет, используемый человеком в быту и на производстве (например: автомобиль, компьютер, дом), услуга (стрижка, перевозка груза), работа или результат работ (строительство или ремонт объекта).
Примером требования, предъявляемого к автомобилю, может являться максимальный расход топлива – не более 11 литров на 100 км пробега по городу.
Иными словами, требование – это то, что мы ожидаем получить, приобретая товар, заказывая работу или услугу, те свойства и функциональность, которые делают их полезными для нас.
Зачем нужно записывать требования
Если Вы хотите купить рубашку, то Вам нужно решить, какого она должна быть цвета, из какого материала и какого фасона, и рассказать о Ваших желаниях продавцу, чтобы он помог выбрать именно то, что нужно. В этом случае документирование требований излишне. Достаточно, чтобы Вы их помнили.
Однако, при создании компьютерной программы, которая должна выполнять множество действий, без разработки документа, описывающего требования, не обойтись. Если разработчики не получат полного и ясного описания того, что должна делать программа, то результат скорее всего не обрадует заказчика. Разработчики не являются ясновидящими и сделают лишь то, что описано в требованиях. Некоторые разработчики могут добавить в программу что-нибудь от себя, но не обязательно это будет нужно заказчику. Если в требованиях не будет сказано, что программа должна сохранять созданные в ней данные в файл, то в последствии Вы будете неприятно удивлены, потеряв результаты работы после закрытия программы. Чтобы такого не произошло, включите в документ все характеристики и все функции, которые должна выполнять программа. Не следует думать, что очевидные Вам вещи будут также очевидны и другим людям.
Кроме того, что в документе, передаваемом разработчикам, должны быть описаны все функции программы, они должны быть описаны ясно и не двусмысленно. Используемые формулировки и термины должны одинаково трактоваться всеми участниками работы над программой. Хорошей практикой является включение в документ с требованиями словаря используемых в нем терминов.
Здесь кратко описана важность документирования требований при разработке программного обеспечения, но оно также необходимо и в проектировании машин, электроники, зданий и сооружений, планировании приобретения сложных и дорогостоящих изделий и во многих других видах деятельности.
Чуть подробнее о том, какие бывают требования
Приступая к работе над проектом, необходимо определить цели этого проекта. Например, целью проекта внедрения новой компьютерной системы может быть снижение среднего времени обслуживания клиента на X минут, за счет этого увеличение на Y количества обслуженных за месяц клиентов и, как следствие, увеличение месячного дохода компании на Z. Целей может быть несколько. Например, уменьшение среднего времени обслуживания клиентов на X минут и сокращение издержек на Y рублей за счет уменьшения бумажного документооборота.
Формулируя цели проекта, необходимо указать критерии для проверки их достижения. То есть, недостаточно просто указать, что в результате внедрения компьютерной системы должно сократиться среднее время обслуживания клиента, но также необходимо указать минимальное значение этого сокращения.
Необходимо начинать разработку требований с формулирования целей проекта, так как, не определившись с целью, нельзя сказать, нужна ли та или иная функциональность. Формулирую требование, подумайте, будет ли способствовать его реализация достижению целей проекта. Включение в проект требований, не отвечающих целям проекта, приведет к росту затрат на разработку, но не добавит полезной функциональности.
Способы представления требований могут быть различны: простое текстовое описание, подробное описание сценария взаимодействия пользователя с компьютерной программой или каким-либо устройством, схемы, таблицы сигнал-реакция и т.д.
Для выражения требования необходимо выбирать наиболее подходящий в каждом конкретном случае способ. Иногда достаточно краткого описания в произвольной форме. Для описания взаимодействия двух систем хорошо подходит таблица сигнал-отклик или диаграмма взаимодействия. При разработке компьютерных программ часто используют сценарии взаимодействия пользователя с системой. При необходимости реализации сложного алгоритма его представляют с помощью блок-схемы и т.д.
В других случаях пользовательских требований оказывается недостаточно. Например, при разработке компьютерной программы сначала собирают пользовательские требования, а затем уточняют, создавая на их основе « варианты использования», которые более подробно описывают процесс взаимодействия человека с компьютером или двух компьютерных систем. «Варианты использования» в разных источниках называют так же прецедентами и сценариями взаимодействия.
Вариант использования фиксирует соглашение между участниками системы о ее поведении. Он описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях. Основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Различные модели поведения, или сценарии, развертываются в зависимости от определенных запросов и условий, при которых делались эти запросы. Вариант использования собирает вместе эти сценарии.[1].
В качестве примера приведу вариант использования «Сохранение проекта» для системы управления требованиями:
Предусловия
Результат
Основной поток
Альтернативный поток
Исключения
Вариант использования является не только способом фиксации требования, работа над ними способствует выявлению новых требований. Так при обсуждении с заказчиками и потенциальными пользователями сценария взаимодействия с системой часто удается услышать от них подробности, которые могли ускользнуть, так как о них никто не вспоминал или они казались несущественными.
В своих проектах я фиксирую ошибки и недостатки, выявленные при тестировании. Они становятся основой для формулирования новых вариантов использования и исправления существующих.
Помимо описания функционирования системы, требования могут включать такие ожидания пользователей, как удобство интерфейса, надежность, быстродействие. Такие требования называют атрибутами качества [2]. Атрибуты качества должны учитываться при выборе архитектуры и средств реализации проекта.
Компьютерные программы и создаваемые ими документы часто должны соответствовать корпоративной политике, промышленным стандартам или правительственным постановлениям. Эти требования называют бизнес-правилами. Их текст не следует полностью переносить в описание требований проекта, достаточно включить ссылки на соответствующие документы, чтобы разработчики могли учесть их при создании программы.
При разработке требований не следует пытаться сразу сформулировать их в окончательном виде. Скорее всего в ходе работы над проектом требования будут изменяться – появляться новые, изменяться существующие. Не следует до бесконечности пытаться улучшить используемые в требованиях формулировки. Главное, чтобы они были достаточно полными и не допускали неоднозначного понимания.
Зачем нужны системы управления требованиями
Использование специализированных средств для управления требованиями позволяет избежать этих трудностей. Многие системы автоматически сохраняют все изменения требований в базе данных, позволяют отслеживать влияние изменения одного требования на другие связанные с ним требования, обеспечивают совместную работу над проектом нескольких участников и регулируют возможности по внесению изменений в соответствии с присвоенными им ролями. Системы управления требованиями позволяют значительно снизить трудоемкость работы с требованиями.
Требования к ПО на пальцах
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры. Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Спасибо за внимание и удачного проектирования.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
Reqs_definition
Требования к программному обеспечению: что это такое и зачем?
Зотова Алина Александровна
Инженерия требований – это про работу с требованиями, а не про любование их структурным совершенством.
Всем знакомо понятие жизненного цикла программного обеспечения, который состоит из периода разработки и эксплуатации программного обеспечения. Первые из семи этапов: 1) возникновение и исследование идеи, 2) анализ требований и проектирование. И если с первым этапом все хорошо знакомы (идеи придумывать умеют все!), то с документированием и описанием идеи иногда возникают сложности. И еще до того момента, как будет принято решение о начале разработки, проходит этап анализа.
У Карла И. Вигерса мы находим такое определение: «анализ требований — это процесс сбора требований к программному обеспечению, их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов».
Следует различать выявление требований (тот самый второй этап жизненного цикла) и управление требованиями (на всех этапах). Под управлением требованиями понимается поддержание документации в актуальном состоянии и использование их для разработки. Так как тема требований к ПО обширна и неоднозначна, мы будем рассматривать только выявление требований, которое происходит на первых этапах работы над проектом.
В англоязычной среде эту дисциплину называют «Инженерия требований» (Requirements Engineering), а специалиста по выявлению и работе с требованиями называют инженером по требованиям. В обязанности такого специалиста входит выявление всех заинтересованных сторон, их потребностей и интересов, переговоры и коммуникация между заинтересованными сторонами, формулирование и согласование самих требований.
Инженерия требований по Лапланту (2007) входит в состав дисциплин системной инженерии и инженерии программного обеспечения, которую считают связанной с определением целей, функций и ограничений систем аппаратного и программного обеспечения. В некоторых моделях жизненного цикла процесс инженерии требований начинается с изучения технико-экономических показателей, которая ведет к написанию ТЭО. Если такое исследование подтверждает целесообразность разработки продукта, то начинается процесс инженерии требований.
Что же такое требования?
Требованиями к программному обеспечению называют описания различных аспектов разрабатываемой системы в совокупности с деонтическими понятиями. Это нормативные понятия, модальности долженствования — характеристики практического действия с точки зрения определенной системы норм. Нормативный статус действия обычно выражается понятиями «обязательно», «разрешено», «запрещено», «(нормативно) безразлично», используемыми в нормативном высказывании. Например, «дизайн пользовательского интерфейса должен быть выполнен в светлых тонах»
Различают следующие виды требований:
В индустрии приняты такие понятия, как «заказчик», «исполнитель», «пользователь», где заказчиком часто считают того, кто платит деньги, исполнителем – того, кто реализует проект и получает за это деньги, а пользователем – тех, кто будет решать свои личные и рабочие задачи с помощью разработанного программного обеспечения. Но когда доходит дело до реального проекта, то оказывается, что кроме непосредственно заказчика, в проектировании и реализации проекта заинтересованы и другие люди.
Например, если вы создаете электронную версию периодического издания, то помимо инвестора и группы программистов, отстаивать свои интересы будет не только редакция этого издания, но и рекламодатели, которые размещают там свои материалы. Редакция и читатели этого издания будут пользователями этой системы, но интересы и потребности будут разные. Если редакции важно быстро проверять материал на фактические ошибки и выкладывать его без задержек, то читателям будет важна хорошая читаемость текста, наличие иллюстрации и возможность обсуждать статьи. Все они будут являться заинтересованными сторонами.
Заинтересованными сторонами (StakeHolders) называются лица или организации (юридические лица, компании), имеющие значимый интерес к разрабатываемой системе, которых она затрагиваемые прямо или косвенно. В 1990-х годах основной акцент был сделан на выявлении всех заинтересованных сторон. Все чаще признают, что заинтересованные стороны не ограничиваются организациями, нанимающими аналитиков. Заинтересованными сторонами могут быть:
В нашей стране тех, кто работает с требованиями к программному обеспечению, называют системными аналитиками. Обычно эти специалисты имеют высшее техническое образование, дотошны, обращают внимание на детали и вооружены системным подходом. Знания, которые считают необходимыми для этой специальности:
А ведь выявление требований – это работа с людьми! Как написано во всех учебниках, и нженерия требований – это социотехническая дисциплина. Именно поэтому, помимо технических знаний, профессионал в области выявления требований должен обладать и коммуникативными навыками: он корректен в общении, умеет активно слушать и задавать открытые вопросы, выстраивать позитивные отношения с заинтересованными сторонами, умеет организовать диалог, предотвращать и разрешать потенциально конфликтные ситуации, помогает сторонам находить компромиссы.
Зачем нужны требования, может без них лучше?
Когда мы создаём программный продукт, то хотим, чтобы продукт был полезным и нужным его потребителю-пользователю. Это называют «делать правильный продукт». Ещё важно, чтобы создание продукта происходило достаточно быстро, то есть, чтобы мы успевали вывести продукт на рынок (для массового продукта) и/или чтобы его создание окупалось и происходило вовремя (более важно для заказных продуктов). Это называют «делать продукт правильно».
В любом проекте есть риски того, что мы делаем продукт недостаточно правильно и недостаточно правильный. Так вот чтобы снижать эти риски и существуют требования. Да, без требований в зафиксированном виде можно обойтись, но только чем сложнее проект, тем больше вероятность допустить ошибку в его проектировании. Ошибки возникают по причине несогласованности представления о том, что и зачем делать между разными участниками проектной команды, что приводит к конфликтам, несогласованностям, повторным решениям, потере информации, времени и неуспеху продукта и проекта в целом.
Как фиксировать требования? Нужны ли документы?
Требования можно фиксировать по-разному — сплошным текстом, сценариями, перечнем утверждений, иерархическим списком, макетами интерфейса, диаграммами, и даже работающими прототипами продукта. Классическим является подход, когда требования в виде иерархического списка записывают в текстовый документ.
Более зрелый промышленный подход для больших и сложных проектов — занесение их в специализированную базу данных со связями и дополнение различными моделями. С такой базой могут одновременно работать множество людей, она позволяет вести учёт изменений и проводить анализ набора требований (зависимости, покрытие, влияние, конфликты), который повышает их качество.
Для не очень сложных продуктов, основную ценность которых представляет взаимодействие с пользователями (например, веб-сайтов), требования могут фиксироваться в виде бумажных макетов, моделей навигации и комментариев.
Как собирать требования?
Существует множество методов выявления требований — 1) опрос будущих пользователей продукта (интервью, анкеты); 2) наблюдение за работой пользователей; 3) изучение правил их работы по существующим регламентам/законодательству, 4) анализ технических журналов использования существующего продукта («логи»), 5) изучение продуктов конкурентов, 6) мозговые штурмы с экспертами и представителями пользователей, 7) проведение маркетинговых исследований и 8) моделирование поведения людей с применением психологических и вероятностных моделей.
Как выбрать подходящий метод?
Это зависит от категории продукта (домашняя веб-страничка, программа для домашнего пользователя, программная система автоматизирующую работу атомной станции), и, следовательно, связанных с ней допустимых сроков разработки, стоимости и качества (безопасности, надёжности, производительности, удобства).
Если программа делается для конкретных людей, которых мы знаем и к которым имеем доступ (заказная разработка), то удобно использовать наблюдение, интервью, мозговой штурм, анализ регламентов.
Если программа делается для большого рынка (словарь-переводчик, веб-сервис почты), то стоит пристально изучить продукты конкурентов (потому что именно они в основном определяют ожидания будущих пользователей относительно того, каким должен быть продукт), провести маркетинговое исследование, проанализировать журналы использования продукта (статистика посещения страниц для сайта).
При автоматизации большого предприятия может понадобиться большая трудоёмкая и довольно дорогостоящая предварительная работа по описанию его бизнес-процессов и выделению тех участков, которые нуждаются в автоматизации.
Литература:
Видео-лекции «Введение в системную инженерию» Анатолия Левенчука: