Аттестация требований. Экспертиза спецификации. Процесс экспертизы спецификации. Тестирование требований

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

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

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

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

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

Процесс экспертизы:

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

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

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

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

На этапе обработки результатов экспертизы председатель совместно с автором должны убедиться, что все проблемы разрешены, а ошибки исправлены.

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

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

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

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

- понимание пользователями возможностей системы, решаемых ею задач, может измениться;

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

- понимание разработчиками поставленных перед ними задач меняется.

Это приводит к негативному влиянию на качество продукта, увеличиваются затраты.

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

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

К действиям по управлению требованиями относятся:

1. Определение основной (базовой) версии спецификации требований для конкретной версии продукта;

2. Анализ предлагаемых изменений требований, оценка воздействия и стоимости каждого изменения до его принятия;

3. Включение одобренных изменений при помощи определенной процедуры;

4. Согласование плана проекта с требованиями;

5. Отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

6. Отслеживание статуса требований и действий по изменению на протяжении всего проекта.

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

Процесс управления требованиями. В организации (или проекте) должны быть определены действия по управлению требованиями. Эти действия должны быть задокументированы и выполняться всеми участниками проекта.

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

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

Статус требования. В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Статус требований позволяет оценить степень готовности проекта.