1. Требования
1.1. Уровни требований
1.1.1. 1) Бизнес требования
1.1.2. 2) Пользовательские требования
1.1.3. 3) Функциональные требования
1.1.3.1. Нефункциональные требования
1.2. Типы требований
1.2.1. Функциональные требования
1.2.1.1. Бизнес требования
1.2.1.2. Пользовательские требования
1.2.1.3. Функциональные требования
1.2.1.4. Системные требования
1.2.1.4.1. Доступ к операциям со счётом должен обеспечиваться через единый сервер
1.2.2. Нефункциональные требования
1.2.2.1. Бизнес правила
1.2.2.1.1. Факты
1.2.2.1.2. Ограничения
1.2.2.1.3. Активаторы(триггеры)
1.2.2.1.4. Вычисления
1.2.2.1.5. Выводы
1.2.2.1.6. Термины
1.2.2.2. Атрибуты качества
1.2.2.2.1. Функциональность
1.2.2.2.2. Надежность
1.2.2.2.3. Удобство использования
1.2.2.2.4. Эффективность
1.2.2.2.5. Обслуживаемость
1.2.2.2.6. Переносимость
1.2.2.3. Ограничения
1.2.2.4. Внешние интерфейсы
1.2.2.4.1. Система должна иметь веб-интерфейс. Система должна поддерживать интеграцию с платежными системами. Система должна иметь возможность обмена данными с другими системами.
1.2.3. Разница между ФТ и НФТ
1.3. Основные техники выявления требований
1.3.1. Интервью
1.3.2. Анекетирование
1.3.3. Наблюдение
1.3.4. Мозговой штурм
1.3.5. Фокус-группы
1.3.6. Анализ документации
1.3.7. Анализ интерфейсов
1.3.8. Анализ конкурентов
1.3.9. Прототипирование
1.4. Документация
1.4.1. Cпецификация требований
1.4.2. Диаграммы
1.4.3. Прототипы
1.4.4. Use Case
1.4.4.1. Имя сценария
1.4.4.2. Цель
1.4.4.3. Действующие лица
1.4.4.4. Заинтересованные лица
1.4.4.5. Предварительные условия
1.4.4.6. Активаторы
1.4.4.7. Порядок Событий
1.4.4.8. Альтернативные пути и дополнения
1.4.4.9. Исключения
1.4.4.10. Результат
1.4.4.11. Дополнения
1.4.5. User Story
1.4.5.1. Как [пользователь], я хочу [цель] ... Чтобы [получить выгоду]...
1.4.5.2. Критерии приемки (Acceptance Criteria, AC)
1.4.5.2.1. Четкими и однозначными.
1.4.5.2.2. Измеримыми
1.4.5.2.3. Достижимыми.
1.4.5.2.4. Релевантными User Story.
1.4.5.2.5. Ограниченными по времени.
1.4.5.3. INVEST
1.4.5.3.1. I — Independent. Не зависит от других историй. Все они могут быть реализованы в любом порядке.
1.4.5.3.2. N — Negotiable. Обсуждаема. Она отражает суть, а не детали, и не содержит конкретных шагов реализации.
1.4.5.3.3. V — Valuable. Ценна для клиентов, бизнеса и стейкхолдеров.
1.4.5.3.4. E — Estimable. Её можно оценить по сложности и трудозатратам
1.4.5.3.5. S — Small. Она компактна и может быть сделана командой за одну итерацию.
1.4.5.3.6. T — Testable. Она имеет определённые критерии приёмки, т. е. тестируема
1.4.5.4. Техника SMART
1.4.5.4.1. S (Specific) – Конкретная: Цель должна быть сформулирована максимально точно и однозначно, чтобы не было возможности интерпретировать ее по-разному.
1.4.5.4.2. M (Measurable) – Измеримая: Цель должна быть измеримой, чтобы можно было определить, достигнута она или нет.
1.4.5.4.3. A (Achievable) – Достижимая: Цель должна быть реальной и выполнимой с учетом имеющихся ресурсов и возможностей.
1.4.5.4.4. R (Relevant) – Релевантная: Цель должна соответствовать стратегическим задачам компании и личным интересам человека.
1.4.5.4.5. T (Time-bound) – Ограниченная во времени: Цель должна иметь конкретный срок достижения.
1.4.6. Gherkin
1.5. Управления требованиями
1.5.1. Управление версиями
1.5.2. Управление изменениями
1.5.3. Отслеживание состояний требований
1.5.3.1. ❏ Идентификатор ❏ Автор требования ❏ Сложность ❏ Собственность ❏ Приоритет ❏ Источник требования ❏ Законченность ❏ Статус ❏ Срочность
1.5.4. Отслеживание связей требований
1.5.4.1. 1. Проверка достаточности требований и отсутствие "лишних" требований - достигается путём выявления взаимосвязей бизнес-целей (требований) с FR; 2. Используется как инструмент анализа влияния. При внесении изменений в требования, пройдя по цепочке взаимосвязей в матрице, можно определить, какие элементы затрагивают изменения; 3. Используется как система коммуникации между всеми ЗЛ на проекте; 4. Используется как источник информации при трансформации системы.
1.6. Верификация
1.6.1. Характеристики хороших требований
1.6.1.1. Четкими и однозначными: Требования должны быть сформулированы так, чтобы их можно было интерпретировать только одним образом.
1.6.1.2. Измеримыми: Требования должны быть измеримыми, чтобы можно было отслеживать их выполнение.
1.6.1.3. Достижимыми: Требования должны быть реалистичными и достижимыми с учетом имеющихся ресурсов и технологий.
1.6.1.4. Релевантными: Требования должны быть релевантными целям проекта и потребностям пользователей.
1.6.1.5. Ограниченными по времени: Требования должны иметь четко определенные сроки выполнения.
1.6.1.6. Полными: Требования должны описывать всю необходимую функциональность и характеристики ПО.
1.6.1.7. Непротиворечивыми: Требования не должны противоречить друг другу.
1.6.1.8. Изменяемыми: Требования должны быть изменяемыми, чтобы можно было адаптироваться к меняющимся потребностям.
1.6.2. Валидация
1.6.3. Верефикация
2. Документы
2.1. V&S
2.1.1. Бизнес-требования
2.1.1.1. 1.1 Исходные данные
2.1.1.2. 1.2 Возможности бизнеса
2.1.1.3. 1.3 Бизнес-цели
2.1.1.4. 1.4 Критерии успеха
2.1.1.5. 1.5 Положение о концепции проекта
2.1.1.6. 1.6 Бизнес-риски
2.1.1.7. 1.7 Предположения и зависимости
2.1.2. Рамки и ограничения проекта
2.1.2.1. 2.1 Основные функции
2.1.2.2. 2.2 Объем первоначально запланированной версии
2.1.2.3. 2.3 Объем последующих версий
2.1.2.4. 2.4 Ограничения и исключения
2.1.3. Бизнес-контекст
2.1.3.1. 3.1 Профили заинтересованных лиц
2.1.3.2. 3.2 Приоритеты проекта
2.1.3.3. 3.3 Особенности развертывания
2.2. Спецификация требований ПО (SRS)
2.2.1. IEEE 830-1998
2.2.2. Когда применять
2.2.3. RUP (Rational Unified Process)
2.2.3.1. фокусируется на процессе разработки и взаимодействии с пользователями
2.2.4. ISO IEEE 29148-2011
2.2.4.1. фокусируется на более формализованном и структурированном описании требований к системе
2.3. ТЗ, ЧТЗ
2.3.1. ТЗ
2.3.2. ЧТЗ
2.3.3. Стандарты написания ТЗ и ЧТЗ
2.3.3.1. ГОСТ 34
2.3.3.1.1. 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6. Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9. Источники разработки
2.3.3.2. ГОСТ 19
2.3.3.2.1. 1. Введение; 2. Основания для разработки; 3. Назначение разработки; 4. Требования к программе или программному изделию; 5. Требования к программной документации; 6. Технико-экономические показатели; 7. Стадии и этапы разработки; 8. Порядок контроля и приемки; 9. Приложения.
2.3.3.3. IEEE STD 830-1998
2.3.3.3.1. Содержание
2.3.3.4. • ISO/IEC/ IEEE 29148-2011
2.3.3.4.1. SyRS
2.3.3.4.2. SRS
2.3.3.5. • RUP
2.3.3.5.1. Содержание
2.3.3.6. • SWEBOK, BABOK