Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
время и бюджет проекта уже потрачены разработчиками на решение
«пустых» задач, а тестировщиками – на подготовку «пустых» тестов.
Для исключения двусмысленности в понима-
Делаем!
нии требований к проекту команде разработчиков
можно использовать один из следующих способов:
проводить совместные обсуждения требований с пользователями.
Самостоятельный раздельный анализ текстов пользователями может не
выявить двусмысленности
в понимании, поскольку без дополнительных
комментариев читающего уточнить смысл прочитанного невозможно.
По умолчанию пользователь может принять формулировку как свою по
смыслу;
подготовить тесты для проверки требований, разработать и про-
тестировать прототип. Анализ полученных результатов позволит выявить двусмысленность требований, если она есть.
7. Используемые термины при формулировании требований могут
быть
источником их двусмысленности?
Зачастую в формулировках используются неоднозначные слова,
предназначенные для подчеркивания двусмысленности в текстах, что
снижает качество требований.
Нужно во всех документах, подготовленных
Делаем!
при разработке и использовании продукта проекта,
применять термины в соответствии с их определе-
нием в словаре и свести к минимуму использование синонимов термина.
Выбрав термин, необходимо
указать его синонимы в словаре, чтобы
заинтересованные лица могли точно связать этот термин с его синонимами. При использовании местоимений нужно так строить предложение, чтобы однозначно было понятно, какой термин заменяет местоимение.
Неоднозначность текста возникает при употреблении наречий, таких как «эффективно», «удобно», «обычно», «универсально», «приемлемо», «гибко» и
др. Требования, которые могут быть поняты неоднозначно из-за используемых терминов и наречий, будет трудно проверять
на более поздних этапах разработки.
В приложении 1 приведены часто встречающиеся в формулировках
требований неоднозначные слова и рекомендации по уменьшению двусмысленности формулировок требований.
11
8. Как исключить неопределенность бизнес-правил
и условий, определяющих действия, описывая пограничные
значения в требованиях?
Рассмотрим на примере, как формулировка бизнес-правила создает
неопределенность понимания описанных ситуаций и как можно снять
неопределенность.
Покупка канцелярских принад-
Пример формулировки
требования с неопределенностью
лежностей на сумму до 100 рублей
не требует одобрения. Покупка
канцелярских принадлежностей
на сумму от 100
до 500 рублей
требует одобрения непосредственного начальника. Покупка канцелярских принадлежностей на сумму от 500 рублей требует одобрения директора организации.
Использованные формулировки не дают
Делаем!
возможности определить, какое бизнес-правило корректно применить, если сумма покупки равна 100 или 500 рублям.
Предлоги «от и до», «свыше» и наречие «включительно» снимают
неопределенность
при описании пограничных значений в требованиях.
Покупка канцелярских принадлежно-
стей на сумму 100 рублей и менее не тре-
Новая формулировка требования
в примере
бует одобрения; более 100 и до 500 рублей включительно требует одобрения
непосредственного начальника. Покупка
на сумму свыше 500 рублей требует
одобрения директора.
9. Как поступать с требованиями, сформулированными
в негативной форме
в виде описания того, чего программный
продукт не должен делать?
Заинтересованные лица нередко формулируют свои требования
в виде описания нежелательного поведения программного продукта.
Причем, как показывает опыт, им легче предоставить свои требования
в такой форме, чем в позитивной. Бывает, что при формулировании они
также используют двойные и тройные отрицания, что усложняет
анализ
таких требований.
12
Что делать?
вать сложные для понимания и реализации
негативные требования в позитивном стиле.
Требования должны описывать ограничения на поведение программного продукта.
Рассмотрим пример такого требования.
Пользователь не должен иметь доступ к материалам сайта, если
он не прошел успешно процедуру регистрации или аутентификации.
В любом случае нужно переформулиро-
Требование легче воспринимается, если
его переформулировать без
использования двойного отрицания в позитивном стиле.
Пользователь получает доступ к материалам сайта после успеш-
ного выполнения процедуры регистрации или аутентификации.
10. Как обеспечить полноту набора требований
в техническом задании?
В настоящее время нет способа досто-
Важно!
верно выяснить, что разработчики определили все требования к программному продукту в
данном проекте.
Выявление задач, которые пользователи смогут решать с помощью
разрабатываемого программного продукта, а не его функций, позволяет
не упустить функциональность. Использование моделей анализа способствует обнаружению пропущенных требований.
Можно назвать несколько причин возник-
Причины
неполноты
требований
новения неполноты требований: частичное
формулирование симметричных требований,
представление требований со сложной логикой в текстовой форме, отказ
от формулиро-
вания отсутствующих исключений.
Пример 1.
Симметричное
требование
Пользователь должен иметь возможность
сохранить частично заполненную форму-анкету в любой момент ручного ввода.
Замечания по формулировке требования:
требование, определяющее для пользователя возможность от-
крыть для завершения работы ранее сохраненную частично заполненную форму-анкету, отсутствует в спецификации;
нет информации о проверке корректности введенных в форму-ан-
кету данных перед сохранением. Разработчикам нужно уточнить: возможно, что это пропущенное требование.
13
Что делать?
Во многих нередко встречающихся ситуациях уже наработаны варианты выбора.
Например, при вводе данных (пример 1) часто
реализуется проверка корректности введенных данных; предоставляется базовый вариант заполнения или пустая форма по требованию
пользователя; предлагаются рекомендации по заполнению; сохраняется
частично заполненная форма; отмечаются обязательные для ввода данные. Рекомендуется использовать накопленный опыт
возможных дей-
ствий в таких ситуациях.
При выборе последующих действий в сложных логических выражениях нередко остаются неопределенными действия для некоторых значений или условий.
«Если не выбран план “Премиальный” и не
Пример 2.
Сложная
логика
предоставлено подтверждение страховки,
то клиент должен автоматически получать
план “Базовый”».
Это требование ссылается на два двоич
ных выбора, которые дают четыре возможных сочетания, но спецификация описывает только одно сочетание. Читатель вынужден думать,
что в таких ситуациях система не должна предпринимать никаких действий. Это может быть верно, но лучше это сформулировать явно, а не
подразумевать» [1, с. 254].
Для представления сложной логики мож-
Делаем!
но использовать таблицы и
деревья принятия
решений (см. приложение 8), что дает воз-
можность учесть все возможные варианты выбора.
Требование, определяющее действия при выполнении заданного
условия, обязательно должно иметь «пару» – требование, определяющее действия в случае невыполнения условия.
Дополнительные примеры требований «до» и «после» приведены
в приложении 2.
-
11. Нужно ли включать требования, которые определяют
несущественные для
пользователя возможности?
Как правило, такие требования предлагают разработчики, считая,
что новые возможности будут интересны и полезны пользователям. Любые дополнительные возможности, предлагаемые разработчиками,
14
должны быть обсуждены и согласованы с заказчиком, потому что для
реализации каждого требования тратятся время и деньги. Согласится ли
на это заказчик?
В свою очередь, пользователи тоже могут предложить интересные
или привычные им возможности, которые, по сути, не определяют выполнение ими профессиональных задач. Все предложения подобного
рода должны быть
согласованы с заказчиком с учетом бюджета проекта
и сроков его исполнения.
Рассмотренные ситуации появления но-
Делаем!
вых требований, определяющих не обязатель-
ный дополнительный функционал, в случае
их реализации расширяют первоначальные границы проекта. Для
уменьшения числа дополнительных требований необходимо отслеживать их до источника появления. Это дает понимание, почему требование включено в
техническое задание, и дает возможность принять обос-
нованное решение об исключении требования из технического задания.
12. К чему может привести неучет потребностей
пропущенных групп пользователей?
Каждый программный продукт имеет группы очевидных пользователей. Пользователи одной группы работают чаще всего с некоторой частью функционала продукта и имеют определенный уровень подготовки
при работе с программным обеспечением. Потребности этих
пользователей изучаются и определяются прежде всего.
Важные для успеха проекта требования могут предложить сотрудники поддержки, у которых есть специфические функциональные и нефункциональные требования, и сотрудники, обеспечивающие передачу
данных из унаследованных систем, а также сотрудники организаций,
которые работают со стандартами различного назначения.
Важно не
пропустить требования всех заинтересованных лиц проекта.
Важно!
13. Какой уровень детализации требований можно
считать достаточным в проекте?
Ответ на этот вопрос во многом зависит от
опыта команды разработчиков. Уровень детализации описания требований можно считать
15
достаточным, если члены команды могут продолжать работу над проектом, используя последний вариант требований. В проектах гибкой разработки на первой итерации разрабатывают требования высокого
уровня общности. Такой подход дает целостное представление о типах
разрабатываемых требований, что во многом определяет успех проекта
(см. вопрос 25).
Декомпозиция высокоуровневых требований
Делаем!
на требования более
низкого уровня общности
дает возможность определить конкретные действия для их реализации в проекте. Таким образом, требования должны
быть настолько подробными и объяснимыми, чтобы было ясно, что делать для их реализации. Если пользователи в незначительной мере по
разным причинам привлекаются к проверке качества требований и результатов тестирования продукта,
то следует включать больше деталей
в описание требований на начальном этапе разработки, чтобы компенсировать ограничение участия пользователей в проекте.
Высокий уровень детализации требований нужен в следующих случаях:
когда продукт разрабатывается для стороннего заказчика;
часть проектной работы будут выполнять специалисты других
компаний;
команда работает удаленно, совещания проводятся в
формате ве-
бинара, связь и обсуждения вопросов происходят в чате;
целью тестирования является определение степени реализации
требований в разработанном продукте;
требуется высокий уровень точности при оценке и управлении
рисками разрабатываемого программного продукта;
нужно отслеживать связи требований.
Можно сократить объем деталей в требованиях в следующих случаях:
если
продукт будет использоваться внутри организации;
пользователи и другие заинтересованные лица имеют возмож-
ность активно работать вместе с членами команды над проектом в течение всего жизненного цикла разработки;
члены команды разработчиков имеют необходимые знания в пред-
метной области и ценный опыт успешного выполнения проектов;
новое приложение создается как
замена существующему продукту
или есть продукты с подобным функционалом;
будет использоваться пакетное решение.
16
14. Нужен ли единый уровень детализации
в проектной документации?
Поскольку уровень детализации описа-
Делаем!
ния требований определяет возможность
продолжения работы по проекту на последующих этапах жизненного цикла, то разумно использовать следующее
правило: использование одного уровня детализации не обязательно при
описании всех требований в спецификации проекта. Поэтому необходимо выполнять следующее:
1)
с более высоким уровнем детализации описывать требования, ко-
торые относятся к областям повышенного риска;
2) с одним достаточным уровнем детализации описывать связанные
требования при описании функциональных требований.
15. Как определить достаточный уровень описания
требований в проектной документации?
В определении достаточности уровня
Делаем!
детализации требований может помочь
подготовка тестов для проверки правильно-
сти реализации
требований в проекте.
Описать требования таким образом,
Пример
чтобы можно было протестировать продукт с целью проверки реализации каж-
дого требования по отдельности.
Если для тестирования правильности реализации одного требова-
ния будет достаточно нескольких взаимосвязанных тестов, то с большой долей вероятности достаточный уровень детализации обеспечен.
Если для
тестирования правильности реализации одного требования подготовлен целый набор многочисленных и разнообразных тестов,
то, скорее всего, несколько требований объединены в одно требование.
Вместо такого требования нужно сформулировать несколько простых
требований. Например:
‒ комбинация клавиш Ctrl+S должна интерпретироваться как
«Сохранить файл»;
‒ комбинация клавиш Ctrl+P должна интерпретироваться как
«Печать файла»;
‒ продукт должен реагировать на команды редактирования, вве-
денные голосом.
17
Для проверки правильности реализации двух первых простых тре-
бований потребуется немного тестов.
Третье требование по форме можно отнести к простым требованиям, но на самом деле это крупное функциональное требование, которое предполагает использование отдельного продукта по распознаванию речи. Подобное требование имеет высокий уровень общности.
На начальном этапе формулирования
требований полезно использовать такой уровень общности для определения областей, в которых
нужно формулировать требования. Проверка правильности реализации третьего требования потребует много тестов. Данное требование
необходимо детализировать.
16. Какие способы представления требований
в спецификации проекта уместны?
Зачастую предпочтение текстовой формы при формулировании тре-
бований приводит к затруднениям в понимании требований
заинтересованными лицами. Удачно выбранная и использованная форма представления требований значительно снижает риски неоднозначного понимания требований и их пропуска.
Кроме текстовой формы рекомендуется ис-
Делаем!
пользовать таблицы, графики, списки, матема-
тические формулы, фотографии, видеоклипы
и наглядные модели анализа. Различные формы представления одного
и того же материала ускоряют, упрощают и углубляют
его понимание.
17. Какие характеристики определяют качество
списка требований в спецификации проекта?
Качественные отдельные требования являются обязательным, но недостаточным условием разработки качественного списка требований
к продукту. Список требований в спецификации проекта считается качественным, если для него характерны полнота, согласованность, модифицируемость и отслеживаемость.
Полнота как качество списка требований
Полнота
предполагает
, что все требования и данные
проекта определены и задокументированы.
На практике реализовать такой подход в полной мере не удается изза ограниченности ресурсов на разработку проекта. Все требования не
18
документируются, так как еще есть предполагаемые и недостающие
требования. Правильная реализация предполагаемых требований имеет
больше рисков, чем реализация явно сформулированных требований.
Недостающих требований пока нет, поэтому их сложно определить на
этой стадии разработки проекта.
Согласованность требования можно
Согласованность
обеспечить в ходе проработки его связей
с требованиями различных типов (одно-
типных требований,
бизнес-требований, пользовательских и системных
требований).
Несогласованность требований проявится на более поздних этапах
разработки продукта, т. е. избежать согласования требований в проекте
практически невозможно. Устранить несогласованность требований
проще, если известны заинтересованные лица или члены команды разработчиков проекта, которые являются авторами требования.
Существенным препятствием для обнаружения несогласованности
требований является их рассредоточенность
по разным документам,
например, они могут быть в описании границ проекта и в спецификации
требований.
Любое требование можно изменить на
Модифицируемость
любом этапе проектной деятельности. Важно
вести историю их изменения, особенно после
первого утверждения требований.
Проработка связей между требованиями на этапе их разработки дает
возможность быстро, корректно и одновременно внести изменения
в группу требований, связанных с изменяемым требованием. Возможность модификации напрямую зависит от принятой системы именования требований уникальными именами и реализации способа формулирования требований, который обеспечивает уникальность каждого требования по содержанию.
Следует учитывать, что уместные для лучшего понимания повторы
требований в разных частях документации приводят к усложнению
управления
требованиями. В частности, необходимо обеспечивать изменение повторяющегося требования в нескольких местах, а значит,
нужно фиксировать подобную информацию.
Задача внесения изменений в требования с учетом взаимозависимостей между ними решается современными системами управления требованиями за счет использования перекрестных ссылок. В этом случае
19
изменения нужно вносить только в единственном списке требований
в спецификации.
В проекте продуктивно определять
Отслеживаемость
связи требования с первоисточником
или с объектами, которые порождает
требование (другие требования, программный код, элементы дизайна),
а также тесты, позволяющие проверить правильность реализации требования. На практике не обязательно определять все возможные типы
связей требований.
Отслеживаемые
требования должны иметь уникальные идентификаторы. Для отслеживания лучше использовать программные продукты
для управления требованиями. Следует отметить, что для успешного
обеспечения отслеживаемости важно не объединять несколько требований в одно.
В условиях ограниченных ресурсов проекта невозможно создать
идеальную спецификацию, в которой отдельные требования однозначно понимаются всеми заинтересованными лицами проекта и
список
требований в спецификации обладает всеми атрибутами качества. Тем
не менее знание перечисленных свойств требований способствует разработке более качественных требований, что в конечном итоге приведет
к разработке более качественного продукта.
18. Когда можно считать сбор требований законченным?
Сбор требований можно закончить, если их список, по мнению спе-
циалистов, достаточен для
продолжения работы над проектом на следующем этапе жизненного цикла продукта. Можно также говорить об
окончании работ по формированию списка требований проекта, если
достигнута запланированная оценка качества отдельных требований
и всего списка требований в целом.
Следует признать, что однозначных признаков завершения работы
над требованиями нет. В технологии гибкой разработки над
требованиями работают при разработке каждой запланированной версии продукта, изменяя некоторые требования и внося новые.
Ориентир
для завершения
работы
Тем не менее при решении вопроса
о завершении работы над требованиями
можно ориентироваться на состояние источников информации о требованиях:
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]