4. Анализ и управление требованиями

По средним подсчетам, ошибки, допущенные на стадии сбора требований, составляют от 40 до 60 % всех дефектов проекта. Что является очень большой цифрой и соответственно к данному вопросу необходимо подходить с особой тщательностью.

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

Отдельно выделяют четыре уровня требований.

1. Бизнес-требования.

• Содержат высокоуровневые цели организации или заказчиков системы.

• Высказываются заказчиками, покупателями.

• Составляется документ, в котором описаны цели, которые фирма намеревается достичь с помощью системы.

• Определяются границы проекта.

2. Требования пользователей.

• Описывают цели и задачи, которые пользователям позволит решить система.

• Описываются способы представления/использования;.

• Документ, указывающий, что пользователи смогут сделать с помощью системы.

3. Функциональные требования (нефункциональные требования).

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

4. Системные требования.

• Программное обеспечение и оборудование.

• Высокоуровневые требования к продукту.

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

1. Корректные требования.

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

2. Недвусмысленные требования.

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

3. Полнота набора требований.

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

4. Непротиворечивость набора требований.

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

5. Упорядочение требований по их важности и стабильности.

В высококачественном наборе требований отдельные требования упорядочены по их важности для клиента и стабильности приложения.

1. Модифицируемый набор требований.

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

2. Трассируемые требования.

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

2. Проверяемые требования.

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

2. Понимаемые требования.

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

В идеале функциональные требования и варианты тестирования пишутся на основе одних и тех же материалов [7].

Варианты тестирования должны охватывать:

• нормальную линию поведения продукта;

• все альтернативные направления;

• исключения.

Процесс тестирования, основанный на требованиях, состоит из двух фаз:

• просмотр на наличие неоднозначностей;

• выведение причинно-следственных связей.

Выведение причинно-следственных связей – процесс необходимый для создания тест-кейсов, позволяющих достигнуть 100% покрытие функциональных требований, что позволяет реализовать следующие преимущества:

• уточнение правил предшествования требований;

• уточнение неясной информации, что делает её явной и понятной всем членам команды;

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

Методология тестирования, основанного на требованиях, представляет собой 12-ступенчатый процесс.

1. Валидация требований по отношению к целям. Сравнение целей, которые описывают причину инициации проекта с требованиями, определяющими конечный продукт. Цели задают критерий успешности проекта. Если «что» не соответствует «почему», цели не могут быть достигнуты и проект не будет успешен. Если какое-либо из требований не ведет к достижению целей, оно не находится в рамках задания проекта.

2. Соотношение use-case с требованиями. В некоторых случаях, требования выполняются в виде набора use-case.

Use-case – это задачно-ориентированное представление пользователя о программе. Собранные вместе частные требования должны удовлетворять любым сценариям use-case; в противном случае требования представляются неполными.

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

4. Проведение экспертных обзоров. Целью таких обзоров является проверка требований на полноту и корректность.

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

6. Проверка логической целостности и разработка тест-кейсов. Возможно применение специальных инструментов для поиска неувязок в графе причинно-следственных связей. Результатом работы такого приложения будет набор тест-кейсов, 100% эквивалентных функциональности в требованиях.

7. Анализ тест-кейсов авторами требований. В случае возникновения разногласий между тест-кейсом и пунктом требований, возможно внесение корректировок и повторная разработка тест-кейса.

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

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

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

11. Использование тест-кейсов в предпросмотре кода. Каждый модуль должен удовлетворять некоторому набору требований. Тест-кейсы могут решить проблему проверки, насколько данный конкретный модуль удовлетворяет определенным требованиям.

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