Тема: Разработка требований к по
Извлечение (elicitation), анализ (analysis), документирование (specification) и утверждение (validation. В эти подэтапы входят все действия, включающие сбор, оценку и документирование требований для ПО или ПО-содержащих продуктов.
Управление требованиями определяется как выработка и поддержание взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО.
На рис. 1 -3 показан способ разделения областей разработки требований и управления ими.
Вопрос 1. Техники извлечения требований.
Интервьюирование – традиционный подход к извлечению требований. Преимущества данного подхода:
- специалист способен распознать смысл вопроса, который достаточно точно сфокусирован, но, возможно, не учитывает всех потребностей предметной области;
- ответ эксперта включает его опыт и целостное представление о предметной области;
- техническое обеспечение интервью очень простое.
Недостатки:
- представление любого эксперта по определению ограничено его опытом, компетенцией, субъективизмом;
- проведение интервью требует определенных навыков для его «гладкого прохождения»;
- результаты работы в виде интервью не являются готовым продуктом.
- аналитик все содержимое своей кратковременной памяти, пометки в виде тезисов, наброски моделей обязан перевести в готовую форму сразу после интервью (без каких либо перерывов), что бывает очень тяжело сделать из-за усталости.
Подготовка к интервью с конкретным лицом включает в себя: определение границ, в которых пойдет интервью; определение целей интервью.
Заранее должны быть заготовлены опросные листы, возможно единые для всего объекта автоматизации, а возможно дифференцированные в зависимости от целей. Если целью интервью является уточнений информации предыдущих интервью или исследований, то их необходимо иметь при себе для дальнейших ремарок.
Результатом интервью является пакет бланков с соответствующими пометками. Частота интервью устанавливается исходя из потребностей, но регулярно.
Сценарий – контекст для сбора пользовательских требований, определяющий ответы на вопросы: «Что если?» или «Как это делается?» в отношении бизнес-процесса, который реализует пользователь.
Разработка прототипа. Хороший инструмент для уточнения требований или их детализации, но дорогой. Существуют различные подходы к прототипированию: от бумажных носителей до пилотных подсистем, реализуемых как самостоятельные, а также бета-версии. Часто они трансформируются в результаты проекта и используются для проверки и подтверждения требований.
Выделяют горизонтальный и вертикальный прототипы.
Горизонтальный прототип – это прототип интерфейса пользователя без реализации бизнес-функциональности;
Вертикальный прототип –реализация всех основных моментов архитектуры с минимальными требованиями интерфейса пользователя.
4. Разъясняющие встречи (часто мозговой штурм).
Генерируются и обсуждаются все идеи. На такой встрече должны быть представлены все группы заинтересованных лиц, чтобы все требования были адекватно представлены. В обязательном порядке должен присутствовать аналитик, которые помогает идеи сформулировать и зафиксировать в виде конкретного требования.
Наблюдение. Непосредственное присутствие инженеров и аналитиков рядом с пользователями в процессе выполнения их работ по реализации бизнес-процессов и фиксирование требований.