Технологии инженерии программ

Анализ требований

Без подходящих программистских приемов: алгоритмов, структур данных, контрактов, анализа производительности, модульной структуры, поддержки компилятора, поддержки инструментария и других изученных приемов — без всего этого проекты потерпят неудачу. Необходима технология, но ее недостаточно. Успешные системы строятся в интересах клиентов и должны соответствовать их потребностям. Анализ требований позволяет достигнуть хорошего соответствия между тем, что хотят пользователи, и тем, что делает система.

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

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

Продукты на этапе требований

Процесс создания требований должен выдавать два конкретных результата:

• документ требований, описывающий характеристики системы, которую предстоит построить;
• В&П-план (план верификации и проверки правильности), часто называемый "тест-план", описывающий, как построенная система будет оцениваться.

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

Стандарт IEEE

Существует полезный ресурс для подготовки требований: стандарт IEEE Computer Society (совместно с ACM — одной из наиболее активных профессиональных ассоциаций ИТ. Мы уже упоминали один из ее стандартов для арифметики с плавающей точкой). Стандарт "Recommended Practice for Software Requirements Specifications" ("Рекомендуемая практика специфицирования требований ПО") определяет некоторые лучшие способы задания требования, включая универсальную структуру документа требований.

Это краткий и простой стандарт. С ним стоит познакомиться, а если необходимо написать требования — то следовать рекомендуемой структуре, широко используемой в индустрии. Эта структура состоит из трех частей: введения, общего описания и специфических требований. Часть 2, помимо описания, включает перспективу продукта, функции продукта, характеристики пользователя, ограничения, предположения, зависимости, выделенные требования. Часть 3 идет глубже, уделяет внимание таким деталям системы, как внешние интерфейсы, требования к производительности, требования к базам данных.

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

Область требований

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

Еще одно важное разграничение, отмеченное ранее, — разграничение функциональных и не функциональных аспектов.

• Функциональные требования специфицируют ответы системы. "Если ввод в поле номера социальной службы является правильным номером, то система должна отобразить имя и фамилию соответствующей персоны" — это функциональное требование.
• Нефункциональное требование специфицирует все другие свойства системы, такие как производительность, доступность, простоту использования. "Отображение имени и фамилии не должно занимать более чем 0,2 секунды в 99, 5% случаев" — это пример нефункционального требования.

Обратите внимание на терминологию: "требование" — это элемент специфицируемого поведения, функционально или нефункционального, как в приведенных примерах. Требования — это коллекция таких индивидуальных элементов.

Получение требований

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

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

• Сопричастники часто имеют конфликтующие интересы — кто-то должен разрешать конфликты.
• Требования пользователей часто представляют смесь простых, осуществимых, трудных (или невозможных) свойств. У пользователей часто нет понимания, что является простым для реализации, а что трудным.
• Только команда разработчиков может оценить техническую стоимость каждой запрашиваемой функциональности; основной критерий принимаемого решения — включать ли данное требование.
• Пользователи имеют тенденцию думать в терминах существующих систем (или, в другом экстремальном случае, мечтают о системах, которые невозможно построить). Чаще всего именно разработчики могут предложить нового типа функциональность, которую пользователи не могли даже вообразить. Это общее свойство технологических инноваций: немногие прорывные продукты были спроектированы на основе пожеланий, собранных у пользователей. Технологи обычно выслушивают пользователей, а потом возвращаются к ним с собственным предложением: а что, если я дам вам следующее устройство?
• Многие внешние факторы влияют на окончательный выбор функциональности, такие как бюджет, существующая система, интерфейс с другими системами.

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

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

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

Приемы для сбора требований включают:

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

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

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

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

Глоссарий

Одним из продуктов, входящим в состав требований, должен быть глоссарий (в стандарте IEEE это раздел 1.3 "Определения, акронимы, аббревиатуры").

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

Свойства проблемной области и машинные (системные) свойства

При написании требований всегда следует четко разграничивать машинные и проблемные свойства (о чем убедительно сказано в книге Майкла Джексона, см. ссылку в конце лекции).

Рис. 10.1. Майкл Джексон (2004)

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

• Никакая передача не должна быть принятой, если в результате баланс счета становится ниже установленного предела. Это проблемное свойство, оно следует в данном случае из правил, принятых в бизнесе.
• Любая передача, в результате которой баланс счета становится ниже установленного предела, должна приводить к посылке сообщения менеджеру счетов. Это машинное свойство, которое описывает частное решение, принятое в системе (в фактическом документе требований оно должно быть сформулировано более точно). Данное машинное требование непосредственно следует из приведенного проблемного требования. Не все машинные требования являются следствиями проблемных. Некоторые отражают чисто системные решения.

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

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

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