Глава 3. Хорошие приемы создания требований

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

Понятие «лучших приемов» довольно спорно: кто решает, что лучше, и на каком основании? Можно создать группу экспертов или исследователей и проанализировать проекты различных организаций (Browr, 1996; Brown, 1999; Dutta, Lee и Van Wassenhove, 1999).Таким образом, вам удастся выявить приемы, которые обычно эффективно применялись в успешных проектах, а в неудачных — показали себя плохо или не применялись вообще. В процессе работы эксперты согласованно определяют, какие действия неизменно дают превосходный результат обычно их называют лучшими приемами. Подразумевается, что это — высокоэффективные способы, которые при работе над определенными проектами и в определенных ситуациях существенно повышаю шансы профессиональных разработчиков ПО на успех.

В табл. 3-1 перечислено приблизительно 50 приемов; они разделены на 7 категорий. Надеюсь, они помогут разработчикам более эффективно формулировать требования. Некоторые приемы относятся к нескольким категориям, но в таблице они указаны только один раз. Приемы годятся не для всех ситуаций, и поэтому не стоит слепо следовать сценарию, а руководствоваться трезвым расчетом, здравым смыслом и опытом. Заметьте: не все из указанных приемов относятся к лучшим, проверенным практикой отрасли, и именно поэтому глава называется «Хорошие приемы создания требований», а не «Лучшие приемы». Сомневаюсь, что когда-либо будет проведена систематическая оценка всех их на предмет выбора лучшего. Тем не менее, многие практики, и я в том числе, считают данные способы эффективными (Sommerville и Sawyer, 1997; Hofmann и Lehner, 2001). Я кратко описываю каждый способ, а также указываю ссылки на другие главы и источники. В заключительном разделе главы приведен примерный план формулирования требований — последовательность действий, подходящая для большинства проектов по разработке ПО.

Таблица 3-1. Приемы формулирования требований

Обучение

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

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

· в главе 4 — об обучении аналитиков требований;

· в главе 10 — о создании бизнес-словаря проекта.

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

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

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

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

Выявление требований

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

· в главе 3 — о процессе формулирования требований;

· в главе 5 — об определении образа и границ проекта;

· в главе 6 — об определении классов пользователей и их характеристик, выборе сторонника продукта из каждого класса пользователей, наблюдении за пользователями на рабочих местах;

· в главе 7 — о проведении совместных семинаров;

· в главе 8 — о работе с представителями пользователей, определении системных событий и реакции на них;

· в главе 22 — об определении процесса формулирования требований.

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

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

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

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

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

Работа с пользователями для выяснения назначения продукта. Выясните у пользователей, какие задачи им требуется выполнять средствами ПО. Обсудите, как должен клиент взаимодействовать с системой для выполнения каждой такой задачи. Воспользуйтесь стандартным шаблоном для документирования всех задач и для каждой сформулируйте функциональные требования. Похожий способ, часто применяемый в правительственных проектах, — создать документ с концепциями операций (ConOps), где указаны характеристики новой системы с точки зрения пользователя (IEEE, 1998а).

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

Проведение совместных семинаров. Совместные семинары по выявлению требований, где тесно сотрудничают аналитики и клиенты — отличный способ выявить нужды пользователей и составить наброски документов с требованиями (Gottesdiener, 2002). Конкретные примеры таких семинаров - Joint Requirements Planning (JRP — совместное планирование требований) (Martin, 1991) и Joint Application Development (JAD-совместная разработка приложений) (Wood и Silver, 1995).

Наблюдение за пользователями на рабочих местах. Наблюдая за работой пользователей, выявляют контекст потенциального применения нового продукта (Beyer и Holtzblatt, 1998). Простые диаграммы рабочих потоков, а также диаграммы потоков данных позволяют выяснить, где, как и какие данные задействовал пользователь. Документируя ход бизнес-процесса, удается определить требования к системе предназначенной для поддержки этого процесса. Иногда даже выясняется, что для выполнения деловых задач клиентам вовсе и не требуется новое ПО (McGraw и Harbison, 1997).

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

Повторное использование требований в разных проектах. Если необходимая клиенту функциональность аналогична уже реализованной в другом продукте, подумайте, готовы ли клиенты гибко пересмотреть свои требования для использования существующих компонентов. Требования, соответствующие бизнес-правилам компании, можно применить в нескольких проектах. Это требования к безопасности определяющие порядок доступа к приложениям, и требования, соответствующие постановлениям правительства, например Закон о гражданах США с ограниченными возможностями (Americans with Disabilities Act).

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

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

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

· в главе 5 — о создании контекстной диаграммы;

· в главе10 — о создании словаря данных;

· в главе 11 — о моделировании требований;

· в главе 13 — о создании пользовательского интерфейса и технических прототипов;

· в главе14 — об определении приоритетов требований;

· в главе 17 — о распределении требований по подсистемам.

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

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

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

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

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

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

Распределение требований по подсистемам. Требования к сложному продукту, включающему несколько подсистем, следует соразмерно распределять между программными, аппаратными и операторскими подсистемами и компонентами (Nelsen, 1990). Как правило, это осуществляет системный инженер или разработчик.

Применение технологий развертывания функций качества. Технология развертывания функций качества (Quality Function Deployment, QFD) — точная методика, соотносящая возможности и атрибуты продукта с их значимостью для клиента (Zultner, 1993; Pardee, 1996). Она позволяет аналитически выявить функции, которые максимально удовлетворят потребности клиента.

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

Спецификации требований

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

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

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

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

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

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