Оглавление
Юрий Дубровский. Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ
Введение
ЧАСТЬ I. Что такое бизнес-требования и зачем они нужны
Глава 1. Как начинается разработка
Вместо эпиграфа
Как начинается разработка
Глава 2. Немного о требованиях
Основные виды требований
Способы сбора требований
Разработка «со слов»
Письменная спецификация требований к разработке
Agile-подход
Когда же разумно начинать разработку?
Глава 3. Зачем бизнес-требования?
Строить или перестраивать?
Проект или прототип?
Что хочет заказчик?
Что хочет разработчик?
Чего не хочет ни заказчик, ни разработчик и почему они это получают?
В чем решение?
ЧАСТЬ II: Структура бизнес-требований
Глава 4. Уровень проработки требований и время
Бизнес-требования как механизм управления неопределенностью
Условные категории желаний
«Хотелки»
Ограничения
Жизненный цикл требования
Необходимость и приоритеты
Взаимное влияние
Глава 5. Основные вопросы, на которые отвечают БТ
Среда, порождающая вопросы
Вопросы процесса
Вопросы участников
Вопросы масштаба
Вопросы ресурсов
Вопросы взаимодействия
Готовность бизнеса к формированию требований
ЧАСТЬ III: Детальная структура бизнес-требований
Глава 6. Структура БТ и краткое описание разделов
1. История изменений
2. Общие сведения
2.1. Назначение документа
2.2. Ссылки на документы
2.3. Термины и определения
2.4. Описание объекта автоматизации
2.4.1.Общие сведения
2.4.2.Организационные границы
2.4.3.Общие сведения об автоматизируемых бизнес процессах
2.4.4.Количественные характеристики
2.5. Области изменения компании
2.5.1.Решаемые проблемы
2.5.2.Области изменения
3. Функциональные рамки проекта. 3.1.Требования к бизнес-процессу
3.2.Требования к системе
3.2.1. Требования к объектам системы
3.2.2. Требования к ролям пользователей и группам
3.2.3 Требования к структуре и компонентам системы
3.2.4. Требования к отчетам, поиску, прочим функциям чтения-сортировки-представления
3.2.5. Требования к интерфейсам пользователя
3.2.6. Сценарии работы сотрудников
3.2.7. Требования сценариям и протоколам интеграции
3.3. Требования к архитектуре и инфраструктуре
3.4. Организационные рамки проекта
Выделим следующие также группы требований. 3.4.1. Требование к проектной команде и проектному офису
3.4.2. Требования к обучению
3.4.3. Требования к приемке-сдаче и результатам проекта
3.5. Нефункциональные требования
Вместо эпилога
Заключение
Отрывок из книги
Вы функциональный специалист бизнеса и решили автоматизировать свой бизнес-процесс? Вы уже делали это и знаете по собственному опыту, как порой нелегко донести до разработчика свои потребности? Вы аналитик, которому поручено выяснить бизнес-потребности? Вы разработчик, который хочет понять, что него хочет его заказчик?
Значит Вам нужно определить бизнес-требования.
.....
Преимущества метода очевидны – скорость перехода от идеи к реализации, отсутствие для заказчика необходимости глубоко продумывать и детализировать свою идею, отсутствие трудозатрат на разработку и документирование требований.
Также ценным является ощущение отсутствия потери информации, передаваемой заказчиком разработчику – что рассказал, то и идет сразу в разработку, а не перерабатывается в требования. Поэтому кажется, что информация не может быть искажена по ходу переработки.
.....
