Вопрос 3. Спецификации требований.

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

Подробнее о приемах по спецификациям к требованиям — в следующих главах:

главе 9 — о документировании бизнес-правил;

главе 10 — об использовании шаблона спецификации требований к ПО, о присвоении уникальных идентификаторов всем требованиям;

главе 12 — об указании атрибутов качества.

Следует придерживаться следующих принципов:

Использовать шаблоны спецификации требований к ПО. Создайте стандартный шаблон для документирования требований к ПО в вашей организации. Шаблон предоставляет согласованную структуру, позволяющую фиксировать описания нужной функциональности, а также прочую информацию, касающуюся требований. Вместо того чтобы изобретать новый шаблон, модифицируйте один из существующих в соответствии со спецификой проекта. Многие компании начинают с использования шаблона спецификации требований к ПО, описанного в стандарте IEEE 830-1998 (IEEE, 1998b). Если ваша компания занимается разными проектами, например проектирует новое крупное приложение и параллельно дорабатывает версии старых программ, создайте соответствующие шаблоны для всех типов проектов. Шаблоны и процессы должны быть масштабируемыми.

Определять источники требований. Чтобы гарантировать, что все заинтересованные лица понимают, почему то или иное требование зафиксировано в спецификации требований к ПО, и упростить последующее прояснение требований, выявите источники всех требований. Это может быть вариант использования или другая информация от пользователей, системное требование высокого уровня, бизнес-правило или иной внешний фактор. Указав всех лиц, заинтересованных в каждом требовании, вы будете знать, к кому обратиться при поступлении запроса на изменение. Источники требований устанавливают на основе связей или определяют для этой цели атрибут требования.

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

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

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

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

1. Определение системы (System definition). Содержание этого документа определяет высокоуровневые требования, часто стратегические цели для достижения которых создается система. Принципиальным моментом является то, что такой документ описывается с точки зрения домена ПрО, и следовательно изложение требований ведется в терминах прикладной предметной области;

2. Системные требования (System requirements) – документ, описывающий программную систему в контексте системной инжинирии, описывает деятельность системных инженеров и выходит за рамки обсуждения инжинирии / реинжинирии ПО;

3. Программные требования (Software requirement) – устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее стоит ожидать. Может включать процедуру проверки получаемого ПО на соответствие предъявляемых к нему требований, вплоть до содержания планов тестирования; характеристики, определяющие качество и методы его оценки; вопросы безопасности и т.д. Часто такие требования создаются на естественном языке. Задача состоит в том, чтобы требования были ясны и связи между ними прозрачны, а содержание спецификации не допускало разночтений и интерпретаций, способных привести к созданию продукта, не соответствующего потребностям заинтересованных лиц.

Признаки проблем спецификаций:

- терминологическая неопределенность – естественный язык неизбежно обладает неопределенностью из-за многозначности слов, и следовательно такие слова должны однозначно определяться в глоссарии;

- отсутствие представления о классификации требований;

- фокусировка на деталях пользовательского интерфейса;

- излишнее акцентирование на деталях реализации;

- слабая формализация бизнес-процеса.