Разработка и анализ требований к программному обеспечению

МИНОБРНАУКИ РОССИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ САМАРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Кафедра «Вычислительная техника» Разработка и анализ требований к программному обеспечению Конспект лекций Самара 2015 Содержание 1. Введение 5 2. Основные положения 6 2.1. Цели разработки требований 6 2.2. Участники разработки требований 6 2.2.1. Основные задачи разработки требований 6 2.2.2. Группа разработки требований 7 2.2.3. Права заказчика 8 2.2.4. Обязанности заказчика 8 2.2.5. Обязанности аналитика требований 8 2.3. Классификация требований 9 2.3.1. Бизнес-требования 10 2.3.2. Бизнес-правила 10 2.3.3. Требования пользователей 11 2.3.4. Системные требования 11 2.3.5. Атрибуты качества 11 2.3.6. Внешний интерфейс 11 2.3.7. Ограничения 11 2.3.8. Функциональные требования 11 2.3.9. Нефункциональные требования 12 2.4. Классификация бизнес-правил 12 2.4.1. Факты 12 2.4.2. Ограничения 12 2.4.3. Активаторы операций 13 2.4.4. Выводы 13 2.4.5. Вычисления 13 2.5. Классификация атрибутов качества 14 2.5.1. Атрибуты, важные для пользователей 14 2.5.1.1. Доступность 14 2.5.1.2. Эффективность 14 2.5.1.3. Гибкость 15 2.5.1.4. Целостность 15 2.5.1.5. Способность к взаимодействию 15 2.5.1.6. Надежность 16 2.5.1.7. Устойчивость к сбоям 16 2.5.1.8. Удобство и простота использования 16 2.5.2. Атрибуты, важные для разработчиков и специалистов по техническому обслуживанию 17 2.5.2.1. Легкость в эксплуатации 17 2.5.2.2. Мобильность 17 2.5.2.3. Возможность повторного использования 17 2.5.2.4. Тестируемость 17 2.5.3. Взаимосвязь атрибутов качества 18 2.6. Критерии качества требований 19 2.6.1. Критерии качества отдельных положений спецификации требований 19 2.6.1.1. Полнота 19 2.6.1.2. Корректность 20 2.6.1.3. Осуществимость 20 2.6.1.4. Необходимость 20 2.6.1.5. Упорядоченность по важности и стабильности 20 2.6.1.6. Недвусмысленность 20 2.6.1.7. Проверяемость 20 2.6.2. Критерии качества спецификации требований в целом 20 2.6.2.1. Полнота 20 2.6.2.2. Непротиворечивость 21 2.6.2.3. Способность к модификации 21 2.6.2.4. Трассируемость 21 2.7. Назначение приоритетов требований 21 2.7.1. Зачем определять приоритеты требований 21 2.7.2. Шкала приоритетов 22 2.8. Обеспечение ресурсами 26 2.9. Обучение 26 2.9.1. Обучение аналитиков требований 27 2.9.2. Ознакомление пользователей и менеджеров с требованиями 27 2.9.3. Ознакомление разработчиков с концепциями предметной области 27 2.9.4. Создание бизнес-словаря 27 3. Разработка требований: общие положения 27 4. Подготовка разработки требований 29 4.1. Определение бизнес-требований 29 4.2. Определение образа и границ проекта 30 4.3. Определение классов пользователей и их характеристик 31 4.4. Определение представителей пользователей 32 4.5. Определение лиц, принимающих решения 32 4.6. Выбор способов выявления требований 33 4.7. Разработка плана-графика 33 5. Выявление требований 35 5.1. Основные источники получения информации о потребностях пользователей 36 5.1.1. Опросы потенциальных пользователей и дискуссии с ними 36 5.1.2. Документы, где описан уже работающий или конкурирующий продукт 37 5.1.3. Спецификации требований к системе верхнего уровня 37 5.1.4. Отчеты об ошибках и претензии к возможностям работающей системы 37 5.1.5. Маркетинговые исследования и опросы пользователей 37 5.1.6. Наблюдение за пользователями на рабочих местах 38 5.1.7. Описание событий и реакций на них 38 5.1.8. Повторное использование требований в разных проектах 38 5.2. Основные способы выявления требований 38 5.2.1. Интервью 39 5.2.2. Проведение совместных семинаров 41 5.2.2.1. Определите основные правила 41 5.2.2.2. Придерживайтесь границ проекта 41 5.2.2.3. Фиксируйте темы для дальнейшего обсуждения 42 5.2.2.4. Ограничивайте некоторые дискуссии по времени 42 5.2.2.5. Не увеличивайте размер команды и тщательно отбирайте участников 42 5.2.2.6. Вовлекайте в обсуждение каждого 42 5.3. Специфика выявления различных требований 43 5.3.1. Бизнес-правила 43 5.3.2. Требования к производительности 43 5.3.3. Атрибуты качества 44 5.3.4. Словарь данных 44 6. Анализ требований 45 6.1. Анализ осуществимости требований 45 6.2. Определение приоритетов требований 46 6.3. Моделирование требований 47 6.4. Поиск упущенных требований 47 6.4.1. Матрица CRUDL 48 7. Документирование требований 49 7.1. Общие правила документирования 50 7.2. Правила построения идентификаторов элементов документации 51 7.3. Особенности документирования спецификации требований 52 7.4. Особенности документирования бизнес-правил 53 7.5. Формулирование требований 53 7.6. Термины, которых следует избегать в спецификации требований 54 7.7. Контроль версий 55 7.8. Контроль статуса требований 56 8. Проверка и утверждение требований 56 8.1. Просмотр требований 58 8.2. Проведение экспертизы 59 8.2.1. Участники 59 8.2.2. Роли экспертов 60 8.2.3. Входные и выходные критерии 61 8.2.4. Этапы проведения экспертизы 61 8.2.4.1. Планирование 61 8.2.4.2. Обзорная встреча 62 8.2.4.3. Индивидуальный просмотр 62 8.2.4.4. Совещание 62 8.2.4.5. Подготовка заключения 63 8.2.5. Контрольные списки дефектов 63 8.3. Возможные проблемы при просмотре требований 65 8.3.1. Большой объем документации 65 8.3.2. Большая команда экспертов 66 8.3.3. Географическое разделение экспертов 66 8.4. Тестирование требований 67 8.4.1. Тестирование требований разработчиком 67 8.4.2. Тестирование требований клиентом 69 8.5. Обобщение результатов проверки требований 69 8.6. Утверждение требований 70 Литература 71 1. Введение Целью «Положения о разработке требований к программному обеспечению» (далее – Положение) является регламентация процедур разработки требований в процессе создания заказного программного обеспечения для обеспечения управляемости и необходимого уровня качества работ. Положение предназначено для использования в области разработки заказного программного обеспечения. Положение является частью документационного обеспечения организационной системы промышленного производства заказного программного обеспечения. Утвержденное Положение имеет статус внутреннего стандарта и обязательно для исполнения в проектах разработки заказного программного обеспечения. В качестве нормативной основы при разработке данного Положения использован стандарт: IEEE Std 830-1993 «IEEE Recommended Practice for Software Requirements Specifications» Настоящее Положение разрабатывается Группой технологии разработки и утверждается Директором. Сопровождение и контроль версий Положения осуществляется Группой технологии разработки. Группа технологии разработки осуществляет сбор предложений и замечаний, которые формируются в ходе выполнения проектов разработки программного обеспечения, а также осуществляет их анализ и обобщение. По результатам анализа предложений и замечаний Группа технологии разработки разрабатывает новые и исправленные версии Положения и представляет их для утверждения. Номер версии присваивается в процессе ввода Положения в действие. При исправлении ошибок или несоответствий Положению присваивается следующий по порядку вспомогательный номер версии (после разделительной точки); при изменении и вводе в действие новых элементов организации или технологии работ, новой версии Положения присваивается следующий по порядку основной номер. При вводе в действие новой версии Положение публикуется в Intranet компании, а сотрудники уведомляются о выпуске новой версии по электронной почте. Настоящее Положение ссылается на следующие документы: 1. Руководство по составлению Спецификации требований к программному обеспечению (файл «Руководство. Спецификация требований.doc») 2. Шаблон Спецификации требований к программному обеспечению (файл «Спецификация требований.dot») 3. Шаблон Каталога бизнес-правил (файл «Каталог бизнес-правил.xlt») 4. Шаблон Контроля версий (файл «Контроль версий.xlt») 2. Основные положения 2.1. Цели разработки требований Целями разработки требований являются: 1. Обеспечение наиболее полного и точного отражения условий или возможностей, необходимых заказчику для решения его проблем и достижения бизнес-целей. 2. Снижение затрат на разработку, обслуживание и поддержку сложного заказного программного обеспечения. 2.2. Участники разработки требований 2.2.1. Основные задачи разработки требований Результатом сотрудничества заказчика и разработчика на этапе разработки требований считается соглашение по базовой версии требований к продукту, которое должно быть надлежащим образом утверждено. Поэтому первой основной задачей разработки требований является создание базовой версии требований к продукту в оговоренные сроки. Все участники процесса разработки и утверждения требований должны понимать свою меру ответственности. Согласованное понимание значения подписи позволяет избежать прений, возникающих при изменении взглядов на требования, а также при изменении рыночных и бизнес-требований к проекту. Если заказчик будет опасаться, что ему не удастся внести коррективы после того, как базовая версия требований к продукту будет утверждена, он неизбежно станет затягивать утверждение, в результате чего возникает угроза срыва всего проекта. Поэтому второй основной задачей разработки требований является достижение управляемости процессом разработки требований и формирование атмосферы взаимного доверия среди заинтересованных лиц: • заказчик должен быть уверен, что разработчики будут взаимодействовать с ним для создания нужной системы, даже если перед началом работы над проектом он не успел продумать все требования; • заказчик должен быть уверен, что границы проекта не выйдут из-под контроля, поскольку решения относительно границ принимает он; • менеджер проекта должен быть уверен, что команда разработчиков получила достойного делового партнера, который совместно с разработчиками готов отвечать за качество продукта; • аналитик требований должен быть уверен в том, что сможет управлять изменениями проекта, минимизируя хаос. 2.2.2. Группа разработки требований Для разработки требований приказом Директора создается Группа разработки требований, в которую, как правило, включаются представители всех заинтересованных в проекте лиц. К заинтересованным в проекте лицам относятся: • Заказчики, которые финансируют проект или приобретают продукт для решения каких-либо бизнес-задач. • Пользователи, которые взаимодействуют напрямую или косвенно с приложением (подкласс заказчиков). • Аналитики требований, которые пишут требования и передают их разработчикам. • Разработчики, которые создают, разворачивают и поддерживают продукт. • Тестировщики, которые определяют соответствие поведения программного обеспечения желаемому. • Технические писатели, которые отвечают за создание руководства пользователей, тренировочных материалов и справочной системы. • Менеджер проекта, который планирует процесс и руководит командой разработчиков вплоть до успешного выпуска продукта. • Сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям. • Сотрудники отдела продаж и маркетинга, выездной службы поддержки и другие, кому придется работать с продуктом и его пользователями. В обязательном порядке в Группу разработки требований включаются представители заказчика, пользователей, аналитиков требований, разработчиков и тестировщиков. Наличие представителей других заинтересованных групп, как и количество представителей от каждой группы определяется спецификой разрабатываемого проекта. В Группу разработки требований в качестве пользователей целесообразно включать так называемых «сторонников продукта», т.е. представителей отдельных классов пользователей, которые поддерживают требования представляемых ими классов пользователей. Поскольку на этапе создания Группы разработки требований классы пользователей еще не определены, назначение членов группы, являющихся сторонниками продукта, осуществляется позднее, после выявления соответствующих классов пользователей. Руководителем Группы разработки требований назначается аналитик требований. Конкретный состав Группы разработки требований определяется Директором по представлению руководителя группы. Аналитик требований – это не только формальный руководитель Группы разработки требований, но и основное лицо, отвечающее за сбор, анализ, документирование и проверку требование к проекту. Это основной коммуникативный канал между заказчиком и командой разработчиков, хотя, конечно, не единственный. Поэтому аналитик требований должен обладать всеми навыками, знаниями и личными качествами, необходимыми для выполнения данных работ. 2.2.3. Права заказчика 1. Иметь дело с аналитиком, который разговаривает на языке его предметной области. 2. Иметь дело с аналитиком, хорошо изучившим его бизнес и цели, для которых создается система. 3. Потребовать, чтобы аналитик преобразовал требования, предоставленные им устно, в письменную спецификацию требований к программному продукту. 4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования требований. 5. На уважительное и профессиональное отношение со стороны аналитиков и разработчиков. 6. Знать о вариантах и альтернативах требований и их реализации. 7. Описать характеристики, упрощающие работу с продуктом. 8. Изменить требования или разрешить использование имеющихся программных компонентов. 9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО. 10. Потребовать, чтобы система функциональностью и качеством удовлетворяла его требованиям. 2.2.4. Обязанности заказчика 1. Ознакомить аналитиков и разработчиков с особенностями своего бизнеса. 2. Потратить столько времени, сколько необходимо, на объяснение требований. 3. Точно и конкретно описать требования к системе. 4. Принимать своевременные решения. 5. Уважать определенную разработчиком оценку стоимости и возможность реализации его требований. 6. Определять приоритеты требований. 7. Просматривать документы с требованиями и оценивать прототипы. 8. Своевременно сообщать об изменениях требований. 9. Поддерживать принятый в организации-разработчике порядок контроля изменений. 10. Уважительно относиться к методам, с помощью которых аналитики создают требования. 2.2.5. Обязанности аналитика требований 1. Определить бизнес-требования к проекту. 2. Определить классы пользователей продукта и выбрать соответствующих представителей каждого класса – сторонников продукта, а также заручиться их поддержкой и согласовать обязанности. 3. Выявить требования к проекту, используя для этого способы сбора информации, рекомендуемые настоящим Положением. 4. Вести анализ требований для обеспечения их надлежащего качества. 5. Обеспечить создание спецификации требований к продукту. 6. Определять необходимость представления требований с помощью моделей графического анализа, таблиц, математических уравнений, раскадровок и прототипов. 7. Управлять проверкой требований. 8. Обеспечить расстановку приоритетов требований. 9. Обеспечить выпуск базовой версии требований. 10. Управлять требованиями после выпуска базовой версии требований. 2.3. Классификация требований Требования к программному обеспечению состоят из трех уровней – бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на Рис. 2 -1 иллюстрирует способ представления этих типов требований. Как и все модели, она не полная, но схематично показывает организацию требований. Овалы обозначают исходные типы информации для требований, а прямоугольники – средства консолидации и хранения результирующей информации. По существу каждое требование пользователя должно быть сопоставлено бизнес-требованию. На основе требований пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам же необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки налагаемых ограничений. Хотя в модели на Рис. 2 -1 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-требованиями, требованиями пользователей и функциональными требованиями. Рис. 2‑1. Взаимосвязи разных типов информации для требований 2.3.1. Бизнес-требования Бизнес-требования содержат высокоуровневые задачи и цели организации-разработчика или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей или отдел маркетинга. Эти требования объясняют, почему организации нужна такая система, или, иначе говоря, описывают цели, которые организация намерена достичь с ее помощью. Бизнес-требования записываются в соответствующем разделе Спецификации требований к программному обеспечению, хотя могут записываться и в форме документа об образе и границах проекта, который еще иногда называют уставом проекта или документом рыночных требований. 2.3.2. Бизнес-правила Бизнес-правила включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к программному обеспечению, потому что они находятся снаружи границ любой системы программного обеспечения. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. 2.3.3. Требования пользователей Требования пользователей описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие – отклик». Таким образом, требования пользователей определяют, что клиенты смогут делать с помощью системы. 2.3.4. Системные требования Термином системные требования обозначают высокоуровневые требования к продуктам, которые содержат многие подсистемы, то есть системам (IEEE, 1998с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы программного обеспечения и оборудования. Люди – часть системы, поэтому определенные функции системы могут распространяться и на людей. 2.3.5. Атрибуты качества Атрибуты качества представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. 2.3.6. Внешний интерфейс Внешний интерфейс определяется нефункциональными требованиями, описывающими взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации, обусловленные необходимостью взаимодействия с внешними компонентами. 2.3.7. Ограничения Ограничения касаются возможности выбора внешнего вида (дизайна) и структуры продукта (возможности выбора архитектуры). 2.3.8. Функциональные требования Функциональные требования определяют функциональность программного обеспечения, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна». Функциональные требования описывают, что разработчику необходимо реализовать. Функциональные требования, как правило, документируются в спецификации требований к программному обеспечению, где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к программному обеспечению используется при разработке, тестировании, управлении проектом и в других, связанных с проектом функциях, в том числе при обеспечении гарантии качества продукта. 2.3.9. Нефункциональные требования В дополнение к функциональным требованиям спецификация также содержит нефункциональные требования, которые формируются на основе имеющихся атрибутов качества, требований к внешнему интерфейсу и ограничений. 2.4. Классификация бизнес-правил Как уже отмечалось, в любой организации действует широкий набор корпоративных политик, законов и промышленных стандартов, а многие отрасли к тому же подчиняются постановлениям правительства. Все эти контролирующие принципы в целом называются бизнес-правилами. Иногда их выполнение и соблюдение осуществляется средствами программных систем, в других случаях за соблюдением правил и процедур следят люди. Большинство бизнес-правил берут начало вне контекста какой-либо конкретной программной системы. Тем не менее, бизнес-правила – один из основных источников функциональных требований к программному обеспечению, поскольку они определяют возможности, которыми должна обладать система для выполнения правил. Не все фирмы рассматривают собственные важнейшие бизнес-правила как ценность, которой они и являются на самом деле. Если эта информация не задокументирована и не хранится должным образом, она существует только в головах сотрудников. Но последние могут по-разному понимать правила, в результате чего их корректное выявление зачастую затруднено. Облегчить задачу выявления бизнес-правил может их классификация. 2.4.1. Факты Факты – это всего лишь верные утверждения о бизнесе. Зачастую они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами – неизменными истинами о сущности данных и их атрибутах. Бизнес-правила во многих случаях могут ссылаться на определенные факты, однако последние обычно не преобразуются напрямую в функциональные требования к программному обеспечению. Сведения о сущности данных, важных для системы, иногда применяют в моделях данных, создаваемых аналитиком или архитектором БД. Вот примеры фактов: • на каждый товар нанесен уникальный штрих-код; • оплачивается доставка каждого заказа; • каждый элемент заказа содержит данные о товаре и его цене. 2.4.2. Ограничения Ограничения – определяют, какие операции может выполнять система и ее пользователи. Вот некоторые слова и фразы, которые часто применяются при описании ограничивающего бизнес-правила: должен, не должен, не может и только. Скорее всего, в организации есть политики безопасности, определяющие порядок доступа к информационным системам. Обычно они констатируют, какие пароли следует применять, как часто их надо менять, можно ли применять старые пароли и т.п. Все эти ограничения, касающиеся доступа к приложению, можно считать бизнес-правилами. 2.4.3. Активаторы операций Правило, при определенных условиях приводящее к выполнению каких-либо действий, называется активатором операции. Человек может выполнять эти действия самостоятельно. Как вариант, правило может управлять некоторыми программными функциями, благодаря которым приложение при выполнении определенных условий реализует нужную модель поведения. Условия, определяющие выполнение операции, иногда представляют собой сложную комбинацию значений «истина» и «ложь», выполняющихся для нескольких отдельных условий. Выражение вида «Если <некоторое условие верно или наступило определенное событие>, то <что-то произойдет>», – это признак, который описывает активатор операции. 2.4.4. Выводы Вывод, иногда его еще называют предположительным знанием, – это правило, устанавливающее новые реалии на основе достоверности определенных условий. Вывод создает новый факт на основе других фактов или вычислений. Выводы зачастую записывают в формате «если – то», применяемом также при записи бизнес-правил, активирующих операции; тем не менее, раздел «то» вывода заключает в себе факт или предположение, а не действие. Вот несколько примеров выводов: • если платеж не поступил в течение 30 календарных дней с момента отправки счета, счет считается просроченным; • если поставщик не может поставить заказанный товар в течение пяти дней с момента получения заказа, заказ считается невыполненным. 2.4.5. Вычисления Компьютеры осуществляют вычисления, и поэтому один из классов бизнес-правил определяет вычисления, выполняемые с использованием математических формул и алгоритмов. Многие вычисления выполняются по внешним для предприятия правилам, например по формулам удержания подоходного налога. В отличие от активирующих операции бизнес-правил, для реализации которых иногда приходится создавать специфические функциональные требования к программному обеспечению, правила вычислений в той форме, в которой они выражены, можно непосредственно рассматривать в качестве требований к программному обеспечению. Бизнес-правила для вычислений можно представлять в текстовой форме, в символьной форме, например в виде математических выражений, однако представление таких правил в виде таблицы гораздо понятнее, чем длинный список сложных текстовых выражений. 2.5. Классификация атрибутов качества Естественно, что пользователей, как правило, интересуют функциональные, или поведенческие, требования – то есть возможности, предоставляемые программным обеспечением, однако для успеха программного обеспечения недостаточно правильно реализовать соответствующую функциональность. Кроме того, пользователей волнует, насколько хорошо новая система будет работать. К характеристикам, описывающим это свойство системы, относятся такие характеристики как легкость использования, быстрота запуска, количество сбоев, обработка неожиданных ситуаций и т.п.. В целом они и называются атрибутами качества программного обеспечения или факторами качества и считаются частью нефункциональных (или неповеденческих) требований к системе. Атрибуты качества можно разделить на очевидные характеристики, главным образом важные для пользователей, и скрытые качества, которые имеют значение для службы технической поддержки. Последние косвенно влияют на мнение клиента, так как упрощают возможные изменения продукта, его корректировку, проверку и переход на другие платформы. 2.5.1. Атрибуты, важные для пользователей 2.5.1.1. Доступность Под доступностью понимается запланированное время доступности (up time), в течение которого система действительно доступна для использования и полностью работоспособна. Формально доступность равна среднему времени до сбоя (mean time to failure, MTTF) системы, деленному на сумму среднего времени до сбоя и ожидаемого времени до восстановления системы после сбоя. На доступность также влияют периоды планового технического обслуживания. Отдельные задачи более других зависят от времени, и пользователи будут страшно разочарованы (и даже разгневаны), если система не окажется доступной в нужный момент. Узнайте у клиентов, какой процент времени доступности им действительно необходим и есть ли периоды времени, когда доступность настоятельно необходима для бизнеса или выполнения задач, связанных с безопасностью. 2.5.1.2. Эффективность Эффективностью называется показатель того, насколько эффективно система использует производительность процессора, место на диске, память или полосу пропускания соединения. Если система тратит слишком много ресурсов, пользователи заметят снижение производительности – видимого показателя эффективности. Недостаточная производительность раздражает пользователей, которые ожидают вывода на экран результата запроса к базе данных. Но проблемы производительности, кроме того, ставят под удар безопасность, например, при перегрузке системы контроля процессов реального времени. Определите минимальную конфигурацию оборудования, при которой удается достичь заданных эффективности, пропускной способности и производительности. Чтобы определить нижний предел в случае непредвиденных условий и последующий рост, вы можете воспользоваться такой формулировкой: «Как минимум 25% пропускной способности процессора и оперативной памяти, доступной приложению, не должно использоваться в условиях запланированной пиковой нагрузки». Однако типичные пользователи не формулируют требования к эффективности в таких технических терминах. Максимум, на что они способны, так это упомянуть время отклика или заполнение пространства на диске. Дело аналитика – задать вопросы, которые выявят ожидания пользователей о приемлемом снижении производительности, возможных пиках нагрузки и ожидаемом росте. 2.5.1.3. Гибкость Этот атрибут также называют расширяемостью, дополняемостью, наращиваемостью или растяжимостью. Гибкость показывает, с какой легкостью в продукт удается добавить новые возможности. Если ожидается, что при разработке придется вносить множество улучшений, стоит выбрать такие решения, которые позволят увеличить гибкость программного обеспечения. Этот атрибут важен для продуктов, в качестве модели разработки которых выбрано улучшение и повтор успешных выпусков или развитие прототипа. Однако наиболее сложной проблемой является запись требований к гибкости в формате, который предусматривает возможность их измерения. 2.5.1.4. Целостность Целостность, которая включает в себя и безопасность, связана с блокировкой неавторизированного доступа к системным функциям, предотвращением потери информации, антивирусной защитой программного обеспечения и защитой конфиденциальности и безопасности данных, введенных в систему. В требованиях к целостности нет места ошибкам. Для формулирования требований к целостности следует использовать точные термины: проверка идентификации пользователя, уровни привилегий пользователя, ограничения доступа или определенные данные, которые должны быть защищены. Например: «Только пользователи, обладающие привилегиями уровня Аудитор, должны иметь возможность просматривать транзакции клиентов». Многие требования к целостности считаются ограничивающими бизнес-правилами. Неплохо бы знать логическое обоснование ваших требований к атрибутам качества и исследовать их происхождение, например политику управления. Следует избегать указания требований к целостности в виде ограничений дизайна, как, скажем, требования к паролю для контроля доступа. Реальное требование должно ограничивать доступ к системе неавторизированных пользователей; пароли – всего лишь один из способов (хотя и самый распространенный) выполнения этой задачи. Основанное на выбранном подходе к идентификации пользователей, это базовое требование к целостности повлияет на определенные функциональные требования, которые реализуют функции аутентификации в системе. 2.5.1.5. Способность к взаимодействию Способность к взаимодействию показывает, каким образом система обменивается данными или сервисами с другими системами. Чтобы оценить способность к взаимодействию, вам необходимо знать, какие приложения клиенты будут применять совместно с вашим продуктом и обмен какими данными предполагается. Вы также могли бы указать данное требование как требование к внешнему интерфейсу и определить стандартные форматы файлов, которые способна импортировать система. В качестве альтернативы можно определить несколько функциональных требований, относящихся к операции импорта. Однако иногда, только рассматривая систему с точки зрения атрибутов качества, можно выяснить, что некоторые определенные требования не заданы. Клиенты просто не указали данную потребность при обсуждении внешнего интерфейса или функциональности системы. 2.5.1.6. Надежность Надежностью называется вероятность работы программного обеспечения без сбоев в течение определенного периода времени. Иногда одной из характеристик надежности считают устойчивость к сбоям. Для измерения надежности программного обеспечения используют такие показатели, как процент успешно завершенных операций и средний период времени работы системы до сбоя. Определите количественные требования к надежности, основываясь на том, насколько серьезными окажутся последствия сбоя и оправдана ли цена повышения надежности. Системы, для которых требуется высокая надежность, следует проектировать с высокой степенью возможности тестирования, чтобы облегчить выявление недостатков, отрицательно влияющих на надежность. 2.5.1.7. Устойчивость к сбоям Под устойчивостью к сбоям, которую еще иногда называют отказоустойчивостью (fault tolerance), понимают уровень, до которого система продолжает корректно выполнять свои функции, несмотря на неверный ввод данных, недостатки подключенных программных компонентов или компонентов оборудования или неожиданные условия работы. Устойчивое к сбоям программное обеспечение легко восстанавливается после различных проблем и «не замечает» ошибок пользователей. Выясняя требования к устойчивости работы программного обеспечения, спросите пользователей, какие ошибочные ситуации возможны при работе с системой и как система должна на них реагировать. 2.5.1.8. Удобство и простота использования Этот атрибут связан с массой факторов, которые составляют основу того, что пользователи часто описывают как дружелюбие к пользователю. Удобство и простота использования измеряется усилиями, требуемыми для подготовки ввода данных, эксплуатации и вывода конечной информации. Узнайте, должна ли новая система соответствовать каким-либо стандартам или соглашениям, касающимся пользовательского интерфейса, и должен ли последний быть совместим с другими часто используемыми системами. Кроме того, удобство и простота использования определяется и тем, насколько легко новые или непостоянные пользователи научатся работать с продуктом. Простота обучения также поддается исчислению и измерению. 2.5.2. Атрибуты, важные для разработчиков и специалистов по техническому обслуживанию 2.5.2.1. Легкость в эксплуатации Этот атрибут показывает, насколько удобно исправлять ошибки или модифицировать программное обеспечение. Легкость в эксплуатации зависит от того, насколько просто разобраться в работе программного обеспечения, изменять его и тестировать, и тесно связано с гибкостью и тестируемостью. Этот показатель крайне важен для продуктов, которые подвергаются частым изменениям, и тех, что создаются быстро (и, возможно, с экономией на качестве). Легкость в эксплуатации измеряют, используя такие термины, как среднее время, требуемое для разрешения проблемы, и процент корректных исправлений. Чтобы понять, какие качества исходного кода облегчат внесение изменений или исправление недостатков, следует поработать с программистами, занимающимися техническим обслуживанием. 2.5.2.2. Мобильность Мерой ее измерения можно считать усилия, необходимые для перемещения программного обеспечения из одной операционной среды в другую. Зачастую к мобильности относят и возможность интернационализации и локализации продукта. Обычно мобильность продукта или не имеет никакого значения, или же крайне важна для успеха проекта. 2.5.2.3. Возможность повторного использования Постоянная задача разработки программного обеспечения – возможность повторного использования – показывает усилия, необходимые для преобразования программных компонентов с целью их дальнейшего применения в других приложениях. Затраты на разработку программного обеспечения с возможностью повторного использования значительно выше, чем на создание компонента, который будет работать только в одном приложении. Оно должно быть модульным, хорошо задокументированным, не зависеть от конкретных приложения и операционной среды, а также обладать некоторыми универсальными возможностями. Цели многократного использования сложно количественно измерить. Укажите, какие элементы новой системы необходимо спроектировать таким образом, чтобы упростить их повторное применение, или укажите библиотеки компонентов многократного использования, которые необходимо создать дополнительно к проекту. 2.5.2.4. Тестируемость Этот атрибут также называют проверяемостью или верифицируемостью, он показывает легкость, с которой программные компоненты или интегрированный продукт можно проверить на предмет дефектов. Такой атрибут крайне важен для продукта, в котором используются сложные алгоритмы и логика или имеются тонкие функциональные взаимосвязи. Тестируемость также важна в том случае, если продукт необходимо часто модифицировать, поскольку предполагается подвергать его частому регрессивному тестированию, чтобы выяснить, не ухудшают ли внесенные изменения существующую функциональность. 2.5.3. Взаимосвязь атрибутов качества Большинство атрибутов качества противоречат друг другу и для определенных их комбинаций компромиссы неизбежны. Пользователи и разработчики должны решить, какие атрибуты важнее других и при принятии решений соблюдать эти приоритеты. В таблице, приведенной ниже, отражены взаимосвязи наиболее распространенных атрибутов качества. Знак «+» в ячейке означает, что увеличение величины атрибута в соответствующей строке позитивно влияет на атрибут в соответствующем столбце. Знак «-» в ячейке означает, что увеличение величины атрибута в этой строке негативно влияет на атрибут в соответствующем столбце. Пустая ячейка означает, что атрибут в этой строке оказывает незначительное влияние на атрибут в столбце. Эффективность оказывает негативное влияние на большинство атрибутов. Если вы напишите компактную и быструю программу, используя хитрости кодирования и учитывая некоторые побочные эффекты при выполнении, вероятнее всего эту программу будет сложно поддерживать и исправлять, а также переносить на другие платформы. Аналогично, системы, которые были оптимизированы для удобства использования или спроектированы как гибкие, пригодные для многократного применения и способные взаимодействовать с другими программными компонентами или компонентами оборудования, часто грешат проблемами производительности. Вам необходимо найти баланс между возможным ухудшением производительности и ожидаемой выгодой от предлагаемого решения, чтобы убедиться, что компромисс, на который вы идете, разумен. Матрица не симметрична, потому что влияние при увеличении атрибута А на атрибут В не обязательно такое же, как влияние, которое оказывает увеличение атрибута В на атрибут А. Так, модификация системы с целью повышения эффективности не оказывает эффекта на целостность. Но повышение целостности вероятнее всего весьма отрицательно отразится на эффективности, поскольку системе придется выполнять множество проверок аутентификации пользователей, зашифрованных данных, проверок на наличие вирусов и контрольных точек данных. Таблица 2‑1. Позитивные и негативные взаимосвязи атрибутов качества Доступность Эффективность Гибкость Целостность Способность к взаимодействию Легкость в эксплуатации Мобильность Надежность Возможность повторного использования Устойчивость к сбоям Тестируемость Удобство и простота использования Доступность + + Эффективность - - - - - - - - Гибкость - - + + + + Целостность - - - - - Способность к взаимодействию - + - + Легкость в эксплуатации + - + + + Мобильность - + + - + + - Надежность + - + + + + + Возможность повторного использования - + - + + + - + Устойчивость к сбоям + - + + Тестируемость + - + + + + Удобство и простота использования - + - Чтобы оптимизировать баланс атрибутов продукта, в процессе сбора информации вам следует определить и задокументировать важнейшие атрибуты качества, расставив для них приоритеты. При определении атрибутов качества для проекта, следует использовать указанные зависимости, для того, чтобы не поставить перед собой несовместимые цели: • Не пытайтесь максимизировать удобство и простоту использования, если программное обеспечение должно работать на нескольких платформах (мобильность) • Нелегко полностью проверить требования к целостности систем с высоким уровнем безопасности. Для универсальных компонентов многократного использования или тех, что предполагаются для связи с другими приложениями, можно в некоторой степени снизить требования безопасности. • Крайне надежный код окажется менее эффективным из-за постоянного выполнения им проверок данных и поиска ошибок. Как правило, слишком ограничивая возможности системы или определяя конфликтующие требования, вы тем самым усложняете задачу разработчикам – им гораздо труднее удовлетворить все требования заказчика. 2.6. Критерии качества требований 2.6.1. Критерии качества отдельных положений спецификации требований 2.6.1.1. Полнота Требование является полным тогда и только тогда, когда оно содержит всю информацию, необходимую для разработки соответствующей функциональности, которую следует реализовать в продукте. Если в процессе разработки требований не хватает каких-либо данных, необходимо использовать пометку «НО» (необходимо определить) на полях как стандартный флаг для выделения такого места. Все пробелы в каждом фрагменте требований должны быть восполнены, прежде чем спецификация требований будет окончательно утверждена. 2.6.1.2. Корректность Требование является корректным тогда и только тогда, когда оно представляет что-либо, требуемое от создаваемого продукта. 2.6.1.3. Осуществимость Требование является осуществимым тогда и только тогда, когда оно реализуемо при известных условиях и ограничениях создаваемого продукта и операционной среды, в том числе и при оговоренных сроках и объеме финансирования. 2.6.1.4. Необходимость Требование является необходимым тогда и только тогда, когда оно отражает возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, требование должно исходить от лица, которое имеет полномочия на формулирование требований. 2.6.1.5. Упорядоченность по важности и стабильности Все требования должны быть упорядочены по их важности для заказчика и стабильности. Этот процесс упорядочения особенно важен для управления масштабом. Если ресурсы недостаточны, чтобы в пределах выделенного времени и бюджета реализовать все требования, полезно знать, какие требования являются не столь уж обязательными, а какие заказчик считает критическими. 2.6.1.6. Недвусмысленность Требование является недвусмысленным тогда и только тогда, когда его можно однозначно интерпретировать. Если формулировка требований может по-разному интерпретироваться разработчиками, пользователями и другими участниками проекта, вполне может оказаться, что построенная система будет полностью отличаться от той, которую представлял себе заказчик. 2.6.1.7. Проверяемость Требования должны поддаваться проверке (быть верифицируемыми). Требование в целом считается верифицируемым тогда и только тогда, когда каждое из составляющих его элементарных требований является верифицируемым. Элементарное требование считается верифицируемым тогда и только тогда, когда существует конечный финансово-эффективный процесс, с помощью которого человек или машина могут определить, что разработанная программная система действительно удовлетворяет данному требованию. Практическая задача состоит в таком определении требований, чтобы можно было впоследствии протестировать их и выяснить, действительно ли они выполняются. 2.6.2. Критерии качества спецификации требований в целом 2.6.2.1. Полнота Набор требований является полным тогда и только тогда, когда он описывает все важные требования, интересующие пользователей, в том числе требования, связанные с функциональными возможностями, производительностью, ограничениями проектирования, атрибутами или внешними интерфейсами. 2.6.2.2. Непротиворечивость Набор требований является непротиворечивым тогда и только тогда, когда ни одно его подмножество, состоящее из отдельных требований, не противоречит другим подмножествам. Конфликты могут иметь различную форму и проявляться на различных уровнях детализации. 2.6.2.3. Способность к модификации Набор требований является модифицируемым, когда его структура и стиль таковы, что любое изменение требований можно произвести просто, полно и согласованно, не нарушая существующей структуры и стиля всего подмножества. Для этого требуется, чтобы пакет требований имел минимальную избыточность и был хорошо организован, с соответствующим содержанием, указателями и возможностью перекрестных ссылок. 2.6.2.4. Трассируемость Набор требований является трассируемым, когда ясно происхождение каждого из составляющих его элементарных требований и существует механизм, который делает возможным обращение к этим требованиям при дальнейших действиях по разработке. Возможность трассировки имеет огромное значение. Разработчики могут использовать ее как для достижения лучшего понимания проекта, так и для обеспечения более высокой степени уверенности, что все требования выполняются. 2.7. Назначение приоритетов требований 2.7.1. Зачем определять приоритеты требований Приоритеты – это способ разрешения борьбы между конкурирующими требованиями за ограниченные ресурсы. Определение относительного приоритета каждой возможности позволяет так планировать разработку, чтобы обеспечивать наибольшую ценность при наименьших затратах. Определение приоритетов наиболее критично для работы в очень строгих временных рамках. Менеджер проекта должен сбалансировать желаемый объем проекта и ограничения, определяемые сроком, бюджетом, людскими ресурсами и качеством. Один из способов достижения этого – убрать (или отложить до более поздней версии) требования с низким приоритетом, когда принимаются новые, более важные требования или изменяются другие условия проекта. Если клиенты не классифицируют свои требования по важности и срочности, менеджерам проектов приходится делать это своими силами. Неудивительно, что клиентам не всегда нравится результат; поэтому они должны указывать, какие требования необходимы с самого начала, а какие могут подождать. Определяйте приоритеты на ранних стадиях проекта, когда больше шансов на успешный результат, и периодически возвращайтесь к ним. Достаточно сложно заставить даже одного клиента решить, какие из его требований приоритетнее. Согласовать мнения нескольких клиентов с различными ожиданиями еще труднее. Люди по природе склонны отстаивать свои интересы и не жаждут жертвовать собственными нуждами ради чужой выгоды. Тем не менее, участие в определении приоритетов требований – одна из обязанностей клиента в отношениях «клиент – разработчик». Обсуждение приоритетов помогает не только определить последовательность реализации требований, но и прояснять ожидания клиентов. И клиенты, и разработчики должны внести вклад в определение приоритетов требований. Клиентам больше всего нужны функции, наиболее ценные для бизнеса или удобства работы. Однако, когда разработчики обрисуют затраты, трудоемкость, технический риск или компромиссы, связанные с каждым требованием, клиенты могут передумать и прийти к выводу, что это требование не так важно, как они считали изначально. Разработчики же иногда решают на ранних стадиях реализовать некоторые функции с низким приоритетом из-за их влияния на архитектуру системы. Оценивая приоритеты, учитывайте связи и взаимосвязи между различными требованиями, а также их соответствие бизнес-целям проекта. 2.7.2. Шкала приоритетов Обычный метод расстановки приоритетов подразумевает три группы категорий требований. Неважно, как вы назовете их, все сводится к высокому, среднему и низкому приоритетам. Такие шкалы приоритетов субъективны и неточны. Лица, заинтересованные в проекте, должны согласовать, что означает каждый уровень в используемой шкале. В малом проекте заинтересованные лица могут согласовать приоритеты требований неформально. Крупные или спорные проекты требуют более структурированного подхода, устраняющего из процесса некоторые эмоции, политику и догадки. Поэтому для определения приоритетов обычно используются аналитические и математические методики. Один из способов оценки приоритетов предлагает учитывать два измерения: важность и срочность. Каждое требование считается важным либо не важным и срочным либо не срочным. Получаются четыре комбинации для определения шкалы приоритетов: 1. Требования с высоким приоритетом (high priority) – и важные (пользователям нужны функции), и срочные (они необходимы уже в следующем выпуске). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам либо из-за непреодолимых бизнес-причин. 2. Требования со средним приоритетом (medium priority) – важные (пользователям нужны функции), но не срочные (они могут ждать следующего выпуска). 3. Требования с низким приоритетом (low priority) – не важные (пользователи при необходимости могут обойтись без этой функций) и не срочные (пользователи могут ждать, причем вечно). 4. Требования в четвертой клетке кажутся срочными, но в действительности – они не важны. Не тратьте время на работу над ними – они не сделают продукт более ценным. Для определения приоритетов также предлагаются аналитические и математические методики, основывающиеся на оценке относительной ценности и относительной стоимости каждого требования. В соответствии с этими методиками требования с самым высоким приоритетом – это те, что обеспечивают большую ценность продукта при меньшей стоимости. Другая альтернатива – Quality Function Deployment (QFD), всесторонний метод определения относительной ценности для клиента, а также подход, заимствованный из Total Quality Management (TQM), позволяющий оценить каждое требование по нескольким весомым критериям успеха проекта и подсчитать количество баллов для назначения приоритетов требований. Однако в силу сложности лишь немногие организации разработчики ПО применяют QFD или TQM. В таблице показана матрица определения приоритетов, которая может использоваться для оценки относительных приоритетов наборов вариантов использования, функций или функциональных требований. Таблица 2‑2. Матрица определения приоритетов Вес α1 α2 β1 β2 Требование Выгода Урон Стоимость Риск Приоритет Эта матрица заимствует из QFD концепцию обоснования ценности для пользователя, поскольку учитывается как выгода для пользователя, если требование реализовано в продукте, так и неудобство, если реализация отсутствует. Затраты также оцениваются двояко: как стоимость реализации требования и как возможный риск срыва реализации. Все показатели: Выгода – B (benefit), Урон – L (loss), Стоимость – C (cost) и Риск – R (risk) оцениваются в баллах по шкале 1-10. Двойная оценка ценности и затрат позволяет снизить влияние субъективных факторов. Обобщенная оценка Ценности – W (worth) и Затрат – O (outlay) вычисляется как где α и β – весовые коэффициенты, определяющие предпочтения в парных оценках. Причем должно соблюдаться условие α1 + α2 = β1 + β2 = 1. При прочих равных условиях требования с наибольшим значением Ценность/Затраты должны иметь наивысший приоритет. Поэтому оценка приоритета P определяется как где коэффициент Kn введен из условия нормировки (значение приоритета лежит в диапазоне 0-1) и равен 10. Применять эту матрицу определения приоритетов к элементам, не имеющим наивысшей ценности. Не нужно включать в этот анализ элементы, которые реализуют основные бизнес-функции продукта, или которые являются основными отличительными чертами продукта, а также те, которые необходимы для соответствия юридическим нормам. Если нет возможности назначить этим элементам со временем более низкий приоритет при изменении условий, то необходимо реализовать их в продукте как можно быстрее. Определив элементы, которыми обязательно должен обладать выпускаемый продукт, для оценки оставшихся можно применить рассматриваемую матрицу. Обычно в процессе назначения приоритетов участвуют: • менеджер проекта, который ведет процесс, разрешает конфликты и при необходимости адаптирует данные, поступающие от других участников; • представители клиента – сторонники продукта или маркетологи, предоставляющие информацию о сильных и слабых сторонах продукта; • представители разработчиков, например руководители команд, сообщающие данные о стоимости и риске. Методика оценки заключается в следующем: 1. В таблицу вносятся все функции, варианты использования или требования, для которых определяются приоритеты. Все элементы должны принадлежать к одному уровню абстракции – нельзя смешивать, например, функциональные требования с функциями продукта. Если определенные функции логически связаны (например, вы реализуете функцию В только при наличии функции А), в анализ включайте только ведущую функцию. Поскольку получить приемлемые экспертные оценки для сотен объектов весьма сложно, при наличии большого числа оцениваемых элементов следует предварительно сгруппировать связанные элементы и включить в перечень оцениваемых элементов обобщенные, групповые элементы. При необходимости вы можете провести второй раунд анализа, на более детальном уровне. 2. Попросите представителей клиентов оценить относительную выгоду, которую каждый элемент дает клиенту или бизнесу, по шкале от 1 до 10 баллов: 1 балл означает, что никто не находит его полезным, а 10 – что этот элемент крайне ценен. Эти оценки выгоды по существу отражают связь оцениваемых элементов с бизнес-требованиями к продукту. 3. Аналогично попросите представителей клиентов оценить относительный урон, который потерпит клиент или бизнес, если элемент не будет включен в продукт. Здесь 1 балл означает, что никто не расстроится, если этого элемента не будет; 10 показывает серьезный урон. Оценивая урон, учитывайте, насколько расстроятся клиенты, если определенный элемент не будет реализован 4. Попросите разработчиков оценить относительную стоимость реализации каждого элемента, опять-таки по шкале от 1 (легко и быстро) до 10 (трудоемко и дорого). При оценке стоимости разработчики должны учитывать сложность реализации, объем требуемой работы над интерфейсом пользователя, потенциальную возможность повторного использования существующего кода, объем необходимого тестирования и документации и т.д. 5. Подобным же образом, разработчики должны оценить относительную степень технического или другого риска, связанного с каждым элементом. Оценка в 1 балл означает, подобное команда разработчиков уже реализовывала и имеет технологические наработки, 10 баллов означает серьезную озабоченность самой возможностью реализации, нехваткой сотрудников с необходимым опытом или использованием неиспытанных или незнакомых средств и технологий. 6. После получения всех оценок определяется значения приоритета по указанной выше формуле. 7. Полученный список следует отсортировать по уменьшению подсчитанного приоритета (при равенстве приоритетов – по убыванию выгоды или ценности). Элементы вверху списка характеризуются наиболее благоприятным сочетанием ценности, стоимости и риска и поэтому – при равенстве остальных факторов – должны иметь наивысший приоритет. Элементы, имеющие низкие рейтинги и выгоды, и урона, увеличивают затраты, но имеют малую ценность. Поэтому являются потенциальными кандидатами на исключение. Точность этого метода ограничена возможностью команды оценивать выгоду, урон, стоимость и риск для каждого элемента. Поэтому используйте подсчитанную последовательность приоритетов только как ориентир. Представители клиентов и разработчиков должны проверить итоговую таблицу, чтобы прийти к соглашению о рейтингах и результирующей последовательности приоритетов. Изначально весовые коэффициенты α и β, определяющие предпочтения в парных оценках, равны 0.5, т.е. компоненты оценок имеют одинаковый вес. Однако, используя наборы готовых требований из предыдущих проектов, эти коэффициенты можно настроить. Для этого необходимо их изменить так, чтобы подсчитанная последовательность приоритетов хорошо сочеталась с вашей постфактум-оценкой того, насколько в действительности важны требования в вашем калибровочном наборе. Заинтересованные в проекте лица обычно по-разному оценивают рассматриваемые элементы. При малом количестве оцениваемых элементов и небольшом разбросе оценок согласованные оценки могут быть получены в ходе простого обсуждения. В противном случае необходима формальная процедура согласования оценок. В качестве такой оценки может выступать взвешенная оценка: где ki – вес i-го эксперта, а Ri – его оценка. При назначении весов экспертов следует исходить из их влияния на принятие решений, касающихся проекта. При назначении весов экспертам, оценивающим показатели выгоды и урона, можно исходить из выявленных классов пользователей. Имеющиеся классы необходимо проранжировать по степени их влияния на принятие решений, касающихся проекта, и определить их веса как показано в таблице. Например, эксперты принадлежат к классам заказчиков, привилегированных и непривилегированных пользователей. Таблица 2‑3. Определение весов экспертов Группа экспертов Ранг группы Кол-во экспертов в группе Общий ранг группы Вес группы Вес эксперта Привилегированные пользователи 3 2 6 0.46 0.23 Заказчики 2 2 4 0.31 0.15 Непривилегированные пользователи 1 3 3 0.23 0.08 Суммарный ранг: 13 Примечания: 1. Несмотря на кажущийся приоритет заказчиков, привилегированные пользователи имеют более высокий ранг, поскольку их работа с продуктом определяет, способствует ли он достижению заявленных бизнес-целей или нет. 2. Общий ранг группы определяется как произведение ранга группы на количество экспертов в группе. 3. Вес группы определяется как отношение общего ранга группы к суммарному рангу. 4. Вес эксперта определяется как частное от деления веса группы на количество экспертов в группе. При назначении весов экспертам, оценивающим показатели стоимости и риска, можно исходить из аналогичных соображений, выделив соответствующие группы экспертов. Причем наивысший ранг также следует присваивать тем группам, от которых в наибольшей степени зависит успешность реализации проекта. 2.8. Обеспечение ресурсами Обеспечение ресурсами процесса разработки требований осуществляется на основе утвержденного Плана-графика разработки требований. 2.9. Обучение Не следует предполагать, что участники проекта интуитивно знают, как сотрудничать при формулировании требований. Всех участников необходимо информировать о их правах и обязанностях с тем, чтобы организовать взаимодействие наиболее эффективно. Более того, не все разработчики программного обеспечения знают теорию разработки требований, хотя на определенном этапе профессиональной деятельности многие из них осваивают обязанности аналитика требований и работают с клиентами, собирая, анализируя и документируя требования. Обучение позволяет повысить профессиональные навыки сотрудников, выполняющих роли аналитиков, но не может компенсировать нехватку навыков межличностного общения и отсутствие интереса к делу. Процесс формулирования требований весьма важен, и поэтому все участники проекта должны понимать концепцию и приемы формулирования требований. Эффективный способ создать команду – собрать участников проекта на однодневный семинар, где и обсудить все процедуры разработки требований. Стороны смогут глубже понять проблемы, стоящие перед остальными, а также то, что необходимо участникам друг от друга для успеха проекта. Аналогичным образом разработчиков следует просветить о концепциях и терминологии предметной области. 2.9.1. Обучение аналитиков требований Всем членам команды, которые будут исполнять функции аналитиков, необходимо научиться приемам и методам разработки требований. Однако этого недостаточно. Поскольку именно на аналитиков требований возлагается организация и проведение разработки требований, для них дополнительно необходимо организовать семинары по межличностному общению, организации работы групп, ведению переговоров и разрешению конфликтов. Полезно также организовать семинары по соответствующим предметным областям. 2.9.2. Ознакомление пользователей и менеджеров с требованиями Пользователи, которые будут принимать участие в разработке ПО, должны пройти непродолжительный тренинг (один-два дня), чтоб научиться формулировать требования. Он полезен и для менеджеров по разработке и по работе с клиентами. Подобное обучение поможет понять особое значение выявления требований, суть процесса их разработки, а также опасность пренебрежения ими. 2.9.3. Ознакомление разработчиков с концепциями предметной области Чтобы помочь разработчикам в общих чертах понять предметную область, перед каждой разработкой требований необходимо провести семинар, на котором познакомить их с бизнесом клиента, терминологией и назначением создаваемого продукта. Это уменьшит вероятность путаницы, непонимания и доработок. Можно также на время проекта назначить каждому разработчику «личного пользователя», который будет разъяснять профессиональные термины и бизнес-концепции. 2.9.4. Создание бизнес-словаря Словарь со специализированными терминами из предметной области снизит вероятность непонимания. Включите в него синонимы, термины, имеющие несколько значений, и термины, имеющие в предметной области и повседневной жизни разные значения. Таким словарем желательно снабдить всех участников проекта. 3. Разработка требований: общие положения Разработку требований можно подразделить на подготовку, выявление, анализ, документирование и проверку. В эти процедуры по существу входят все действия, включающие сбор, оценку и документирование требований для программного обеспечения, в том числе: • определение бизнес-требований; • определение образа и границ проекта • идентификация классов пользователей продукта; • выяснение потребностей тех, кто представляет каждый класс пользователей; • определение задач и целей пользователей; • анализ информации, полученной от пользователей, чтобы отделить задачи от функциональных и нефункциональных требований, бизнес-правил, предполагаемых решений и поступающих извне данных; • установление относительной важности атрибутов качества; • установление приоритетов реализации; • документирование собранной информации и построение моделей; • просмотр спецификации требований, который позволяет удостовериться в том, что запросы пользователей всеми понимаются одинаково; • устранение всех возникших проблем до передачи документа разработчикам. На Рис. 3 -2 представлена IDEF0 модель разработки требований. Рис. 3‑2. Общая модель разработки требований Данная модель рассматривает разработку требований как управляемый итеративный процесс последовательных уточнений требований. На каждом этапе выявленные требования анализируются, документируются и подвергаются проверке. При обнаружении несоответствий, неопределенностей, противоречий и иных несообразностей формируются соответствующие запросы на их устранение и итерация повторяется. 4. Подготовка разработки требований На Рис. 4 -3 представлена IDEF0 модель подготовки разработки требований. Рис. 4‑3. Модель подготовки разработки требований По существу процесс подготовки разработки требований является начальным этапом итерационной процедуры разработки требований, а его основными задачами являются определение образа и границ проекта, формирование Группы разработки требований и разработка Плана-графика разработки требований. 4.1. Определение бизнес-требований Основой раздела об образе и границах проекта спецификации требований являются бизнес-требования. Именно бизнес требования определяют основные задачи и цели проекта, в рамках которых определяются все детальные требования к проекту. Достаточно широко распространена практика, когда бизнес-требования разрабатываются заказчиком самостоятельно. Однако подобную практику нельзя признать приемлемой, поскольку зачастую бизнес-требования, разработанные заказчиком, не обладают требуемыми характеристиками, что в последствии, при разработке детализированных требований, приводит к конфликтам и необоснованным затратам времени и ресурсов. Проблема усугубляется и тем, что исключительная прерогатива изменения бизнес-требований принадлежит заказчику. Поэтому более правильным подходом является совместная разработка бизнес-требований на начальной стадии процесса разработки требований. Причем информация, касающаяся бизнес-требований, должны поступать от лиц, четко понимающих, почему они взялись за проект. Это может быть непосредственный заказчик и/или его топ-менеджер. При разработке бизнес-требований следует обратить внимание на необходимость формулирования бизнес-целей в количественном и измеряемом виде. В противном случает по завершении проекта будет очень сложно доказать его успешность. Также следует обратить особое внимание на формулировку критериев успеха, в соответствии с которыми заинтересованные лица будут определять и измерять успех проекта. Необходимо установить факторы, которые максимально влияют на успех проекта – и те, которые вы можете контролировать, и те, которые находятся вне сферы вашего влияния. Важно также четко определить меру для оценки того, были ли достигнуты бизнес-цели. 4.2. Определение образа и границ проекта Образ продукта призван выстраивать работу всех заинтересованных лиц в одном направлении. Образ продукта должен четко определять, что представляет собой продукт как в базовой, так и в последующих версиях. Границы проекта показывают, к какой области конечного долгосрочного образа продукта будет направлен текущий проект. В положении о границах должна быть четко определена черта между тем, что входит в проект и тем, что остается вовне. То есть указанные рамки по существу определяют ограничения проекта. Важно учитывать, что говоря об образе, мы подразумеваем весь продукт. Он будет изменяться относительно медленно при изменении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту – базовой или последующей версиям. То есть границы более динамичны, чем образ, так как менеджер проекта изменяет содержимое каждой версии в соответствии с графиком, бюджетом, ресурсами и ограничениями качества. Таким образом, сбалансированный образ продукта, удовлетворяющий различные заинтересованные лица, должен обобщать долгосрочные цели и назначение нового продукта. Он может быть несколько идеалистичным, но должен быть основан на существующих или предполагаемых рыночных факторах, архитектуре предприятия заказчика, стратегическом направлении развития предприятия заказчика и ограничениях ресурсов. Далее показан шаблон, состоящий из ключевых слов, которые прекрасно подходят для определения образа продукта: для целевая аудитория покупателей продукта который потребности, удовлетворяемые продуктом, и/или возможности, предоставляемые продуктом эта (этот) наименование продукта является категория продукта который(ая) ключевое преимущество, основная причина для покупки или использования в отличие от основной конкурирующий продукт, текущая система или текущий бизнес-процесс наш продукт положение об основном отличии и преимуществе нового продукта Как уже отмечалось, границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц. Определение границы между тем, что входит и выходит за границы проекта, – отличный способ управления расползанием объема и ожиданиями клиентов. На практике обычно определение границ конкретной версии осуществляется перечислением бизнес-требований, которые предполагается в рамках этой версии реализовать. При поэтапной разработке базовая версия не обязательно должна быть быстрой, красиво оформленной или легкой в использовании, но она должна быть надежной; это основа работы команды. Необходимо помнить, что первая версия системы выполняет лишь базовые задачи. В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие легкость и простоту использования. Для более наглядного представления границ проекта желательно использовать контекстную диаграмму. Она определяет оконечные элементы, расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма, по сути, представляет собой высший уровень абстракции в диаграммы потока данных. На подобной диаграмме нет смысла показывать внутренние объекты системы, процессы и данные – она вполне может быть представлена в виде единого объекта. Оконечные элементы обычно представляют классы пользователей, подразделения, другие системы или аппаратные комплексы. Главное назначение подобной диаграммы – наглядно показать, что находится за границами проекта. 4.3. Определение классов пользователей и их характеристик Чтобы не упустить из виду потребности отдельных пользователей, их необходимо подразделить на характерные группы – классы пользователей. Пользователей продукта можно подразделять по таким признакам: • по частоте использования продукта; • по опыту в предметной области и опыту работы с компьютерными системами; • по требуемой им функциональности; • по задачам, которые им приходится выполнять; • по правам доступа к системе (например, обычный пользователь, гость или администратор). На основе подобных признаков и формируются классы пользователей. При формировании классов пользователей также необходимо учитывать, что некоторых пользователей можно отнести к нескольким классам. Так, администратор иногда работает с системой, как рядовой пользователь. Очень заманчиво поделить пользователей на классы по их географическому положению, виду бизнеса, которым занимается компания, или занимаемой должности, а не на основании того, как они взаимодействуют с системой. В действительности же таким образом выделяются потенциальные сегменты рынка, а не различные классы пользователей. Одни классы пользователей для вас важнее других. Когда вы принимаете решения о приоритетах или пытаетесь найти компромисс требований, выдвигаемых различными классами пользователей, мнение привилегированных классов имеет первостепенное значение. К последним относятся группы пользователей, работа которых с продуктом определяет, способствует ли он достижению заявленных бизнес-целей или нет. Это отнюдь не означает, что заинтересованных лиц, оплачивающих разработку системы (они, вполне вероятно, вообще не являются ее пользователями), или тех, кто имеет большое политическое влияние, следует обязательно включать в привилегированные классы. Непривилегированные классы составляют те пользователи, которые по причинам безопасности, конфиденциальности или правовым причинам используют ограниченную функциональность продукта. Остальные классы пользователей можно проигнорировать. Они получат то, что получится, то есть при разработке системы вам не надо учитывать их интересы. Это может показаться необычным, однако классы пользователей не обязательно состоят из людей. В качестве дополнительных классов пользователей можно рассматривать сторонние приложения и аппаратные компоненты, с которыми взаимодействует ваша система. 4.4. Определение представителей пользователей В процессе выявления требований аналитикам придется в той или иной мере общаться с большинством пользователей, но для эффективной разработки требований необходимо более тесное взаимодействие. Естественно организовать такое взаимодействие со всеми пользователями вряд ли возможно. Более того – в этом случае вы неизбежно столкнетесь с проблемами организации работ в больших группах. Поэтому общепринятой практикой является выделение в каждом классе представителей для участия в разработке требований. По существу – это человек, который сможет точно передавать настроения и нужды соответствующего класса пользователей и принимать решения от их лица. Естественно, такой выбор можно сделать только после определения классов пользователей. Выбранные вами люди должны принимать постоянное участие в проекте (они включаются в состав Группы разработки требований) и обладать полномочиями для принятия решений, касающихся пользовательских требований. 4.5. Определение лиц, принимающих решения Вполне понятно, что кто-то должен устранять конфликты между требованиями разных классов пользователей, сглаживать противоречия и решать возникающие вопросы относительно границ проекта. Поэтому уже на ранних стадиях проекта необходимо определить тех, кто будет принимать решения, касающиеся требований. Если не ясно, кто за это отвечает, или уполномоченные лица отказываются брать на себя такую ответственность, в конечном итоге принятие решения возлагается на разработчиков. Это – неудачный выход, поскольку у разработчиков обычно нет необходимых знаний, опыта и стратегического видения для принятия оптимальных бизнес-решений. Не существует единственно верного ответа на вопрос о том, кто должен принимать решения по требованиям к программному проекту. Однако, по возможности, решения должны принимать сотрудники низких уровней организационной иерархии, которые непосредственно занимаются выпуском продукта, и пользователи, которые непосредственно будут работать с продуктом. Для упрощения процедуры принятия решений также необходимо определить соответствующие правила решения. 4.6. Выбор способов выявления требований Существует большое множество апробированных способов выявления требований. Однако далеко не все из них универсальны и применимы в любых ситуациях. Одни способы ориентированы на ситуации, когда разрабатываемый проект является частью другого высокоуровневого проекта, другие – на ситуацию, когда разрабатываемый продукт представляет собой некоторую разновидность уже существующих продуктов, третьи – на ситуацию, когда проект направлен на модернизацию существующего продукта и т.п. Иными словами, выбор способов выявления требований существенно зависит от специфики конкретного проекта. С другой стороны способы выявления требований различаются по затратам, требующимся на их осуществление. Следовательно, нельзя указать какой-либо набор способов выявления требований, применимый в любых ситуациях, в особенности, учитывая существующие ограничения по использованию ресурсов. Поэтому весьма важным является правильный выбор способов выявления требований на начальной стадии разработки требований с учетом специфики разрабатываемого проекта. Конкретный набор способов выявления требований фиксируется в Плане-графике разработки требований и служит основанием для планирования необходимых мероприятий и выделения необходимых ресурсов. 4.7. Разработка плана-графика План-график разработки требований является основным документом, регламентирующим разработку требований. В отличие от Решения о разработке требований, устанавливающего лишь основные цели и задачи разработки требований и фиксирующего создание Группы разработки требований, План-график разработки требований: • устанавливает конкретный состав Группы разработки требований и распределение обязанностей среди ее участников; • устанавливает перечень лиц, принимающих решения относительно требований; • определяет правила принятия решений; • определяет перечень используемых способов выявления требований; • определяет перечень работа и мероприятий по разработке требований, сроки их проведения и участников. План-график разработки требований также является основанием для выделения необходимых ресурсов. В зависимости от сложности и масштаба проекта, а также используемых технологических средств планирование работ может осуществляться в виде простого календарного плана, временных диаграмм, диаграмм Гантта или PERT-диаграмм. При планировании работ необходимо учесть ряд важных моментов, не только часто не учитываемых, но и зачастую не осознаваемых. Планы, как правило, расходятся с действительностью. Поэтому современные методологии так и говорят - да, планы будут меняться, да, этого не избежать, просто нужно организовывать процесс так, чтобы минимизировать потери и минимально снизить стоимость внесения изменений в проект. Методологии существуют, но вот цитата из доклада "Хаос" компании Standish Group (статистика по 364 американским компаниям и 23 тысячам проектов): "Только 16.2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52.7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31.1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%". Почему же так происходит? Ответ заключается в нескольких допущениях, о которых обычно никто не задумывается. Допущение первое: в 8-ми часовом рабочем дне 8 рабочих часов. По статистике, в наиболее продвинутых компаниях с жестко поставленным процессом и направленной на это корпоративной культурой за день работе отдается до 7-и часов. Это лучший результат. Вывод первый: составляя планы, не забывайте, что даже при хорошем раскладе в рабочем дне не восемь, а скорее всего лишь 6 часов, на которые вы и можете рассчитывать. Допущение второе: все рабочее время будет затрачено на выполнение запланированных работ. Обычно запас времени на непредвиденные ситуации вычисляют в процентах от общей продолжительности проекта. Естественно конкретная величина зависит от множества факторов, но более или менее разумной величиной принято считать 5-6%. Вывод второй: составляя планы, не забывайте включать в них запас по времени для непредвиденных ситуаций. 5. Выявление требований Выявление требований по существу является базовым процессом разработки требований. На Рис. 5 -4 представлена детальная модель процесса выявления требований. Рис. 5‑4. Модель выявления требований В общем виде процесс выявления требований распадается на процесс планирования конкретных мероприятий по выявлению требований, собственно процессы выявления различных видов требований и процесс формулирования выявленных требований в виде проекта требований. При отсутствии хорошо структурированной организационной схемы и четкого плана мероприятий собрать воедино мнения множества пользователей весьма трудно. Проблемы возникают и если вам приходится выслушивать нескольких пользователей, и если вы имеете дело с наиболее громогласным и упрямым клиентом. Вы можете упустить из виду требования, важные для определенных классов пользователей, или включить требования, которые не отражают потребности большинства. Чтобы соблюсти баланс, следует привлечь сторонников продукта, обладающих полномочиями для выступления от лица всех соответствующих классов пользователей. Но этого мало. Необходимо четко планировать каждый цикл выявления требований. Часто говорят, что суть требований заключается в том, что система должны делать, а то, как решение будет реализовано, относится к области дизайна. Хотя эта формулировка заманчиво кратка, по сути она примитивна. Выявление требований действительно должно быть сосредоточено на этом что, но области анализа и дизайна разделяет размытая линия, а не четкая граница. В действительности эти гипотетические как помогают уточнить и детализировать понимание потребностей пользователей. Модели анализа, наброски того, что видно на экране, и прототипы помогают в ходе выявления требований более осязаемо выразить потребности и избежать ошибок и упущений. Однако следует довести до всех участников выявления требований (в особенности - со стороны клиента), что какие-либо модели и дизайнерские решения, выработанные в процессе формулирования требований, необходимо воспринимать как концептуальные предложения, упрощающие эффективное взаимодействие, а не как ограничения возможностей, доступных разработчику. Необходимо объяснить пользователям, что эти средства служат только для иллюстрации идей и необязательно попадут в окончательные решения. Критический взгляд пользователя на разрабатываемое программное обеспечение крайне важен для создания продукта отличного качества, и поэтому с самого начала необходимо привлечь пользователей к работе над проектом. Качество выявленных требований к программному обеспечению, а, следовательно, и успех самого программного обеспечения зависит от того, насколько хорошо голос пользователей будет услышан разработчиками. Вовлечение пользователей в работу над проектом – единственный способ избежать их претензий и разочарования, когда они получают не тот продукт, который ожидали. Недостаточно просто расспросить нескольких пользователей о том, как они представляют продукт, чтобы немедля браться за дело. Если разработчики будут выполнять все требования пользователей, им, скорее всего, только и придется, что переделывать продукт, поскольку пользователи зачастую сами не знают, чего им требуется на самом деле. 5.1. Основные источники получения информации о потребностях пользователей Ниже приведено несколько типичных источников и способов получения информации в ходе выявления требований к программному обеспечению. Поскольку источники получения информации от пользователей зависят от специфики разрабатываемого продукта и среды разработки, выбор конкретных источников обычно осуществляется в ходе подготовки к разработке требований. 5.1.1. Опросы потенциальных пользователей и дискуссии с ними Самый очевидный способ выяснить потребности потенциальных пользователей нового программного продукта – опросить их. Выясните у пользователей, какие задачи им требуется выполнять средствами программного обеспечения. Обсудите, как должен клиент взаимодействовать с системой для выполнения каждой такой задачи. Воспользуйтесь типовым шаблоном для документирования всех задач и для каждой сформулируйте функциональные требования. Такой прием, как создание документа с концепциями операций, где указаны характеристики новой системы сточки зрения пользователя, является очень хорошей основой для разработки детальных требований. 5.1.2. Документы, где описан уже работающий или конкурирующий продукт Эти документы помимо функционального описания могут также содержать корпоративные или отраслевые стандарты, которых необходимо придерживаться, а также ссылки на постановления и законы, которым должен соответствовать продукт. Пригодятся и описания уже реализованных и будущих бизнес-процессов. Опубликованные сравнительные обзоры позволяют выявить недостатки других аналогичных продуктов, на которые стоит вовремя обратить внимание, чтобы получить конкурентное преимущество. 5.1.3. Спецификации требований к системе верхнего уровня Для продукта, включающего программные и аппаратные компоненты, создается спецификация требований к системе, описывающая продукт в целом. Отдельные требования к системе в целом касаются каждой подсистемы. Аналитик может вычленить дополнительные, более мелкие функциональные требования из требований к конкретной подсистеме. 5.1.4. Отчеты об ошибках и претензии к возможностям работающей системы Персонал внутрикорпоративной и выездной службы поддержки – ценный источник информации. Они в курсе проблем, с которыми сталкиваются пользователи работающей системы, и постоянно выслушивают идеи клиентов по совершенствованию ее следующей версии. Поступающие от клиентов отчеты о проблемах и предложения о расширении функциональности – отличный источник идей о возможностях, которые можно реализовать в следующей версии или новом продукте. За подобной информацией стоит обратиться и к персоналу службы поддержки. 5.1.5. Маркетинговые исследования и опросы пользователей Опросы потенциальных пользователей продукта способны предоставить массу информации. Опрос позволяет проверить, насколько четко вы понимаете требования, выявлением которых вы занимаетесь, однако это не лучший способ стимулировать творческое мышление. Опросы хотя и весьма распространенный инструмент получения данных, но, в тоже время, инструмент, имеющий множество погрешностей. Прежде чем начать опрос, необходимо критически изучить перечень вопросов. Неоднозначно сформулированные или пропущенные вопросы могут свести пользу опроса на нет. Вообще, прежде чем рассылать сотрудников для проведения опроса, необходимо проконсультироваться с экспертом по планированию и управлению опросами, дабы убедиться, что вы задаете нужные вопросы нужным людям. В противном случае ценность полученной информации будет весьма сомнительна. 5.1.6. Наблюдение за пользователями на рабочих местах Наблюдая «один рабочий день из жизни пользователя», аналитик может выявить особенности работы действующей системы, а также потребности потенциальных пользователей будущей системы. Такое исследование позволяет проверить информацию, собранную в ходе интервью, определить темы новых опросов, выявить проблемы действующей системы и понять, какие функции новой системы необходимы для автоматизации операций. Наблюдая за работой пользователей, вы лучше и полнее поймете суть рабочего процесса, чем если просто попросите их описать все этапы их работы. Излагая и обобщая данные, аналитик должен абстрагироваться от ситуации и рассматривать ее несколько «сверху». Это гарантирует, что собранные требования будут представлять интересы класса пользователей в целом, а не отдельных лиц. Кстати, опытные аналитики зачастую способны предложить что-то весьма дельное для совершенствования текущих бизнес-процессов. Наблюдая за работой пользователей, можно выявить контекст потенциального применения нового продукта. Простые диаграммы рабочих потоков, а также диаграммы потоков данных позволяют выяснить, где, как и какие данные задействовал пользователь. Документируя ход бизнес-процесса, удается определить требования к системе, предназначенной для поддержки этого процесса. Иногда даже выясняется, что для выполнения отдельных деловых задач клиентам вовсе и не требуется новое программное обеспечение. 5.1.7. Описание событий и реакций на них Данный способ основывается на перечислении внешних событий и соответствующих реакций системы на них. Данный способ особенно хорош для систем реального времени, которые считывают и обрабатывают потоки данных, коды ошибок, управляющие сигналы и сигналы прерывания от внешних устройств. 5.1.8. Повторное использование требований в разных проектах Если необходимая клиенту функциональность аналогична уже реализованной в другом продукте, подумайте, готовы ли клиенты гибко пересмотреть свои требования для использования существующих компонентов. Требования, соответствующие бизнес-правилам компании, можно применить в нескольких проектах. Это требования к безопасности, определяющие порядок доступа к приложениям, и требования, соответствующие постановлениям правительства. 5.2. Основные способы выявления требований Несмотря на обилие источников требований, и способов их выявления в практике выявления требований обычно используются два основных способа выявления требований: индивидуальные интервью и групповые семинары. 5.2.1. Интервью Возможно, выявление требований – самый трудный, важный, подверженный ошибкам и требующий интенсивного общения этап разработки программного обеспечения. Эта процедура может оказаться успешной только при условии сотрудничества пользователей и разработчиков. Основной задачей аналитика при проведении интервью является создание атмосферы, благоприятной для тщательного рассмотрения всех аспектов разрабатываемого программного обеспечения. Чтобы облегчить общение, необходимо использовать лексику соответствующей предметной области (мы уже говорили о необходимости создания бизнес-словаря), а не прессинговать пользователей специфическим компьютерным жаргоном. Также следует объяснить пользователям, что обсуждение возможной функциональности – это еще не обязательство включить ее в продукт. Этот этап обособлен от анализа приоритетов, осуществимости и ограничений, налагаемых реальностью. Мастерство управления дискуссией по выявлению требований приходит с опытом, очень помогают в таком деле тренинги, где слушатели учатся брать интервью, общаться в группах, разрешать конфликтные ситуации и т.д. Существует множество методик проведения интервью, подходящих для выявления требований. Интервью можно построить так, что активную роль будет играть аналитик. Даже просто задавая вопросы типа «Почему?», вы сможете легко перейти от обсуждения уже существующего решения к выявлению проблем и имеющихся потребностей. Вопросы, допускающие несколько вариантов ответа, помогут вам разобраться в бизнес-процессах и понять, как новая система повысит их эффективность. Поинтересуйтесь, какие задачи собираются выполнять пользователи, и как они будут работать с системой. Другой подход – влезть в «шкуру» новичка, которого обучает опытный пользователь. Вы задаете массу вопросов, а он управляет беседой, выбирая важную, с его точки зрения, тему для обсуждения. Весьма плодотворным является метод исключений. Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на различные, ошибочные условия? Задавайте вопросы, начинающиеся со слов: «Что еще могло бы...», «Что произойдет, когда...», «Вам когда-нибудь требовались...», «Где вы получаете...», «Почему вы делаете (или не делаете)...» и «А кто-нибудь когда-либо...». При разработке следующей версии системы или модернизации существующей системы, попросите пользователей припомнить три вещи, которые раздражают их сейчас больше всего. Этот вопрос поможет вам понять, почему же систему следует менять. При этом также становится ясно, чего же ждут пользователи от новой системы. Как и при любой модификации, неудовлетворенность настоящим дает отличную пищу для принятия нового. Специалисты рекомендуют использовать бесконтекстные вопросы, узкоспециализированные вопросы и вопросы, допускающие разные толкования, чтобы выявить информацию о бизнес-проблемах и их возможных решениях. Реакция пользователей на такие вопросы, как «Какой уровень точности необходим в продукте?» или «Почему вы не согласны с предложенным ответом?», иногда более информативна, чем информация, получаемая в ответах на вопросы типа «да/нет» или «А/В/С». В процессе сбора информации работающий творчески аналитик должен не только фиксировать ответы пользователя, но и постоянно предлагать пользователям новые идеи и альтернативы. Иногда пользователи просто не представляют, какие возможности готовы предоставить разработчики; они весьма обрадуются, если вы предложите функциональность, которая сделает систему особенно удобной. В тех случаях, когда пользователи не способны ясно выразить свои потребности, аналитику стоит понаблюдать за их работой, чтобы самому разобраться, какие операции следует автоматизировать и в каком объеме. Зачастую именно аналитикам удается выйти за рамки, ограничивающие мышление людей слишком тесно связанных с конкретной предметной областью. Аналитик также должен искать удобные случаи повторно использовать функциональность, которая уже реализована в других системах. Если пользователей ознакомить с имеющимися наработками, то возможно их взгляды на разрабатываемую систему изменятся. Интервью с отдельными потенциальными пользователями или с группами – традиционный источник информации при сборе требований, касающихся как коммерческих продуктов, так и информационных систем. Вовлечение пользователей в процесс сбора информации в активное взаимодействие – это способ получить поддержку, в том числе и финансовую, проекта. Попытайтесь понять, из чего следуют конкретные требования пользователей. Поэтапно рассмотрите работу пользователей и постарайтесь понять ее логику. Блок-схемы и деревья решений позволяют отобразить логические пути принятия решений. Убедитесь, что все понимают, почему система должна выполнять конкретные функции. Иногда предложенные требования отражают устаревшие или неэффективные бизнес-процессы, которые не следует встраивать в новую систему. Частой ошибкой является механический перенос существующих бизнес-процедур в разрабатываемую систему, в особенности, если ранее эти бизнес-процедуры не были автоматизированы. Такие бизнес-процедуры разрабатывались совершенно для другого контекста и вряд ли их целесообразно реализовывать современными средствами компьютерных технологий. После каждого интервью документируйте элементы, обсуждавшиеся группой, и попросите интервьюируемых просмотреть список и внести исправления. Просмотр на ранних стадиях необходим для успешного сбора требований, поскольку только те люди, которые эти требования предоставили, могут судить, правильно ли они зафиксированы. В дальнейшем также не отказывайтесь от обсуждений – это позволит разрешить все противоречия и заполнить пробелы. Аналитик также должен после каждого интервью просматривать полученные материалы. Необходимо как можно раньше выявлять все конфликты и упущения. Также весьма желательно выявить все те возможности или характеристики, которые пользователи полагают само собой разумеющимися и даже не считают нужным обрисовать. Задокументируйте источник каждого требования, чтобы, если потребуется, понять их причину и проследить, на каких же потребностях клиентов основываются те или иные направления разработки. 5.2.2. Проведение совместных семинаров Совместные семинары по выявлению требований, где тесно сотрудничают аналитики и пользователи – отличный способ выявить нужды пользователей и составить наброски документов с требованиями. Аналитики требований часто проводят совместные семинары, упрощающие сбор информации о требованиях. Это позволяет весьма эффективно наладить связи между пользователями и разработчиками. Основная задача ответственного за мероприятие сотрудника – создать условия для успешного проведения семинара: именно он планирует семинар, выбирает участников и следит, чтобы обсуждение проводилось продуктивно. Весьма правильным шагом будет также назначение секретаря, чтобы он фиксировал все идеи, возникающие в ходе обсуждения. Однако при проведении семинаров существует и множество опасностей: совместное обсуждение может перейти в бесполезные споры, участники могут увлечься обсуждением несущественных вопросов и т.п. Чтобы избежать подобной опасности необходимо использовать ряд приемов. 5.2.2.1. Определите основные правила Участники должны договориться об основных правилах проведения семинаров. Например, таких: • своевременно начинать и заканчивать семинар; • не опаздывать после перерывов; • не проводить несколько обсуждений одновременно; • следить, чтобы каждый принимал участие в работе; • комментировать и критиковать решение, а не личность. 5.2.2.2. Придерживайтесь границ проекта Чтобы удостовериться, что предлагаемые пользовательские требования не выходят за текущие границы проекта, используйте задокументированный образ и границы проекта. Следите, чтоб на каждом семинаре уровень обобщения соответствовал выбранным целям. Периодически участники могут углубляться в обсуждения несущественных деталей. На это уходит масса времени, которое на начальном этапе работы следует потратить на прояснение пользовательских требований – время деталей наступит позже. Задача организатора – по мере необходимости возвращать участников к теме обсуждения. Пользователи легко переходят к обсуждению того, где в отчете или диалоговом окне следует разместить элементы, даже еще до того, как разработчики согласятся с поставленными задачами. Если вы включите данные детали в требования, то тем самым ограничите процесс разработки. Хотя предварительные наброски интерфейса полезны на любом этапе, особенно для иллюстрации возможных способов реализации требований, к детальной разработке пользовательского интерфейса следует приступать позднее, после определения основных требований. 5.2.2.3. Фиксируйте темы для дальнейшего обсуждения На семинаре всплывает масса случайных, но важных сведений: атрибуты качества, бизнес-правила, идеи по разработке пользовательского интерфейса, ограничения и т.п. Их необходимо фиксировать по ходу семинара на карточках, плакатах, доске или иным удобным способом. Главное при этом – их доступность всем участникам семинара. Действуя подобным образом, вы не потеряете эти сведения и продемонстрируете уважение участнику, высказавшему их. Не отвлекайтесь на обсуждение деталей, не относящихся к теме дискуссии, если только они не окажутся важными, например бизнес-правилом, которое ограничивает варианты использования. 5.2.2.4. Ограничивайте некоторые дискуссии по времени Организатор семинара имеет право ограничить время обсуждения каждой темы, скажем, первоначально – 30 минут на каждый вариант использования. Возможно, некоторые дискуссии придется завершить позднее, но жесткие временные рамки помогают не тратить времени больше, чем запланировано. В противном случае времени может не хватить на обсуждение всех запланированных тем. Хорошей практикой является подведение ведущим итогов обсуждения каждой темы в последние 3-5 минут, выделенного на обсуждение времени, даже если обсуждение еще не закончено. В подобном резюме фиксируются все нерешенные вопросы, а также необходимость дальнейшего обсуждения. При таком подходе все запланированные темы будут обсуждены, а при наличии резерва времени в конце семинара можно будет вернуться к обсуждению спорных тем. 5.2.2.5. Не увеличивайте размер команды и тщательно отбирайте участников Небольшие группы работают намного быстрее. Семинары, число активных участников которых превышает пять или шесть человек, могут превратиться в отвлеченные дискуссии, споры и даже ссоры. Попробуйте одновременно проводить несколько семинаров, например, с различными классами пользователей. В обсуждении, как правило, должны участвовать сторонник продукта и другие представители пользователей, возможно, эксперт в данной предметной области, аналитик требований и разработчик. Допуском к участию в семинарах по сбору информации являются знания, опыт и право принимать решения, а не желание кого-либо "поучаствовать". 5.2.2.6. Вовлекайте в обсуждение каждого Иногда участники самоустраняются от обсуждения, например, расстроившись из-за того, что не представляют себе ценность системы. Возможно, их идеи не воспринимают серьезно, поскольку другим участникам их концепции кажутся неинтересными или группа не хочет отвлекаться от текущей дискуссии. Возможно, аутсайдер не уверен в себе и уступил право голоса более активным сотрудникам или главному аналитику. Организатору семинара необходимо следить за языком телодвижений, чтобы разобраться в причинах замкнутости того или иного участника, и попытаться снова вовлечь его в работу. Ведь интуитивное представление каждого может оказаться очень ценным. 5.3. Специфика выявления различных требований Процесс выявления требований ориентирован на выявление всех требований "пользовательского" уровня: вариантов использования и функциональных требований, характеристик операционной среды, ограничений дизайна и реализации, требований к внешнему интерфейсу, требований к производительности и атрибутов качества. На данном этапе предполагается, что бизнес-требования уже разработаны, а образ и границы проекта определены. Основные источники и способы выявления данных требований одинаковы и рассмотрены выше. Однако есть некоторые моменты, которые необходимо учитывать при выявлении отдельных видов требований. 5.3.1. Бизнес-правила Как уже отмечалось бизнес-правила находятся вне контекста любой системы. Это накладывает определенные ограничения на способы их выявления. Так невозможно выявить все необходимые бизнес-правила, ограничившись работой с пользователями разрабатываемой системы. Если организация-заказчик имеет формальный свод используемых бизнес-правил (что обычно встречается крайне редко), его можно будет принять за основу и пополнять в ходе обсуждения других требований. В противном случае придется вести целенаправленную работу по выявлению бизнес-правил в ходе выявления других требований. Поскольку бизнес-правила лежат вне контекста системы, а следовательно имеют общий характер, большинство организаций разработчиков ведут собственный каталог бизнес-правил, постоянно обновляемый в ходе реализации различных проектов. Такой общий каталог может служить прекрасной основой для составления каталога бизнес-правил для конкретного проекта. 5.3.2. Требования к производительности Требования к производительности определяют, насколько быстро и качественно система должна выполнять определенные функции. Они определяют такие параметры, как скорость (например, время отклика БД), пропускная способность (количество транзакций в секунду), мощность (нагрузка при совместном использовании) и распределение по времени (интенсивные запросы реального времени). Жесткие требования к производительности сильно влияют на стратегию разработки программного обеспечения и выбор оборудования, поэтому определяйте требования, касающиеся производительности, для конкретной операционной среды. Все пользователи хотят, чтобы их приложение запускалось моментально, но реальные требования к производительности должны быть обусловлены важностью соответствующих функций для реализации бизнес-целей. Все показатели производительности должны быть предельно конкретными и измеримыми. Требования к производительности также должны учитывать снижение производительности при перегрузках. 5.3.3. Атрибуты качества Дизайнеры и программисты должны определить наилучший способ удовлетворения требования для каждого атрибута качества и производительности. Хотя атрибуты качества относятся к нефункциональным требованиям, они помогают сформулировать функциональные требования, определить направления разработки или техническую информацию, которые позволяют реализовать продукт желаемого качества. Иначе говоря, при разумном подходе, атрибуты качества могут стать источником других требований и служить основой для принятия решений относительно дизайна разрабатываемой системы. В приведенной ниже таблице перечислены некоторые категории технической информации, которые могут быть выведены с помощью атрибутов качества. Таблица. Преобразование требований к качеству в техническую документацию Типы атрибутов качества Категория технической информации Целостность, способность к взаимодействию, устойчивость к сбоям, легкость и простота использования, безопасность Функциональное требование Доступность, эффективность, гибкость, производительность, надежность Архитектура системы Способность к взаимодействию, легкость и простота использования Ограничения дизайна Гибкость, легкость в эксплуатации, мобильность, надежность, возможность повторного использования, тестируемость, легкость и простота использования Руководство по дизайну Мобильность Ограничение реализации 5.3.4. Словарь данных Словарь данных (data dictionary) – общее хранилище, где определены значение, тип данных, длина, формат, необходимая степень точности и допустимые диапазоны значений или список значений всех элементов данных и атрибутов, используемых в приложении. Информация в словаре данных связывает различные представления требований. Проблема целостности становится не столь критичной, если все разработчики придерживаются определений из словаря данных. Начинать собирать определения данных желательно еще в процессе выявления требований. Словарь данных по существу дополняет бизнес-словарь проекта, где приведены определения отдельных терминов. Вы можете объединить эти документы, но предпочтительно хранить их отдельно. По сравнению с определениями данных, размещенными в различных местах функциональных требований, отдельный словарь данных облегчает поиск необходимой информации, а также помогает избежать ненужных повторов и несогласованности. Время, потраченное на создание словаря данных, будет более чем компенсировано временем, которое вы сэкономите, избежав ошибок, возможных, если участники проекта по-разному понимают ключевые данные. Если вы регулярно обновляете словарь данных, он останется ценным средством и при обслуживании системы, и при разработке схожих систем. В таблице перечислены некоторые категории технической информации, которые могут быть выведены с помощью атрибутов качества. 6. Анализ требований Анализ требований подразумевает тщательное исследование требований на предмет ошибок, пробелов и других недостатков, а также их детализацию, гарантирующую, что все заинтересованные лица одинаково понимают требования. Кроме того, анализ обычно включает анализ осуществимости требований, определение и согласование приоритетов, а также создание прототипов. На Рис. 6.1 представлена детальная модель процесса анализа требований. Рис. 6‑5. Модель анализа требований Цель анализа – достаточно качественно и подробно определить требования, позволяющие менеджерам реалистично оценить все затраты на проект, а техническому персоналу – начать проектирование, сборку и тестирование. 6.1. Анализ осуществимости требований Прежде чем подвергать выявленные требования подробному анализу, желательно проанализировать осуществимость этих требований. Увы, требование может быть безупречным со всех сторон, но, в тоже время, быть неосуществимым, т.е. нереализуемым при известных условиях и ограничениях создаваемого продукта и операционной среды, в том числе и при оговоренных сроках и объеме финансирования. Естественно не следует тратить ресурсы на подробный анализ и проработку подобных требований - их необходимо отсекать на начальных стадиях анализа. Проанализируйте, насколько реально реализовать каждое требование при разумных затратах и с приемлемой производительностью в предполагаемой среде. Рассмотрите риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями, зависимость от внешних факторов и препятствия технического характера. При анализе осуществимости требований ключевую роль играют разработчики. Именно их мнение будет решающим при принятии решения об отклонении неосуществимых требований. Анализ осуществимости требований - не одноразовая акция и должен осуществляться на каждой итерации разработки требований для всех имеющихся требований, в том числе и для тех, для которых такой анализ уже проводился. Это обусловлено тем, что по мере выявления и разработки требований определяются и уточняются характеристики операционной среды, ограничения дизайна и реализации, требования к внешнему интерфейсу, требования к производительности и атрибуты качества, т.е. по существу уточняются условия и ограничения создаваемого продукта и операционной среды. Естественно, при изменении этих условий и ограничений оценка осуществимости также подлежит пересмотру. 6.2. Определение приоритетов требований Определение приоритетов требований также весьма важный процесс, поскольку приоритеты - это наиболее естественный способ разрешения борьбы между конкурирующими требованиями за ограниченные ресурсы. Правильное определение относительного приоритета каждой возможности позволяет так планировать разработку, чтобы обеспечивать наибольшую ценность при наименьших затратах. Даже одного человека достаточно сложно заставить решить, какие из его требований приоритетнее. Согласовать же мнения нескольких пользователей с различными ожиданиями и мнения разработчиков еще труднее. Люди по природе склонны отстаивать свои интересы и не жаждут жертвовать собственными нуждами ради чужой выгоды. Поэтому для определения приоритетов необходимо воспользоваться аналитическим методом, изложенным в разделе 2.7. Приоритеты полезны не только как средство, упрощающее планирование разработки. Само обсуждение приоритетов помогает не только определить последовательность реализации требований, но и прояснять ожидания пользователей. И пользователи, и разработчики должны внести вклад в определение приоритетов требований. Пользователям больше всего нужны функции, наиболее ценные для бизнеса или обеспечения удобства работы. Однако, когда разработчики обрисуют затраты, трудоемкость, технический риск или компромиссы, связанные с каждым требованием, пользователи могут передумать и прийти к выводу, что это требование не так важно, как они считали изначально. Разработчики же иногда решают на ранних стадиях реализовать некоторые функции с низким приоритетом из-за их влияния на архитектуру системы. 6.3. Моделирование требований Моделирование требований - это ключевой процесс анализа требований, заключающийся в построении различных моделей требований на основе исходных текстовых данных, полученных при выявлении требований. В отличие от подробной информации, представленной в тестовом описании требований, графические модели анализа отображают требования на высоком уровне абстракции. При этом, зачастую представление требований несколькими способами позволяет выявить их особенности и проблемы, не заметные при представлении одним определенным способом. Высокоуровневые модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность – связь», диаграммы перехода состояний, называемые также автоматами (state charts), карты диалогов, диаграммы классов, диаграммы последовательностей, диаграммы взаимодействий, таблицы решений и деревья решений. Выбор конкретных моделей определяется спецификой проекта, а также наличием соответствующих инструментальных средств, поскольку построение моделей без соответствующей инструментальной поддержки приводит к неоправданным затратам ресурсов и чревато ошибками. Для помощи в выявлении требований полезно использовать такую простую модель анализа, как контекстные диаграммы, которые отображают место разрабатываемой системы (или ее части) в соответствующей среде. Поскольку контекстная диаграмма наглядно определяет границы и интерфейсы между разрабатываемой системой (или ее частью) и сущностями, внешними для этой системы, например пользователями, устройствами и прочими информационными системами, ее полезно использовать для визуализации образа и границ проекта в ходе выявления требований. Во всех сомнительных и спорных ситуациях полезно прибегнуть к практике создания прототипов – частичных, упрощенных или предварительных версий продукта, которые делают рассматриваемые концепции и возможности более осязаемыми. Оценка прототипа поможет всем заинтересованным лицам достичь взаимопонимания по решаемой проблеме. 6.4. Поиск упущенных требований Пропуск каких-либо важных данных – самый распространенный недостаток требований. Обнаружить их в процессе повторного просмотра требований очень трудно, поскольку они просто невидимы! Предлагаемые далее приемы позволяют выявить упущенные требования. И в тоже время следует заметить, что не стоит тратить слишком много времени на выявление требований, пытаясь не упустить ни одно из них – все равно вы никогда не выявите их все сразу! • Раскладывайте требования высокого уровня на простейшие составляющие - это позволит понять, чего же именно просят пользователи. Из-за неясности требований высокого уровня, предоставляющих пользователям слишком большую свободу интерпретации, возможно несовпадение представлений пользователей о продукте и тем, что создает разработчик. Вот некоторые неточные и расплывчатые термины, которых следует избегать: обеспечивать поддержку, предоставлять возможность, разрешать, обрабатывать и управлять. Конечно, наличие какого-либо из этих терминов в формулировке требования отнюдь не означает, что это требование неверно, но служит сигналом для проверки необходимости дальнейшей детализации требования. • Убедитесь, что все классы пользователей предоставили вам информацию и для каждого варианта использования определена, по крайней мере, одна роль. • Подробно документируйте, на каких функциональных требованиях основаны требования к системе, варианты использования, списки откликов на события и бизнес-правила. Это позволит вам быть уверенным, что аналитик описал всю необходимую функциональность. • Для выявления недостающих требований проверяйте граничные значения. Предположим, в одном требовании указано: «Если стоимость заказа меньше $100, стоимость доставки будет равна $5.95», а в другом – «Если стоимость заказа превышает $100, стоимость доставки составляет 5% от общей стоимости заказа». А как быть, если стоимость заказа составляет ровно $100? Это не оговорено, значит, отсутствует соответствующее требование. • Используйте разнообразные формы представления информации о требованиях. Трудно прочитать большой объем текста и заметить, что чего-то не хватает. Модели анализа визуально представляют требования высокого уровня абстракции – лес, а не отдельные деревья. Рассматривая модель, вы можете заметить, что от одного блока к другому должна идти стрелка, которой нет, – это тоже недостающее требование. Подобного рода ошибку легче заметить на рисунке, чем в длинном списке требований, который сливается перед глазами. 6.4.1. Матрица CRUDL Одним из точных и продуктивных способов поиска недостающих требований является создание так называемой матрицы CRUD (Create, Read, Update, Delete – создание, чтение, обновление, удаление). Данная матрица позволяет соотнести действия системы с элементами данных (отдельными или их совокупностями), в результате вы получаете представление о том, где и как каждый элемент данных создается, считывается, обновляется и удаляется. Некоторые авторы добавляют к названию матрицы букву L (CRUDL), указывая, что элементы данных можно еще и перечислять (List). Например, при помощи этого инструмента легко проверить полноту и непротиворечивость вариантов использования, построив соответствующую матрицу, где строки – это имеющиеся варианты использования, а столбцы – элементы данных. На пересечении строк и столбцов необходимо расставить пометки операций, выполняемых вариантом использования с элементами данных: C – создание, R – чтение, U – обновление, D – удаление, L – перечисление. Наличие пустых столбцов означает либо отсутствие необходимых вариантов использования, либо ненужность соответствующего элемента данных. Наличие пустых строк означает либо ненужность соответствующих вариантов использования, либо отсутствие необходимых элементов данных. Если в столбце отсутствует признак создания элемента данных, то это явно указывает на неполноту вариантов использования. Если в столбце отсутствует признак удаления элемента данных, то следует разобраться, действительно ли этот элемент не подлежит удалению. Если в столбце отсутствуют признаки использования элемента данных (RUL), то следует разобраться, действительно ли необходим этот элемент данных. Для составления соответствующих матриц CRUDL необходимо использовать словарь данных. При этом анализ матриц позволяет проверить полноту словаря данных и уточнить его при необходимости. Полезной особенностью матриц CRUDL является и то, что их можно начинать составлять не дожидаясь завершения выявления требований и пополнять на каждой итерации. Причем анализ матриц на каждой итерации способен подсказать направления выявления недостающих данных. 7. Документирование требований Итог разработки требований – задокументированное соглашение между клиентами и разработчиками о создаваемом продукте. Способов представления требований несколько: • документация, в которой используется четко структурированный и аккуратно используемый естественный язык; • графические модели, иллюстрирующие процессы трансформации, состояния системы и их изменения, взаимодействия данных, а также логические потоки, классы объектов и отношения между ними; • формальные спецификации, где требования определены с помощью математически точных, формальных логических языков. Последний метод обеспечивает наивысшую степень точности, однако немногие разработчики – и еще меньше клиентов – знакомы с ним, поэтому они не могут, используя этот метод, проверить спецификации на наличие ошибок. Несмотря на недостатки, наиболее практичным подходом остается структурированный естественный язык, дополненный графическими моделями. Будучи конечным хранилищем требований к продукту, спецификация требований к программному обеспечению должна быть ясной и понятной, дабы у разработчиков и клиентов не оставалось ни малейших возможностей для разночтения. Именно эту цель преследуют процессы проверки и исправления формулировок требований на общей модели процесса документирования требований на Рис. 7 -6. Рис. 7‑6. Модель документирования требований Контроль версий и управление статусом требований призваны обеспечить управляемость всех процессов разработки требований, а процесс выпуска версий спецификаций обеспечивает всем участникам разработки точное и единообразное представление о текущем состоянии спецификации требований на всех итерациях процесса разработки требований. 7.1. Общие правила документирования Вся документация этапа разработки требований должна соответствовать шаблонам, которые определяются настоящим Положением. Вся документация этапа разработки требований должна быть согласована и утверждена в соответствии с настоящим Положением. Все члены Группы по разработке требований должны иметь свой экземпляр документа, который подлежит обсуждению. Все рабочие версии документов должны распечатываться с нумерацией строк документа, чтобы облегчить ссылки на обсуждаемые части документа. При обнаружении любых неясностей следует помечать соответствующие места документов специальными маркерами НО (необходимо определить). Все маркеры должны нумероваться строго последовательно, например, НО-001, и сопровождаться датой исполнения и указанием исполнителя. Например: Время реакции системы на запрос должно быть минимальным. При обработке больших объемов данных должно отображаться сообщение о ходе выполнения. Все заголовки, определяющие структуру документа, должны иметь иерархическую нумерацию для обеспечения возможности использования ссылок. 7.2. Правила построения идентификаторов элементов документации Идентификаторы всех элементов документации (требований, определений и т.п.) должны быть уникальными в рамках проекта. Общая структура идентификатора имеет вид: ID-nn, где ID – идентификатор типа, а nn – порядковый номер элемента соответствующего типа. При удалении какого-либо элемента перенумерация оставшихся элементов не производится, а в соответствующем списке элементов идентификатор данного элемента помечается как удаленный. Полное определение элемента дается только в исходном для него документе. В остальных документах делается только ссылка на элемент посредством указания его идентификатора. Подобные ограничения необходимы для обеспечения ссылочной целостности документации и исключения неоднозначных трактовок при изменениях описаний элементов. Идентификаторы различных элементов документации: Бизнес-требования Имеют идентификатор типа BT (Business Requirement – Task) для бизнес-задач и BA (Business Requirement – Aims) для бизнес-целей Бизнес-правила Имеют идентификатор типа BR (Business Rule) Предположения Имеют идентификатор типа А (Assumption) Зависимости Имеют идентификатор типа D (Dependence) Ограничения Имеют идентификатор типа C (Constraint) Действующие лица Имеют идентификатор типа ACT (Actor) Варианты использования Имеют идентификатор типа UC (Use Case). Нормальный поток варианта использования идентифицируется как «X.0», где «X» – идентификатор варианта использования. Например, нормальный поток варианта использования UC-15 будет обозначаться как UC-15.0. Каждый альтернативный поток идентифицируется как «X.Y», где «X» – идентификатор варианта использования, а «Y» – порядковый номер альтернативного потока. Например, UC-15.3 указывает на третий альтернативный поток для варианта использования UC-15. Каждое исключение идентифицируется как «X.Y.E.Z», где «X» – идентификатор варианта использования, «Y» – нормальный поток (0) или альтернативный поток (>0), «E» признак исключения, а «Z» – порядковый номер исключения. Например, UC-15.0.E.2 определяет второе исключительное состояние для нормального потока варианта использования UC-15 Функциональные требования Имеют идентификатор типа FR (Functional Requirement). Поскольку функциональные требования упорядочиваются по вариантам использования, для их идентификации используется схема вида FR-uc-xx, где uc – номер соответствующего варианта использования, а xx – порядковый номер функционального требования. Для всех функциональных требований, которые не связаны с конкретными вариантами использования, или являются общими для нескольких вариантов использования рекомендуется в качестве номера варианта использования указывать нулевое значение. Требования к интерфейсам пользователя Имеют идентификатор типа IU (User Interfaces) Требования к интерфейсам оборудования Имеют идентификатор типа IH (Hardware Interfaces) Требования к интерфейсам программного обеспечения Имеют идентификатор типа IS (Software Interfaces) Требования к интерфейсам передачи информации Имеют идентификатор типа IC (Communications Interfaces) Требования к производительности Имеют идентификатор типа PR (Performance Requirements) Атрибуты качества Имеют идентификатор типа QA (Quality Attribute) 7.3. Особенности документирования спецификации требований С одной стороны, точно сформулированные требования повышают вероятность того, что ожидания клиентов будут реализованы. С другой стороны, менее строгие формулировки дают разработчикам больше свободы для интерпретаций. Поэтому создатели документации зачастую тратят массу сил, чтоб «поймать» нужный уровень детализации требований. Косвенным свидетельством верно выбранного уровня детализации является то, что разработчики способны предложить несколько способов удовлетворения требования и все они приемлемы. Если же разработчикам по составленной спецификации не удается абсолютно ясно представить себе ожидания клиентов, следует включить дополнительную информацию, чтобы снизить риск последующих исправлений. При написании требований также следует соблюдать выбранный уровень детализации, т.е. не следует допускать в спецификации требований, уровень детализации которых существенно различается. Следует избегать длинных повествовательных абзацев, которые содержат несколько требований. Наличие в требовании таких слов, как «и», «или» и «также», допускает возможность объединения нескольких требований. Это вовсе не означает, что эти союзы не могут использоваться в формулировках требований, но их наличие должно служить указанием на необходимость проверки возможности объединения требований. Никогда не следует использовать «и/или» в требованиях; поскольку это оставляет читателю свободу маневра, а, следовательно, содержит потенциальную возможность неоднозначной трактовки. Такие выражения, как «пока не» и «кроме» также указывают на наличие нескольких требований. Следует избегать и излишних положений о требованиях. Повторяя требования в нескольких местах спецификации требований к программному обеспечению, вы облегчаете чтение документа, но затрудняете его поддержку. Одинаковые требования придется изменять одновременно, в противном случае возникнет несогласованность. Перекрестные ссылки на связанные между собой элементы в спецификации помогут вам синхронизировать последние при внесении изменений. 7.4. Особенности документирования бизнес-правил Поскольку бизнес-правила зачастую влияют на множество проектов, следует управлять этими правилами на корпоративном уровне, а не на уровне проектов. Для начала достаточно простого каталога бизнес-правил. Большим организациям, а также компаниям, деловые операции и информационные системы которых в значительной степени регулируются и управляются бизнес-правилами, следует создать базу данных таких правил. По мере того, как вы при работе над проектом определяете новые правила, добавляйте их в каталог, а не вписывайте в документацию конкретного проекта или, что еще хуже, только в его код. При неправильном использовании правила, относящиеся к безопасности, защите, финансам и соответствию различным постановлениям, становятся весьма опасными. Не следует пытаться сделать каталог бизнес-правил более сложным, чем необходимо. Для проектов среднего масштаба можно использовать шаблон каталога бизнес-правил, прилагаемый к настоящему положению. Хорошей практикой является ведение корпоративного каталога бизнес-правил, который развивается и пополняется по мере работы над конкретными проектами. Для конкретного проекта следует делать адаптированную копию данного каталога, исключая из нее все ненужные для проекта правила и добавляя специфические. 7.5. Формулирование требований При формулировании требований следует соблюдать ряд правил. 1. Используйте полные предложения, с правильной грамматикой, правописанием и пунктуацией. Предложения и абзацы должны быть краткими и ясными. 2. Используйте действительный залог (например, «Система сделает то-то», а не «Произойдет то-то»). 3. Последовательно используйте термины и именно так, как они определены в словаре. Остерегайтесь синонимов и слов, близких по значению. Не следует в спецификации требований к програм­мному обеспечению пытаться разнообразить лексику, чтобы заинтересовать читателя. Помните – спецификация представляет собой формальный документ, а не художественное произведение. 4. Требования следует излагать последовательно, например «Система будет» или «Пользователь будет», затем – активный глагол, а после – наблюдаемый результат. Укажите инициирующие условия или действия, вследствие которых система ведет себя определенным образом. Например, «Если запрошенный товар найден на складе, система отобразит список всех хранимых на складе контейнеров с указанным товаром». Вы можете использовать «должно» как синоним «будет», однако следует избегать «следовало бы», «может», «можно было бы» и аналогичных слов, из которых не ясно, необходимо ли описываемое действие. 5. При указании требования в форме «Пользователь будет...» идентифицируйте определенного исполнителя (например, «Покупатель будет...»). 6. Применяйте списки, рисунки, графики и таблицы, чтобы представить информацию визуально. Читателей утомляет большой объем сплошного текста. 7. Подчеркните наиболее значимые фрагменты информации. Здесь годятся: графики, последовательности, в которых первый элемент подчеркивается, повторы, пустое пространство и визуальный контраст, например затенения. 7.6. Термины, которых следует избегать в спецификации требований При записи требований следует избегать множества привычных и обыденных терминов, имеющих неоднозначный характер. Ловушка в использовании подобных терминов заключается в том, что в процессе обсуждения все формулировки кажутся понятными, но при последующем чтении этих формулировок вне контекста обсуждения возникает неоднозначность. В приведенной ниже таблице показаны распространенные термины, порождающие неоднозначность, и способы устранения неоднозначности. Таблица 7‑4. Устранение неоднозначностей в формулировках требований Неоднозначный термин Способы устранения неоднозначности Приемлемый, адекватный Определите, что понимается под приемлемостью и как система это может оценить Практически выполнимо Не заставляйте разработчиков определять, что под этим понимается. Поставьте пометку НО (необходимо определить) и определите дату, к которой эту проблему следует разрешить По меньшей мере, как минимум, не более чем, не должно превышать Укажите минимальное и максимальное допустимые значения Между Определите, указаны ли конечные точки Зависит от Определите природу зависимости. Обеспечивает ли другая система ввод данных в вашу систему, надо ли установить другое ПО до запуска вашей системы и зависит ли ваша система от другой при выполнении определенных расчетов или служб Эффективный Определите, насколько эффективно система использует ресурсы, насколько быстро она выполняет определенные операции и насколько она проста в обращении Быстрый, моментальный Укажите минимальную приемлемую скорость, при которой система выполняет определенное действие Гибкий Опишите способы изменения системы в ответ на изменения условий или бизнес-потребностей Улучшенный, лучший, более быстрый, превосходный Определите количественно, насколько лучше или быстрее стали показатели в определенной функциональной области Включает; включает в себя, но не ограничен этим; и т.д., и т.п.; такой как Список элементов должен включать все возможности. В противном случае его нельзя использовать при разработке или тестировании Максимизируйте, минимизируйте, оптимизируйте Укажите минимальное и максимальное допустимые значения определенного параметра Обычно, в идеальном варианте Также опишите поведение системы при нештатных или неидеальных условиях Необязательно Укажите, кто делает выбор: системы, пользователь или разработчик Разумный, при необходимости, при соответствующих условиях Объясните, как это выполнить Устойчивый к сбоям Определите, как система должны обрабатывать исключения и реагировать на неожиданные условия работы Цельный, прозрачный, элегантный Выразите ожидания пользователя, применяя характеристики продукта, которые можно наблюдать Несколько Укажите сколько или задайте минимальную и максимальную границы диапазона Не следует Старайтесь формулировать требования в позитивной форме, описывая, что именно система будет делать Реальный Поясните этот термин Достаточный Укажите, какая степень чего-либо свидетельствует о достаточности Поддерживает, позволяет Дайте точное определение, какие действия система будет выполнять, поддерживая конкретную возможность Дружественный, простой, легкий Опишите системные характеристики, которые будут отвечать потребностям пользователей и его ожиданиям, касающимся легкости и простоты применения продукта 7.7. Контроль версий Контроль версий – это важный аспект управления спецификациями требований и другими проектными документами. Каждой версии следует присвоить уникальный идентификатор. У каждого члена команды должен быть доступ к текущей версии требований, а изменения необходимо ясно документировать и передавать всем заинтересованным сторонам. Чтобы минимизировать путаницу, конфликты и непонимание, назначьте право обновления требований строго определенным лицам и убедитесь, что идентификатор версии изменяется при каждом изменении требования. Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Текущая версия документа должна указываться в колонтитуле. Простейший механизм управления версиями – именовать вручную каждую версию спецификации требований к программному обеспечению согласно соглашению. Попытка различать версии документов по дате изменения или дате печати часто приводит к ошибкам и неразберихе. 7.8. Контроль статуса требований Контроль статуса требований на протяжении всей разработки позволяет более точно оценивать готовность проекта, чем отслеживание степени выполнения задач. В таблице, приведенной ниже, перечислено несколько возможных состояний требований: Таблица 7‑5. Статус требований Код Статус Определение P Предложено (Proposed) Требование запрошено авторизированным источником A Одобрено (Approved) Требование проанализировано и его влияние на проект просчитано. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики обязались реализовать его V Проверено (Verified) Корректность требования подтверждена соответствующей проверкой или тестированием. Теперь требование считается завершенным R Отклонено (Rejected) Требование предложено, но не запланировано для реализации ни в одной из будущих версий. Следует описать причины отклонения требования и указать того, кто принял это решение Статус «Отклонено» позволяет оставить предложенное требование доступным для будущего использования, не создавая беспорядка в наборе утвержденных требований для определенного выпуска. Более того, отслеживать требования, от которых вы отказались, и причины этого отказа весьма полезно, потому что как показывает опыт, отвергнутые требования имеют обыкновение «всплывать» в ходе дальнейшей разработки. Распределение требований по нескольким категориям состояния имеет больший смысл, чем попытка контролировать процент завершения каждого требования или всей базовой версии. Определите, кто может изменить состояние требования, и обновляйте статус, только когда удовлетворены определенные условия перехода. Основная часть работ считается выполненной, когда всем требованиям назначено состояние «Проверено» (реализуется, как запланировано) или «Отклонено» (не подлежит реализации). 8. Проверка и утверждение требований Недостаточно просто написать требования – необходимо убедиться, что именно эти требования и нужны и что они достаточно хороши, чтобы стать основой для дизайна, сборки, тестирования и управления проектом. Планирование тестов приемлемости, неофициальных просмотров требований, экспертизы спецификации требований к программному обеспечению и тестирование требований –это то, что поможет вам собрать продукт высокого качества с приемлемыми затратами Проверка и утверждение требований является по существу контролирующим процессом разработки требований. Именно в рамках данного процесса принимаются решения о приемлемости требований и завершении всего процесса разработки базовой спецификации требований. На каждой итерации разработки требований в рамках данного процесса осуществляется просмотр всех изменений и дополнений текущей версии спецификации требований для проверки их соответствия критериям качества и выявления имеющихся проблем. При обнаружении проблем формулируется соответствующий запрос на устранение недостатков. Если же просмотр не выявляет каких-либо проблем, то проводится экспертиза и тестирование требований. По выполнении критериев завершения выявления требований, а также завершении экспертизы и тестирования имеющихся требований, осуществляется утверждение базовой версии спецификации требований. Рис. 8‑7. Модель проверки и утверждения требований Особенностью предложенной модели является тестирование требований. Любые усилия, затраченные на выявление ошибок в спецификации к требованиям, сэкономят реальные время и деньги. Зачастую тестирование рассматривается как одна из последних стадий проекта. Проблемы, связанные с требованиями, могут оставаться в продукте до тех пор, пока они не будут выявлены в ходе долгого тестирования системы или их не обнаружит клиент. Если же начать планирование тестирования и разработку вариантов тестирования на ранней стадии проекта, можно обнаружить многие ошибки сразу вскоре после их появления. При этом удается не только предотвратить дополнительный ущерб, наносимый ими, но и снизить затраты на тестирование и обслуживание. Хотя в процессе разработки требований проведение классических программных тестов невозможно, так как никакого программного обеспечения еще нет, однако создание концептуальных (то есть, не зависящих от реализации) вариантов тестирования вполне реализуемо. При этом концептуальные варианты тестирования, созданные на основе требований, позволят выявить ошибки, неясности и пропуски данных в спецификации требований к программному обеспечению и проанализировать модели задолго до того, как разработчики приступят к написанию кода. Участники проекта часто с неохотой тратят время на проверку и тестирование спецификации требований к программному обеспечению, считая при этом, что если выделить время на проверку качества требований, дата выпуска продукта задержится на такой же срок. При таком отношении утверждение требований обычно превращается в формальную процедуру. В действительности же усилия по улучшению качества требований могут сократить график поставки, за счет уменьшения требуемых исправлений и ускорения интеграции и тестирования системы. Чем лучше требования, тем выше качество продукта и тем больше удовлетворенность клиента, что в свою очередь снижает затраты на обслуживание, улучшение и клиентскую поддержку продукта. Инвестируя в качество продукта, можно сохранить больше, чем затрачено. 8.1. Просмотр требований Просмотр задокументированных требований – это эффективный прием выявления неясных или не поддающихся проверке требований, требований, которые были определены недостаточно ясно для разработки, а также других проблем. Существуют два основных варианта просмотра – неофициальные и официальные просмотры. Неофициальные просмотры полезны при знакомстве людей с продуктом и сборе отзывов о нем (формирование обратной связи). Однако они несистематические, неполные и несогласованные. Есть несколько видов неофициальных просмотров требований: • проверка «за столом», когда вы просите одного коллегу исследовать ваш продукт; • коллективная проверка, когда вы приглашаете несколько коллег для совместной проверки продукта; • критический анализ, когда автор описывает создаваемый продукт и просит его прокомментировать. В отличие от нарочито естественных неофициальных просмотров, официальная проверка представляет собой строго регламентированный процесс. По его завершении формируется отчет, в котором указаны просматриваемые материалы, рецензенты и мнение команды рецензентов о приемлемости продукта. Главный результат просмотра – совокупность всех найденных дефектов и поднятых вопросов. Члены команды, которая выполняет официальный просмотр продукта, делят ответственность за качество проверки, хотя, в конце концов, за качество продукта отвечают все-таки его создатели. Просмотр требований – наиболее действенный из доступных приемов проверки качества программного обеспечения. При серьезном подходе к совершенствованию качества программного обеспечения просмотру должны подвергаться все задокументированные требования, т.е. не только окончательная версия требований, а все рабочие промежуточные версии. Выявление значительных дефектов на ранней стадии и систематических проблем в процессе написания требований является отличным способом предотвращения – а не только выявления – ошибок. 8.2. Проведение экспертизы Экспертиза как метод оценки корректности и качества требований признана лучшим приемом в области разработки программного обеспечения. Этот метод годится для проверки любого продукта, в том числе документации требований и дизайна, исходного кода, документации тестирования и планов проекта. Экспертиза – это четко определенный многоэтапный процесс. В нем участвует небольшая команда квалифицированных специалистов – экспертов, которые тщательно проверяют продукт на наличие дефектов и изучают возможности улучшения. Экспертиза обеспечивает уровень качества продукта, предшествующий окончательному. 8.2.1. Участники Участники экспертизы должны отражать четыре точки зрения на продукт: 1. Автор продукта и, возможно, коллеги автора. Это может быть аналитик, составивший документацию требований. 2. Автор продукта более высокого уровня, чем проверяемый элемент. В этой роли может выступить системный инженер или архитектор, который способен подтвердить, что в спецификации требований к программному обеспечению система описана достаточно детально. При отсутствии спецификации более высокого уровня в экспертизе должны принять участие представители клиента для того, чтобы подтвердить, что требования в спецификации требований к программному обеспечению описаны правильно и полно. 3. Люди, которые будут выполнять работу, основанную на проверяемом элементе. Для экспертизы спецификации требований к программному обеспечению вы можете привлечь разработчика, тестировщика, менеджера проекта, а также составителя пользовательской документации. Они будут выявлять наличие проблем различных типов. Требование, которое не поддается проверке, скорее всего, сможет выявить тестировщик, а разработчик сумеет определить требования, которые технически невыполнимы. 4. Люди, отвечающие за работу продуктов, взаимодействующих с проверяемым элементом. Они выявят проблемы с требованиями к внешнему интерфейсу. Они также могут выявить требования, изменение которых в проверяемой спецификации влияет на другие системы (так называемый «волновой эффект»). Численность команды должна быть ограничена 4-6 членами (максимум 7-8). Большие команды могут легко увязнуть в посторонних дискуссиях, попытках решения проблем и дебатов о том, что считать ошибкой. При этом снижается темп проверки и растет стоимость обнаружения каждого дефекта. 8.2.2. Роли экспертов Все участники экспертизы, включая автора, должны искать недостатки и возможности улучшения. Отдельные участники при этом играют различные роли. Автор. Автор создает или поддерживает проверяемый продукт. В роли автора спецификации требований к программному обеспечению, как правило, выступает аналитик, который осуществлял сбор требований клиента и писал спецификацию. В ходе неофициальных проверок, таких, как критический анализ, именно автор часто возглавляет дискуссию. Однако в экспертизе он принимает более пассивное участие. Как правило, не рекомендуется возлагать на него обязанности координатора, читателя или секретаря. Поскольку автор не принимает активное участие в обсуждении, он имеет возможность выслушать других участников инспектирования, ответить – но не вступать в дебаты – на их вопросы и поразмыслить. При таком подходе автору зачастую удается обнаружить ошибки, незамеченные другими участниками. Координатор. Координатор, или руководитель проверки, планирует экспертизу совместно с автором, согласовывает особенности и организует совещания. Координатор распределяет проверяемый материал между участниками за несколько дней до совещания. Он отвечает за своевременное начало совещаний, поощрение вклада каждого участника и управление дискуссией, которая должна быть направлена на выявление дефектов, а не на решение проблем. Кроме того, в его обязанности входит информировать менеджеров или того, кто занимается сбором результатов различных экспертиз, о результатах. Координатор также работает вместе с автором над предложенными изменениями, чтобы все дефекты и проблемы, поднятые в ходе экспертизы, были рассмотрены должным образом. Читатель. Один из проверяющих выступает в роли читателя. На совещании он озвучивает своими словами положения спецификации – по одному требованию за раз. Затем другие участники указывают на потенциальные дефекты и проблемы. Выражая требование своими словами, читатель дает трактовку требования, которая может отличаться от интерпретации других членов команды. Это хороший способ выявления неясностей, возможных недостатков или предположений. При этом важно, чтобы автор не выступал в роли читателя. Секретарь. Секретарь использует стандартные формы для документирования возникающих вопросов и дефектов, выявленных в ходе совещания. Секретарь должен вслух прочитать свои записи, чтобы убедиться в их точности. Другие участники экспертизы должны помочь ему зафиксировать суть каждой проблемы таким образом, чтобы автор смог четко уяснить природу и местоположение каждой проблемы. 8.2.3. Входные и выходные критерии Экспертиза спецификации требований возможна только в том случае, если спецификация удовлетворяет определенным предварительным условиям. Набор входных критериев призван четко обрисовать авторам то, как следует готовиться к экспертизе, а также удержать команду от траты времени на проблемы, которые следует решать до начала экспертизы. Координатор использует входные критерии в качестве контрольного списка в процессе принятия решения о начале экспертизы. Вот основные входные критерии для готовности спецификации требований к экспертизе: • спецификация должна соответствовать установленному шаблону; • в спецификации не должно быть ошибок правописания или ошибок компоновки; • для экспертизы подготовлены все необходимые проверяющим лицам предшествующие документы или документы, на которые имеются ссылки; • спецификация (или ее обсуждаемая часть) должна быть распечатана с нумерацией строк, чтобы облегчить ссылки на обсуждаемые части документа в ходе экспертизы; • все нерешенные к моменту экспертизы вопросы в спецификации должны быть помечены значком «НО» (необходимо определить); • координатор выявляет не более трех существенных дефектов после 10-минутной проверки выбранного фрагмента документа. Аналогично, прежде чем координатор объявит о том, что проверка закончена необходимо убедиться в том, что все возникшие в ходе экспертизы вопросы были сняты или отражены в дефектной ведомости. 8.2.4. Этапы проведения экспертизы Важно отметить, что экспертиза – это не одноразовая акция, а многоэтапный процесс, состоящий из таких этапов как планирование, обзорная встреча, индивидуальный просмотр, совещание, подготовка заключения. 8.2.4.1. Планирование Экспертизу совместно планируют автор и координатор. Они определяют состав участников, материалы, которые проверяющие должны получить до начала первого совещания, и количество совещаний, необходимых для охвата всего материала. Количество обнаруженных дефектов очень зависит от темпов работы: чем медленнее изучается спецификация требований к программному обеспечению, тем больше дефектов удается выявить. Поскольку ни одна команда не может тратить бесконечное количество времени на проверку требований, необходимо выбрать подходящий темп, принимая во внимание риск пропуска важных дефектов. Чаще всего – от двух до четырех страниц в час, хотя оптимальная скорость, при которой достигается максимальный эффект ниже примерно в два раза. При выборе темпа работы необходимо учесть следующие факторы: • дату предыдущей экспертизы; • объем текста на каждой странице; • сложность спецификации; • риск не заметить ошибку; • насколько критично для успеха проекта проверить весь этот материал; • квалификацию автора спецификации требований к программному обеспечению. 8.2.4.2. Обзорная встреча Во время обзорной встречи автор описывает исходные данные материала, предназначенного для проверки, предположения, которые он сделал, и его личные цели. Если все проверяющие хорошо знакомы с проверяемым материалом, этот этап может быть пропущен. 8.2.4.3. Индивидуальный просмотр До совещания каждый из экспертов самостоятельно исследует предоставленные материалы, чтобы определить возможные дефекты и возникающие вопросы. Для этого можно использовать контрольные списки типичных дефектов и другие приемы анализа. До 75% дефектов, обнаруживаемых при экспертизе, выявляются на этапе индивидуального просмотра, поэтому этот этап пропускать нельзя. Весьма полезным приемом является использование бальных оценок для отдельных аспектов, проверяемых требований. Например, можно обратиться к разработчикам, проверяющим спецификацию требований к программному обеспечению, с просьбой оценить ясность (понятность) требований по 10-балльной шкале. Оценка «1» означает, что разработчик не имеет ни малейшего представления о содержании требования, а «10» – что оно абсолютно понятное, полное и недвусмысленное. Аналогично, тестировщиков можно попросить оценить проверяемость требований. 8.2.4.4. Совещание На совещании читатель знакомит членов команды с каждым требованием спецификации – по одному за раз, перефразируя их своими словами. По мере обсуждения дефектов и других проблем, секретарь заносит их в ведомость дефектов. Цель совещания – выявить в документе как можно больше ошибок. Совещание не должно длиться более двух часов, поскольку работу уставших людей нельзя назвать продуктивной. Если же вам нужно больше времени, следует запланировать еще одно совещание. В заключение совещания команда принимает решение: следует ли принять документ без изменений, с незначительными поправками или указать на необходимость значительной переработки. Решение «необходимы значительные изменения» свидетельствует о наличии серьезных проблем в процессе разработки требований. Возможно, стоит изучить уже проделанную работу и попытаться найти выход до того, как приступать к следующему этапу работы над спецификацией. Иногда эксперты сообщают только о поверхностных и незначительных проблемах. Вдобавок эксперты легко отвлекаются на дискуссии о том, действительно ли обсуждаемый вопрос является дефектом, на споры о границах проекта и на обсуждение возможных решений проблем. Это все, конечно, полезно, однако эти действия отвлекают экспертов от непосредственной цели совещания – выявления серьезных дефектов и возможностей улучшения. Распространено мнение, что совещания слишком трудоемки и дороги. Однако на них можно выявить те дефекты, которые не удастся обнаружить экспертам при индивидуальной работе. Более того, как показывает практика, затраты на улучшение требований окупаются снижением затрат на заключительных стадиях проекта и повышением качества программного продукта. 8.2.4.5. Подготовка заключения Практически на каждом этапе работы, связанном с контролем качества, выявляются определенные дефекты. Результатом экспертизы является заключение о проверяемых требованиях и ведомость дефектов. Все требования, которые успешно прошли экспертизу получают статус «Одобрено», а требования, которые не подлежат тестированию на уровне концептуальных вариантов тестирования, получают статус «Проверено». В ведомость дефектов вносятся все дефекты, ошибки и другие проблемы, обнаруженные экспертами в рассматриваемых материалах. При этом автор и эксперты должны согласовать все формулировки, добиваясь однозначного толкования сущности всех обнаруженных недостатков и путей их устранения. В зависимости от сущности недостатков их устранение может осуществляться на этапе документирования (запрос на переработку требований), на этапе анализа (запрос на повторный анализ требований) или на этапе выявления требований (запрос на изменение и устранение недостатков). 8.2.5. Контрольные списки дефектов Для того чтобы помочь экспертам обнаружить типичные ошибки в проверяемых материалах, желательно использовать контрольные списки дефектов. С помощью таких контрольных списков вы можете привлечь внимание экспертов к часто возникающим проблемам с требованиями. Поскольку длинный контрольный список запомнить невозможно, желательно составить несколько обозримых тематических списков и постоянно корректировать их, сообразуясь с тем, какие проблемы в требованиях повторяются чаще всего. При этом также появляется возможность предложить разным экспертам использовать на этапе индивидуального просмотра разные контрольные списки. Так, например, один эксперт может быть ориентирован на проверку корректности и согласованности требований, другой – на проверку тестируемости, а третий – на проверку того, могут ли требования служить основой для дизайна. Такое распределение обязанностей (естественно, при условии, что экспертов снабжают четкими указаниями или сценариями, которые помогают им при поиске ошибок) более эффективно, чем когда эксперты работают по одинаковым контрольным спискам. Далее приведены примеры контрольных списков. Пример Контрольного списка дефектов для вариантов использования 1. Является ли конкретный вариант использования продукта автономной и отдельной задачей? 2. Ясно ли сформулирована цель или измеряемое значение для конкретного варианта использования продукта? 3. Очевидно ли, кто получит преимущества от этого варианта использования? 4. Написан ли вариант использования на базовом уровне, без ненужных деталей, связанных с дизайном и реализацией? 5. Все ли предполагаемые альтернативные направления задокументированы? 6. Все ли известные условия исключения задокументированы? 7. Есть ли какие-либо последовательности действий, которые можно разделить на отдельные варианты использования? 8. Все ли этапы каждого направления записаны в ясной, недвусмысленной и полной форме? 9. Каждый ли исполнитель и стадия варианта использования продукта соответствуют выполнению конкретной задачи? 10. Осуществимо ли и поддается ли проверке каждое альтернативное направление, определенное в варианте использования? 11. Должным ли образом структурируют вариант использования выходные и выходные условия? Пример Контрольного списка дефектов для спецификации требований Организация и завершенность 1. Корректны ли все ли внутренние перекрестные ссылки на другие документы? 2. Написаны ли все ли требования на одном и том же соответствующем уровне детализации? 3. Обеспечивают ли требования адекватную основу для дизайна? 4. Указан ли приоритет реализации каждого требования? 5. Определены ли все внешние интерфейсы оборудования, программного обеспечения и взаимодействия? 6. Определены ли все алгоритмы, соответствующие функциональным требованиям? 7. Включены ли в спецификацию требований к программному обеспечению все известные потребности клиента или системы? 8. Отсутствует ли в требовании какая-либо необходимая информация? Если да, помечена ли она значком «НО»? 9. Задокументировано ли ожидаемое поведение системы для всех предполагаемых ошибочных условий? Корректность 10. Конфликтуют ли какие-либо требования с другими требованиями или повторяют их? 11. Написано ли каждое требования ясным, точным и недвусмысленным языком? 12. Можно ли проверить каждое требование с помощью тестирования, демонстрации, просмотра или анализа? 13. Не выходит ли какое-либо требование за границы проекта? 14. Нет ли в каком-либо требовании тематических или грамматических ошибок? 15. Можно ли реализовать все требования, не выходя за рамки установленных ограничений? 16. Все ли перечисленные сообщения об ошибках уникальны и выразительны? Атрибуты качества 17. Все ли задачи, связанные с производительностью, сформулированы соответствующим образом? 18. Все ли соображения, касающиеся охраны труда и безопасности, сформулированы соответствующим образом? 19. Все ли задачи, связанные с атрибутами качества, ясно задокументированы и просчитаны, с учетом приемлемых компромиссов? Возможность отслеживания 20. Каждое ли требование идентифицировано уникально и корректно? 21. Прослежено ли каждое функциональное требование до более высокого уровня (например, требования к системе или вариант использования)? Особые проблемы 22. Все ли требования можно отнести именно к требованиям, а не к решениям разработки или реализации? 23. Идентифицированы ли все функции, зависящие от времени, и определены ли их критерии? 24. Были ли рассмотрены соответствующим образом все проблемы, связанные с интернационализацией? 8.3. Возможные проблемы при просмотре требований Экспертные оценки можно отнести как к техническим приемам, так и к работе с людьми. Просьба коллег высказать их мнение о том, что не так с вашей работой, – сознательное, а не интуитивное действие. Для введения практики экспертных оценок необходимо время. Ниже описаны типичные проблемы, с которыми специалисты сталкиваются при проверке требований, и предложения по их решению. 8.3.1. Большой объем документации Можно с уверенностью утверждать, что перспектива тщательной проверки спецификации требований к программному обеспечению, состоящей из нескольких сотен страниц, окажется малопривлекательной для любого эксперта. Многим экспертам покажется заманчивым пропустить проверку деталей, особенно тех, которые обычно не входят в круг их профессиональных интересов. Более того, даже в спецификации среднего размера, как правило, все эксперты тщательно проверят первую часть, несколько наиболее стойких изучат середину, но маловероятно, чтобы кто-то дошел до конца. Для решения данной проблемы можно на основе анализа специфики разрабатываемых проектов определить области повышенного риска, которые требуют тщательной экспертизы, а для менее важных фрагментов спецификации требований использовать неофициальные просмотры. Можно также распределить различные части проверяемых материалов между разными экспертами, однако при этом вы рискуете не заметить несогласованности. Однако наилучшим решением, позволяющим избежать перегрузок, является проверка требований по мере их разработки, не дожидаясь разработки всей спецификации требований. 8.3.2. Большая команда экспертов Многие участники проекта и клиенты хотят заниматься требованиями, поэтому список желающих может оказаться весьма длинным. Однако чем больше команда экспертов, тем труднее составить график совещаний, тем больше на них посторонних разговоров и тем труднее прийти к согласию по каждому вопросу. Чтобы избежать проблем неконтролируемого разрастания команд экспертов координатору при формировании команды экспертов следует убедиться, что каждый участник понимает, что его задача заключается в выявлении дефектов, а не в повышении своей квалификации или отстаивании своей позиции. Координатор должен четко понимать, чью точку зрения (клиента, разработчика или тестировщика) представляет каждый участник. Необходимо тактично отклонить участие лиц, готовых отстаивать точку зрения, которая уже представлена в формируемой команде. Если несколько экспертов относятся к одной группе, необходимо помочь им выбрать своего представителя для участия в команде. Возможен также вариант, когда собираются несколько небольших групп для параллельной проверки спецификации требований к программному обеспечению. Исследования показали, что экспертиза документа о требованиях, выполняемая несколькими командами, выявляет больше ошибок, чем одна большая команда. Как правило, результаты параллельных проверок скорее дополняют, чем повторяют друг друга. 8.3.3. Географическое разделение экспертов Все больше компаний разрабатывают продукты, привлекая команды, разъединенные географически. В этом случае проверки проводить труднее. Видеоконференции могут стать эффективным решением этой проблемы, но необходимо учитывать, что в телеконференциях теряются многие не вербальные каналы общения, что снижает их эффективность по сравнению с «живым» общением экспертов. Другим решением является просмотр электронного файла, размещенного в общей сетевой папке. В этом случае эксперты используют функции текстового редактора, чтобы ввести свои комментарии в проверяемый документ. Каждый комментарий помечается инициалами эксперта, таким образом, любой из участников может ознакомиться с мнением других экспертов. Однако при отказе от совещаний следует учитывать, что результативность экспертизы снизится примерно на 25%, однако стоимость экспертизы также уменьшится. 8.4. Тестирование требований Тестирование и разработка требований связаны синергетически: чем лучше требования, тем качественнее тесты; чем качественнее анализ тестирования, тем лучше требования. Требования обеспечивают основу для тестирования системы. Продукт следует тестировать на соответствие тому, что он, как записано в требованиях, должен делать, а не на предмет дизайна или кода. Тестирование системы, выполненное на основе кода, может стать ловушкой. Продукт может вести себя именно так, как описано в вариантах тестирования, созданных на основе кода, но это отнюдь не означает, что он соответствующим образом реализует пользовательские или функциональные требования. Во избежание подобной опасности следует подключить тестировщиков к экспертизе требований, чтобы убедиться, что требования поддаются проверке и могут служить основой для тестирования системы. Тестировщики проекта должны определить, как они будут проверять каждое требование. Возможных методов несколько: • тестирование (выполнение программного обеспечения с целью поиска дефектов); • экспертиза (проверка кода на предмет его соответствия требованиям); • демонстрация (демонстрация того, что продукт работает, как ожидалось); • анализ (обоснование того, как система должна работать при определенных условиях). Само по себе обдумывание того, как проверить каждое требование, является ценным приемом работы над качеством. Необходимо, чтобы каждое функциональное требование можно было проследить, по крайней мере, до одного варианта тестирования в системном тестовом наборе, для того чтобы ни одна ожидаемая реакция системы не осталась непроверенной. При таком подходе прогресс тестирования можно измерить, определяя процент требований, которые прошли проверку. 8.4.1. Тестирование требований разработчиком Трудно представить себе, как система будет функционировать при определенных условиях только на основании прочитанной спецификации требований к программному обеспечению. Варианты тестирования, созданные на основании функциональных или пользовательских требований, помогают участникам проекта получить представление об ожидаемом поведении системы. Как показывает практика, даже простая разработка вариантов тестирования без реального выполнения тестов может выявить множество проблем с требованиями. Если вы начнете разрабатывать варианты тестирования сразу после стабилизации некой части требований, вам удастся обнаружить проблемы, которые еще можно устранить с минимальными затратами. Следует остерегаться тестировщиков, которые утверждают, что не могут приступить к работе, пока требования еще формируются, как и тех, которые утверждают, что для тестирования программного обеспечения им не нужны требования. Тестирование и требования связаны между собой синергетическими отношениями, поскольку они представляют дополняющие взгляды на систему. При написании вариантов тестирования по существу кристаллизуется ваше понимание того, как система должна себя вести при определенных условиях. Неясные и двусмысленные требования при таком подходе будут выявлены практически сразу, поскольку вы не сможете описать ожидаемую реакцию системы. Важно также учитывать, что когда аналитики, разработчики и клиенты вместе создают варианты тестирования, они вырабатывают общее понимание того, как продукт будет работать. Созданием концептуальных вариантов тестирования можно заняться, основываясь на вариантах использования продукта или других представлениях пользовательских требований, уже на ранней стадии процесса разработки требований. Варианты тестирования должны охватывать нормальную линию поведения варианта использования продукта, альтернативные направления, а также исключения, идентифицированные в ходе сбора информации и анализа. Важно помнить, что эти концептуальные (или абстрактные) варианты тестирования не зависят от реализации. Это именно тесты требований. В идеале разработка вариантов тестирования должна идти вслед за разработкой вариантов использования на основе одних и тех же материалов – пользовательских требований. Неясности в пользовательских требованиях и различные интерпретации выливаются в несогласованность функциональных требований, моделей и вариантов тестирования. В дальнейшем, по мере того, как разработчики преобразовывают требования в пользовательский интерфейс и технический дизайн, тестировщики могут переработать концептуальные тесты в детально проработанные процедуры тестирования для официального тестирования системы. Концептуальное тестирование требований к программному обеспечению – мощный прием управления затратами и графиком проекта, так как он позволяет выявлять неясности и ошибки в требованиях на начальных стадиях проекта. Разработка вариантов использования продукта и разработка вариантов тестирования отлично дополняют друг друга. Если варианты использования написаны полно, аккуратно и ясно, то процесс составления вариантов тестирования становится крайне простым. Если же варианты использования имеют какие-либо дефекты, то попытка составления вариантов тестирования зачастую помогает их выявить. 8.4.2. Тестирование требований клиентом Разработчики программного обеспечения могут быть уверены, что они создают идеальный продукт, однако последнее слово все же остается за клиентом. Клиенты тестируют продукт, чтобы определить, удовлетворяет ли система критерию приемлемости. Если да, то клиент платит за продукт, разработанный согласно контракту. Критерий приемлемости – и, следовательно, проверка приемлемости – является показателем того, удовлетворяет ли продукт задокументированным требованиям и годится ли он для использования в предполагаемой операционной среде. Поэтому делегирование разработки тестов на приемлемость пользователям – эффективная стратегия разработки требований. Чем раньше в процессе разработки пользователи продумают тесты на проверку приемлемости, тем скорее удастся отловить дефекты в требованиях и разрабатываемом программном обеспечении. Проверку приемлемости следует сосредоточить на предполагаемых вариантах использования. Ключевым пользователям при принятии решения о способе оценки приемлемости системы стоит принять во внимание наиболее общие и важные варианты использования. Тесты приемлемости должны фокусироваться на нормальной линии поведения вариантов использования продукта, а не на более редких альтернативных направлениях или на том, обрабатывает ли система исключения соответствующим образом. Тестирование приемлемости также должно затрагивать нефункциональные требования и должно подтверждать, что цели, связанные с производительностью, достигаются на всех оговоренных платформах, а система в целом соответствует оговоренным атрибутам качества. Естественно пользовательское тестирование приемлемости не заменит итогового полного тестирования системы на основании требований, при котором тестируются все нормальные, альтернативные пути и пути исключений, а также большое количество комбинаций данных. Однако оно существенно облегчит приемку системы. Разработка критерия приемлемости клиентами позволяет также упростить разработку требований, разрешая проблему неясности, размытости пользовательских требований. На этапе выявления требований появляется возможность оперировать не только вопросами типа «Что вы хотите делать с помощью системы?», но и вопросами типа «Как вы убедитесь, что система удовлетворяет ваше требование?». Такая постановка вопроса автоматически выявляет нечеткие требования пользователей, так как клиент будет не в состоянии описать, как он оценит, что конкретное требование удовлетворено системой. 8.5. Обобщение результатов проверки требований Обобщение результатов проверки требований призвано зафиксировать конкретные результаты текущей итерации проверки требований и определить дальнейший ход разработки требований. Если по результатам проверки необходимо устранение обнаруженных недостатков или дефектов требований, то необходимо сформировать соответствующие запросы на их устранение. Также необходимо принять решение о необходимости продолжения процесса выявления требований. Выявить требования полностью с практической точки зрения невозможно (время и ресурсы не безграничны), поэтому каких-либо однозначных признаков, показывающих, что выявление требований завершено, нет. Тем не менее, для определения момента прекращения процесса выявления требований можно использовать следующие признаки: 1. Пользователи уже не могут придумать какие-либо еще варианты использования. Обычно они описывают их в порядке убывания значимости последних. 2. Пользователи предлагают новые варианты использования, однако вы уже вывели соответствующие функциональные требования из других вариантов использования. Эти «новые» предложения могут оказаться случаями других вариантов использования, которые вы уже рассмотрели. 3. Пользователи все чаще повторно описывают уже обсуждавшиеся проблемы. 4. Предлагаемые новые функции, пользовательские или функциональные требования выходят за границы проекта. 5. Все вновь предлагаемые требования имеют низкий приоритет. 6. Пользователи предлагают возможности, которые имеет смысл реализовать «когда-то позже», а не включить «в конкретный продукт, который мы сейчас обсуждаем». Наличие данных признаков свидетельствует о том, что продолжать выявление требований вряд ли целесообразно. Однако это не свидетельствует о завершении разработки требований. Разработку требований можно считать завершенной только после утверждения базовой версии спецификации требований. 8.6. Утверждение требований Утверждение требований позволяет удостовериться в том, что: • в спецификации требований к программному обеспечению должным образом описаны предполагаемые возможности и характеристики системы, которые удовлетворят потребности различных заинтересованных в проекте лиц; • требования отвечают критериям качества; • требования обеспечивают качественную основу для дизайна и сборки программного обеспечения. В широком смысле утверждение – это не один отдельный этап процесса, выполняемый после выявления и документирования требований. Некоторые проверочные мероприятия, например, просмотр все более разрастающейся спецификации требований к программному обеспечению, выполняются после каждой процедуры сбора информации, ее анализа и документирования. Другие мероприятия, такие, как экспертиза спецификации требований к программному обеспечению или тестирование требований, обеспечивают достижение того уровня качества, которое предшествует финальной версии спецификации. В узком смысле утверждение – это официальная процедура принятия базовой версии спецификации требований к программному обеспечению. Готовность спецификации требований к процедуре утверждения определяется следующими критериями: • Принято решение о прекращении процесса выявления требований. • Все требования, включенные в спецификацию, имеют статус «Проверено» или «Отклонено». Литература 1. Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению. 3-е изд., дополненное / Пер.с англ. - М.: Издательско-торговый дом «Русская Редакция», 2014. - 736 с.: ил. - ISBN 978-5-7502-0433-5 2. Клевцов С.И. Анализ и формирование требований к ПО информационных систем сбора и обработки данных: Учебное пособие. - Таганрог: Изд-во ТТИ ЮФУ, 2007. – 100 с. 3. Брауде Э. Технологии разработки программного обеспечения. СПб: Питер, 2004. - 655 с. 4. Алистер Коберн. Современные методы описания функциональных требований к системам М.: издательство «Лори», 2002. - 263 с. 5. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД «Вильямс», 2002.