Оговоренные требования к ПО

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

Основной закон: требования должны быть документированы. Однажды я занимался проектом, который делала опытнейшая команда, однако ее состав постоянно менялся. Заказчик впал в неистовство, когда, к нему пришел еще один аналитик требований и сказал: «Мы должны поговорить о том, что же вам нужно». На что заказчик ответил: «Я уже излагал свои требования. А теперь постройте мне систему!» Дело в том, что никто не документировал собранную информацию, поэтому каждому новому аналитику приходилось начинать с набросков. Полный бред объявлять о готовности требований, если на самом деле у вас есть куча электронных писем, голосовых сообщений, записок, протоколов совещаний и неясных воспоминаний о беседах в коридоре.

Особенности интерпретации требований

Консультант Brian Lawrence предположил, что требования - это «нечто такое, что приводит к выбору проектрования» (Lawrence, 1997). Многие категории информации попадают в эту категорию. IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;

3. Документированное представление условий или возможностей для пунктов 1 и 2.

Это определение охватывает требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Термин пользователи следует распространить на всех заинтересованных лиц, так как не все, кто заинтересован в проекте — пользователи. Я думаю о требованиях, как о свойствах, которыми должен обладать продукт, чтобы представлять какую-то ценность для пользователей. Следующее определение подтверждает различие типов требований (Sommerville и Sawyer, 1997):

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

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

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

В этом разделе приводятся определения, которыми я буду пользоваться для терминов, наиболее часто применяемых у такой сфере, как разработка требований. Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. 1-1 иллюстрирует способ представления этих типов требований. Как и все модели, она не полная, но схематично показывает организацию требований. Овалы обозначают типы информации для требований, а прямоугольники — способ хранения информации (документы, диаграммы, базы данных).

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга или «провидец» продукта. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Создание такого документа описано в главе 5. Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ.

Рис. 1-1. Взаимосвязи нескольких типов информации для требований

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие - отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы. Пример варианта использования — «Сделать заказ» для заказа билетов на самолет, аренды автомобиля, заказа гостиницы через Интернет.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе». Как иллюстрируется в главе 10, функциональные требования описывают, что разработчику необходимо реализовать.

Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространиться и на людей.

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

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Как вы увидите в главе 9, бизнес-правила не являются требованиями к ПО, потому что они находятся вне границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, (подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.

Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы. Я буду относиться к спецификации, как к документу, хотя это может быть база данных или крупноформатная таблица с требованиями, хранилище данных в коммерческом инструменте управления требованиями (см. главу 21) или даже, может быть, куча карточек для небольшого проекта. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и связанных с проектом функциях..

В дополнение к функциональным требованиям спецификация содержит нефункциональные, где описаны цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения проектирования и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

Люди часто рассуждают о характеристиках продукта. Характеристика(feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта. Характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки Web-браузера, контроль за орфографией, запись макрокоманды, сервопривод стекла в автомобиле, on-line- обновление или изменение налогового кодекса, ускоренный набор телефонного номера или автоматическое определение вируса. Характеристики могут охватывать множество вариантов использования, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач.

Чтобы вы лучше восприняли некоторые из различных видов требований, я рассмотрю программу подготовки текстов. Бизнес-требование может выглядеть так: «Продукт позволит пользователям исправлять орфографические ошибки в тексте эффективно». На коробке CD-ROM указано, что проверка грамматики включена как характеристика, удовлетворяющая бизнес-требование. Соответствующие требования пользователей могут содержать задачи (варианты использования) вроде такой: «Найдите орфографическую ошибку» или «Добавьте слово в общий словарь». Проверка грамматики имеет множество индивидуальных функциональных требований, которые связаны с такими операциями, как поиск и выделение слова с ошибкой, отображение диалогового окна с фрагментом текста, где это слово находится, и замена слова с ошибкой корректным вариантом по всему тексту. Атрибут качества легкость и простота использования (usability) как раз и определяет его значение посредством слова «эффективно» в бизнес-требованиях.

Менеджеры и сотрудники отдела маркетинга определяют бизнес-требования для ПО, которые помогут их компании работать эффективнее (для информационных систем) или успешно конкурировать на рынке (для коммерческих продуктов). Каждое требование пользователя должно быть сопоставлено бизнес-требованию. На основе требований пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки налагаемых ограничений.

Хотя в модели на рис. 1-1 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-тpeбованиями, требованиями пользователей и функциональными требованиями. Кто бы, когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить; «Они попадают в указанные границы?» Если ответ «да», то они соответствуют спецификации. Если — «нет», то на «нет», как известно, и суда нет. А вот если ответ «нет, но они должны там быть», то заказчик или тот, кто финансирует проект, должен решить, готов ли он раздвинуть границы проекта, чтобы принять новое требование.