Комментарии 5
В каком виде требования согласовывает заказчик?
Особенно интересует этот вопрос в случае внешнего заказчика.
Не совсем условил. В начале статьи идет:
- описание
Описание границ системы, какие задачи решает система, в общих словах описать функционал
А в конце:
Общее описание
Раздел, который предполагает обозначение контекста. Что это за функционал, какая цель и
ограничения.
И еще Use-case тоже в двух местах. Можете пояснить это дублирование?
1) У систем нет целей, системы предназначены для решения задач.
2) Забыли сказать про роли пользователей в системе.
2) Забыли сказать про роли пользователей в системе.
Для 2го варианта я бы добавил еще и моделирование БП, с указанием систем, ролей и пользовательских, системных, интеграционных и др. задач. Это очень помогает, особенно в обсуждении/согласовании с Заказчиками. Многие скажут, что это задачи бизнес-аналитика, но далеко не везде эти роли разделены.
Use case упомянут дважды.
Use case diagram кстати — очень полезная вещь — позволяет описать скоуп, и отобразать все варианты использования и роли пользователей, и связать их друг с другом.
Диаграмма компонетов чаще всего — не задача аналитика. Даже мокапы интерфейсов чаще приходится рисовать.
Часто ограничения предметной области имеет смысл вынести отдельным разделом.
Плюс, приоритеты требований необходимо указывать.
Use case diagram кстати — очень полезная вещь — позволяет описать скоуп, и отобразать все варианты использования и роли пользователей, и связать их друг с другом.
Диаграмма компонетов чаще всего — не задача аналитика. Даже мокапы интерфейсов чаще приходится рисовать.
Часто ограничения предметной области имеет смысл вынести отдельным разделом.
Плюс, приоритеты требований необходимо указывать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Требования от системного аналитика и шаблоны документации