требования
к функционалу
Описание требуемого поведения системы в определенных условиях
ОРИЕНТАЦИЯ НА БИЗНЕС-ПРОЦЕССЫ
01. ОРИЕНТАЦИЯ НА БИЗНЕС-ПРОЦЕССЫ
Описание любой функциональности как процесса ─ набора автоматизированных шагов, в результате прохождения которых решаются бизнес-задачи и извлекается польза.
ЦЕННОСТЬ
  • Систематизация и стандартизация деятельности компании
  • Интеграция действий различных подразделений через сквозные процессы
  • Возможность постепенной автоматизации
  • Возможность визуализации и анализа бизнес-метрик
ФУНКЦИОНАЛЬНЫЕ ЗАКАЗЧИКИ, ВОВЛЕЧЕННЫЕ В СОЗДАНИЕ ТРЕБОВАНИЙ
02. ФУНКЦИОНАЛЬНЫЕ ЗАКАЗЧИКИ, ВОВЛЕЧЕННЫЕ В СОЗДАНИЕ ТРЕБОВАНИЙ
Эффективное и тесное автоматизированное взаимодействие разработчиков и клиентов (в первую очередь, фактических пользователей) через внутреннюю систему электронного документооборота (СЭД).
ЦЕННОСТЬ
  • Клиенты и разработчики одинаково понимают поставленную задачу
  • Уменьшается разрыв между ожиданиями и реализацией в конце проекта
ОПИСАНИЕ ТРЕБОВАНИЙ ОТ СЦЕНАРИЕВ использования
03. ОПИСАНИЕ ТРЕБОВАНИЙ ОТ СЦЕНАРИЕВ использования
Описание задач, выполняемых пользователем, посредством системы или взаимодействия пользователя и системы, которые дадут полезный результат для того или иного заинтересованного лица. Представляют собой детализированное описание одного из вариантов прохождения по бизнес-процессу.
ЦЕННОСТЬ
  • Более точное понимание требований пользователей
  • Правильная расстановка приоритетов при реализации требований
  • Создание и согласование программ ПСИ
  • Создание эффективных тестов
ИСПОЛЬЗОВАНИЕ ПРОТОТИПОВ ДЛЯ уточнения требований
04. ИСПОЛЬЗОВАНИЕ ПРОТОТИПОВ ДЛЯ уточнения требований
Создание прототипа будущего решения. Возможны различные варианты от макетов форм будущего решения до proof-of-concept.
ЦЕННОСТЬ
  • Прояснение, формулировка и утверждение требований
  • Устранение неясностей на ранних стадиях процесса разработки
  • Исследование альтернативных решений
ИСПОЛЬЗОВАНИЕ СУЩЕСТВУЮЩИХ методологий
05. ИСПОЛЬЗОВАНИЕ СУЩЕСТВУЮЩИХ методологий
Использование существующих архитектурных моделей (например, BIAN) и каталогов процессов (например, кросс-индустриального каталога процессов APQC).
ЦЕННОСТЬ
  • Четкое позиционирование создаваемого продукта
  • Сокращение времени на определение объектного состава продуктов вплоть до использования конкретных сервисов и методов
  • Сокращение времени на выявление процессов организации
НАЛИЧИЕ ПРОЦЕССА УПРАВЛЕНИЯ ТРЕБОВАНИЯ
06. НАЛИЧИЕ ПРОЦЕССА УПРАВЛЕНИЯ ТРЕБОВАНИЯ
Зафиксированная последовательность шагов в ходе выявления, анализа, спецификации, проверки и управления требованиями.
ЦЕННОСТЬ
  • Сокращение сроков согласования требований
  • Упрощение планирования проекта реализации
  • Управление изменениями требований
ДОКУМЕНТИРОВАНИЕ (СПЕЦИФИКАЦИЯ) требований
07. ДОКУМЕНТИРОВАНИЕ (СПЕЦИФИКАЦИЯ) требований
Документирование требований единообразным, доступным и поддающимся проверке способом так, чтобы они были понятными целевой аудитории (как заказчику, так и команде разработки). Наличие согласованных шаблонов для различных типов документов.
ЦЕННОСТЬ
  • Задокументированное соглашение между заинтересованными лицами о создаваемом продукте
  • Основа для дальнейшего планирования, проектирования архитектуры и непосредственно разработки продукта
ДЕКОМПОЗИЦИЯ ТРЕБОВАНИЙ
08. ДЕКОМПОЗИЦИЯ ТРЕБОВАНИЙ
Разбивка исходных функциональных требований на простые требования. Оценка конечного требования на реализацию не должна превышать одной недели (40 часов).
ЦЕННОСТЬ
  • Более точная оценка требований
  • Простыми и малыми требованиями проще управлять
  • Возможность разбить требование на типовые задачи
ОТСЛЕЖИВАНИЕ (ТРАССИРОВКА) требований
09. ОТСЛЕЖИВАНИЕ (ТРАССИРОВКА) требований
Документирование зависимостей и логических связей требований и других элементов системы. В эти элементы входят другие требования различных типов, архитектура, исходный код, тесты, документация и др. В первую очередь интересна связь изначальных входящих требований и конечных требований на реализацию.
ЦЕННОСТЬ
  • Контроль полноты описания требований в части удовлетворения потребности клиента
  • Возможность определения происхождения каждого требования
  • Обнаружение пропущенных или ненужных требований
  • Анализ влияния изменений
ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ ТРЕБОВАНИЙ
10. ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ ТРЕБОВАНИЙ
Использование уже реализованных требований в диапазоне от копирования спецификаций до повторного использования целого функционального компонента. Возможны любые промежуточные варианты. Для этого необходимо сохранять требования в единой базе знаний.
ЦЕННОСТЬ
  • Сокращение сроков создания и согласования требований
  • Более точная оценка реализации
  • Функциональное единообразие в рамках семейства продуктов
ОСТАЛИСЬ ВОПРОСЫ?
Напишите нам, и мы обязательно вам ответим
*поля обязательные к заполнению