5) Раскадровка

Преимущества — простота и неформальность.

Типы раскадровок:

• пассивная – состоит из схем, картинок, скриншотов, образцов выходной информации. Аналитик играет роль системы, проводя пользователя по раскадровке (когда вы делаете это, происходит вот это…)

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

• активная – автоматизированная демонстрация типового или операционного поведения системы с использованием анимации, показа слайдов или фильма (пользователь может самостоятельно смотреть презентацию и управлять показом < > << >> || )

Примеры: демонстрация слайдов, анимация, имитация

• интерактивная – для выполнения требуют участия пользователя

Примеры: макет программы («живая» демонстрация), интерактивная презентация.

6) Прототипирование

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

Прототип может быть написан в среде разработке и постепенно эволюционировать или может быть отброшен.

- может использоваться для получения подтверждения заказчика о правильном понимании требований,

- помогает найти дополнительные требования,

- помогает донести требования до исполнителя предельно точно.

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

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

7) Обыгрывание ролей

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

Тестирование в среде разработчика — самый яркий пример.

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

8) Построение модели прецедентов

Последовательность:

1. Выявить акторы.

2. Выявить прецеденты использования.

3. Повторять шаги 1 и 2 до тех пор, пока акторы и прецеденты не станут полностью соответствовать друг другу (для всех ли прецедентов хватает акторов и наоборот).

4. Написать краткое описание для каждого актора (1 абзац) и прецедента (1-2 абзаца).

5. Выявить ключевые «предметы», с которыми работает система и включить их в глоссарий или модель предметной области.

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

7. Выявить наиболее существенные или критичные (архитектурно-значимые) прецеденты (обычно 20-30%)

8. Описать эти прецеденты более подробно.

9. Проводить корректировку глоссария и модели предметной области в ходе жизненного цикла.

10. Структурировать модель прецедентов.

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

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

10