Скачиваний:
140
Добавлен:
01.05.2014
Размер:
1.16 Mб
Скачать
    1. Вопросы для самоконтроля

  1. Какая информация вносится в спецификацию требований?

  2. Кто основные читатели спецификации?

  3. Какие рекомендации по документированию требований должны быть выполнены?

  4. Зачем разрабатываются шаблоны спецификации?

  5. От чего зависит тип применяемого шаблона?

  6. На основе каких стандартов разрабатываются шаблоны?

  7. Какие классификации могут быть использованы для организации требований?

  8. В чем особенности организации требований по классам?

  1. Анализ спецификации требований

    1. Оценка качества спецификации требований

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

      1. Характеристики качества спецификации

Рассмотрим характеристики качества, предъявляемые к документу спецификация требований:

  • полнота, согласованность,

  • способность к модификации

  • трассируемость.

Полнота и согласованность

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

Способность к модификации

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

Трассируемость

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

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

      1. Аттестация требований

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности:

  • экспертиза спецификации,

  • прототипирование,

  • автоматизированный анализ.

    1. Экспертиза спецификации

Экспертиза спецификации [4, 7] требований позволяет эффективно выявить неполные и некорректные требования, требования неясные или неподдающиеся проверке, несогласованные и не тестируемые требования.

Неофициальные экспертизы проводится во время разработки спецификации, знакомства с продуктом и не носят регулярный характер. Такие просмотры могут проводиться в виде «проверки за столом», когда автор просит коллегу исследовать спецификацию, или коллективной проверки – параллельного исследования спецификации несколькими людьми.

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

Рис. 6.1

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

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

Рис. 6.2

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

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

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

Для организации помощи экспертам в проведении экспертизы спецификации требований разрабатываются контрольные списки дефектов [4]. На рис. 6.2. приведен список дефектов для варианта использования. Список содержит вопросы, на которые должен ответить эксперт при проведении анализа. Списки могут изменяться, сообразуясь с требованиями проекта. Если список велик, то его можно разбить на подсписки, которые эксперты будут использовать при подготовке.

Проблемы при просмотре требований

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

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