Требования – это точно сформулированное описание совокупности полезных для пользователя характеристик, ожидаемых им от продукта. Продуктом в данном случае может являться предмет, используемый человеком в быту и на производстве (например: автомобиль, компьютер, дом), услуга (стрижка, перевозка груза), работа или результат работ (строительство или ремонт объекта).
Примером требования, предъявляемого к автомобилю, может являться максимальный расход топлива – не более 11 литров на 100 км пробега по городу.
В повседневной жизни мы постоянно формулируем требования: при покупке телевизора (решаем, какие нужны тип монитора, диагональ, ...), при посещении парикмахерской (указываем, как стричь) и т.д.
Иными словами, требование – это то, что мы ожидаем получить, приобретая товар, заказывая работу или услугу, те свойства и функциональность, которые делают их полезными для нас.
Если Вы хотите купить рубашку, то Вам нужно решить, какого она должна быть цвета, из какого материала и какого фасона, и рассказать о Ваших желаниях продавцу, чтобы он помог выбрать именно то, что нужно. В этом случае документирование требований излишне. Достаточно, чтобы Вы их помнили.
Однако, при создании компьютерной программы, которая должна выполнять множество действий, без разработки документа, описывающего требования, не обойтись. Если разработчики не получат полного и ясного описания того, что должна делать программа, то результат скорее всего не обрадует заказчика. Разработчики не являются ясновидящими и сделают лишь то, что описано в требованиях. Некоторые разработчики могут добавить в программу что-нибудь от себя, но не обязательно это будет нужно заказчику. Если в требованиях не будет сказано, что программа должна сохранять созданные в ней данные в файл, то в последствии Вы будете неприятно удивлены, потеряв результаты работы после закрытия программы. Чтобы такого не произошло, включите в документ все характеристики и все функции, которые должна выполнять программа. Не следует думать, что очевидные Вам вещи будут также очевидны и другим людям.
Кроме того, что в документе, передаваемом разработчикам, должны быть описаны все функции программы, они должны быть описаны ясно и не двусмысленно. Используемые формулировки и термины должны одинаково трактоваться всеми участниками работы над программой. Хорошей практикой является включение в документ с требованиями словаря используемых в нем терминов.
Корректно сформулированные и задокументированные требования необходимы всем участникам проекта по разработке программного обеспечения:
Здесь кратко описана важность документирования требований при разработке программного обеспечения, но оно также необходимо и в проектировании машин, электроники, зданий и сооружений, планировании приобретения сложных и дорогостоящих изделий и во многих других видах деятельности.
Приступая к работе над проектом, необходимо определить цели этого проекта. Например, целью проекта внедрения новой компьютерной системы может быть снижение среднего времени обслуживания клиента на X минут, за счет этого увеличение на Y количества обслуженных за месяц клиентов и, как следствие, увеличение месячного дохода компании на Z. Целей может быть несколько. Например, уменьшение среднего времени обслуживания клиентов на X минут и сокращение издержек на Y рублей за счет уменьшения бумажного документооборота.
Формулируя цели проекта, необходимо указать критерии для проверки их достижения. То есть, недостаточно просто указать, что в результате внедрения компьютерной системы должно сократиться среднее время обслуживания клиента, но также необходимо указать минимальное значение этого сокращения.
Необходимо начинать разработку требований с формулирования целей проекта, так как, не определившись с целью, нельзя сказать, нужна ли та или иная функциональность. Формулирую требование, подумайте, будет ли способствовать его реализация достижению целей проекта. Включение в проект требований, не отвечающих целям проекта, приведет к росту затрат на разработку, но не добавит полезной функциональности.
Способы представления требований могут быть различны: простое текстовое описание, подробное описание сценария взаимодействия пользователя с компьютерной программой или каким-либо устройством, схемы, таблицы сигнал-реакция и т.д.
Для выражения требования необходимо выбирать наиболее подходящий в каждом конкретном случае способ. Иногда достаточно краткого описания в произвольной форме. Для описания взаимодействия двух систем хорошо подходит таблица сигнал-отклик или диаграмма взаимодействия. При разработке компьютерных программ часто используют сценарии взаимодействия пользователя с системой. При необходимости реализации сложного алгоритма его представляют с помощью блок-схемы и т.д.
Пользовательское требование - это самый простой тип записи требований. Оно представляет собой краткое описание функции или характеристики системы, написанное на языке, понятном потребителю. Часто такого типа требований оказывается достаточно для проекта. Например, при планировании приобретения компьютерной системы необходимо составить список функций, которые должна реализовывать система, с их кратким описанием. Этот список используется для проверки того, какие системы, представленные на рынке, подойдут заказчику.
В других случаях пользовательских требований оказывается недостаточно. Например, при разработке компьютерной программы сначала собирают пользовательские требования, а затем уточняют, создавая на их основе «варианты использования», которые более подробно описывают процесс взаимодействия человека с компьютером или двух компьютерных систем. «Варианты использования» в разных источниках называют так же прецедентами и сценариями взаимодействия.
Вариант использования фиксирует соглашение между участниками системы о ее поведении. Он описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях. Основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Различные модели поведения, или сценарии, развертываются в зависимости от определенных запросов и условий, при которых делались эти запросы. Вариант использования собирает вместе эти сценарии.[1].
В качестве примера приведу вариант использования «Сохранение проекта» для системы управления требованиями:
Как видим, вариант использования включает информацию о:
Вариант использования является не только способом фиксации требования, работа над ними способствует выявлению новых требований. Так при обсуждении с заказчиками и потенциальными пользователями сценария взаимодействия с системой часто удается услышать от них подробности, которые могли ускользнуть, так как о них никто не вспоминал или они казались несущественными.
В своих проектах я фиксирую ошибки и недостатки, выявленные при тестировании. Они становятся основой для формулирования новых вариантов использования и исправления существующих.
Помимо описания функционирования системы, требования могут включать такие ожидания пользователей, как удобство интерфейса, надежность, быстродействие. Такие требования называют атрибутами качества [2]. Атрибуты качества должны учитываться при выборе архитектуры и средств реализации проекта.
Компьютерные программы и создаваемые ими документы часто должны соответствовать корпоративной политике, промышленным стандартам или правительственным постановлениям. Эти требования называют бизнес-правилами. Их текст не следует полностью переносить в описание требований проекта, достаточно включить ссылки на соответствующие документы, чтобы разработчики могли учесть их при создании программы.
При разработке требований не следует пытаться сразу сформулировать их в окончательном виде. Скорее всего в ходе работы над проектом требования будут изменяться – появляться новые, изменяться существующие. Не следует до бесконечности пытаться улучшить используемые в требованиях формулировки. Главное, чтобы они были достаточно полными и не допускали неоднозначного понимания.
Более подробно о разработке требований можно прочитать в книгах:
Можно хранить требования в текстовом файле или электронной таблице. Но у такого способа есть ряд недостатков:
Использование специализированных средств для управления требованиями позволяет избежать этих трудностей. Многие системы автоматически сохраняют все изменения требований в базе данных, позволяют отслеживать влияние изменения одного требования на другие связанные с ним требования, обеспечивают совместную работу над проектом нескольких участников и регулируют возможности по внесению изменений в соответствии с присвоенными им ролями. Системы управления требованиями позволяют значительно снизить трудоемкость работы с требованиями.
