1. 4. Управлением масштабом
1.1. Задание масштаба проекта
1.1.1. Базовый уровень
1.1.1.1. Установка приоритетов функций
1.1.1.1.1. Критический
1.1.1.1.2. Важный
1.1.1.1.3. Полезный
1.1.1.2. Оценка трудозатрат
1.1.1.2.1. Высокая
1.1.1.2.2. Средняя
1.1.1.2.3. Низкая
1.1.1.3. Оценка риска
1.1.1.3.1. Высокий
1.1.1.3.2. Средний
1.1.1.3.3. Низкий
1.2. Сокращение масштаба
1.3. Умение общаться с заказчиком
2. 5. Уточнение Определения Системы
2.1. Спецификация требований к Программному Обеспечению (Modern SRS Package)
2.1.1. Требования к программному обеспечению
2.1.1.1. Категории элементов для определения системы
2.1.1.1.1. Вводы системы
2.1.1.1.2. Выводы системы
2.1.1.1.3. Функции системы
2.1.1.1.4. Атрибуты системы
2.1.1.1.5. Стрибуты системной среды
2.1.1.2. Функциональные требования
2.1.1.3. Нефункциональные требования
2.1.1.3.1. Практичность (Usability)
2.1.1.3.2. Надежность Reliability
2.1.1.3.3. Производительность (Performance)
2.1.1.3.4. Возможность обслуживания (Supportability)
2.1.1.4. Ограничения проектирования
2.1.1.5. Использование дочерних требований
2.1.2. Критерии качества требования к ПО
2.1.2.1. Корректность
2.1.2.2. Недвусмысленность
2.1.2.3. Полнота
2.1.2.4. Непротиворечивость
2.1.2.5. Упорядоченность по важности и стабильности
2.1.2.6. Должно поддаваться проверке
2.1.2.7. Модифицируемость
2.1.2.8. Трассируемость
2.1.2.9. Понимаемость
2.1.3. Критерии качеств пакета Modern SRS Package
2.1.3.1. Хорошо составленное оглавление
2.1.3.2. Хороший индекс
2.1.3.3. История исправлений
2.1.3.4. Глоссарий
2.2. Уточнение прецедентов
2.2.1. Определение акторов
2.2.2. Дать название прецеденту
2.2.3. Составление краткого описания
2.2.4. Определение потока событий
2.2.4.1. Основной поток
2.2.4.2. Альтернативные потоки
2.2.5. Выявление пред- и постусловий
2.3. Неоднозначность и уровень конкретизации
2.3.1. Методы избежания неоднозначности
2.3.1.1. Эвристика запоминаний
2.3.1.2. Метод ключевых слов
2.3.1.3. Метод ударения
2.3.1.4. Другие
2.3.2. Что делать
2.4. Формальные методы спецификации требований
2.4.1. Псевдокод
2.4.2. Конечные автоматы
2.4.3. Деревья решений
2.4.4. Диаграммы деятельности
2.4.5. Модель сущность-связь
2.4.6. Объектно-ориентированные модели
2.4.7. Схемы потоков данных
3. 6. Построение правильной системы
3.1. Верификация
3.1.1. Стадии проекта, подлежащие верификации
3.1.1.1. Описанные функции действительно соответствуют потребностям
3.1.1.2. Производные от этих функций прецеденты и требования поддерживают данные функции
3.1.1.3. Прецеденты реализуются при проектировании
3.1.1.4. Проектирование поддерживает функциональные и нефункциональные аспекты поведения системы
3.1.1.5. Код действительно соответствует результатам и целям проектирования
3.1.1.6. Тесты обеспечивают полное покрытие разработанных требований и прецедентов
3.1.2. Уровни верификации
3.1.2.1. От потребностей пользователя к функциям продукта
3.1.2.2. От функций продукта к требованиям
3.1.2.3. От требований к архитектуре
3.1.2.4. От архитектуры к модели проектирования
3.1.2.5. От модели проектирования к реализации
3.1.2.6. От реализации к планированию тестов
3.2. From Use cases to Implementation (От понимания требований к реализации системы)
3.2.1. Проблема ортогональности
3.2.2. Объектно-ориентированный подход
3.2.3. Прецедент в роли требований
3.2.4. Архитектура систем ПО
3.2.4.1. Задачи архитектуры
3.2.4.1.1. Понять, что делает система
3.2.4.1.2. Понять, как она работает
3.2.4.1.3. Иметь возможность обдумывать и разрабатывать части системы
3.2.4.1.4. Расширять систему
3.2.4.1.5. Повторно использовать части системы для создания новых систем
3.2.4.2. 4+1 представление архитектуры
3.2.4.2.1. Логическое представлние
3.2.4.2.2. Вид с точки зрения процессов
3.2.4.2.3. Вид с точки зрения прецедентов
3.2.4.2.4. Вид с точки зрения реализации
3.2.4.2.5. Вид точки зрения процессов
3.2.5. Реализация прецедентов в модели проектирования
3.3. Использование трассировки для поддержки верификации (Tracing Requirements)
3.4. Проверка правильности системы
3.5. Управление изменениями (Managing Change)
3.5.1. Факторы изменения требований
3.5.1.1. Внешние факторы
3.5.1.1.1. Произошли изменения проблемы
3.5.1.1.2. Пользователи изменили свое мнение о том, чего хотят от системы
3.5.1.1.3. Изменилась внешняя среда
3.5.1.1.4. Вошла в строй новая система
3.5.1.2. Внутренние факторы
3.5.1.2.1. При первоначальном выявлении требований не удалось задать правильные вопросы нужным людям в нужное время
3.5.1.2.2. Не удалось создать практический процесс, позволяющий справиться с изменением требований
3.5.2. Процесс управления изменениями
3.5.2.1. Осознать, что изменения неизбежны, и разработать план управления изменениями
3.5.2.2. Сформировать базовый уровень требований
3.5.2.3. Установить единый канал контроля изменений
3.5.2.4. Использовать систему контроля изменений для их фиксации
3.5.2.5. Обрабатывать изменения по иерархическому принципу
4. 2. Понимание поттребностей пользователей
4.1. Преграды на пути выявления требований
4.1.1. Синдром "да, но..."
4.1.2. Синдром "неоткрытых руин"
4.1.3. Синдром "пользователя и разработчика"
4.2. Методы выявления требований
4.2.1. Интервьюирование и анкетирование
4.2.2. Совещания, посвященные требованиям
4.2.3. Мозговой штурм, посвященный идеям
4.2.4. Раскадровки
4.2.4.1. Пассивные
4.2.4.2. Активные
4.2.4.3. Интерактивные
4.2.5. Прецеденты (Юзкейсы)
4.2.6. Обыгрывание ролей
4.2.7. Создание прототипов
4.3. Функции продукта или системы
4.3.1. Атрибуты функий
4.3.1.1. Статус
4.3.1.2. Приоритет/Полезность
4.3.1.3. Трубоемкость
4.3.1.4. Риск
4.3.1.5. Стабильность
4.3.1.6. Целевая версия
4.3.1.7. Назначение
4.3.1.8. Обоснование
5. 1. Анализ проблемы
5.1. 5 Этапов анализа проблемы
5.1.1. Достигнуть соглашения об определении проблемы
5.1.2. Выделить основные причины - проблемы, стоящие за проблемой
5.1.3. Выявить заинтересованных лиц и пользователей
5.1.4. Определить границу системы решения
5.1.5. Выявить ограничения, котоыре необходимо наложить на решение
5.2. Моделирование Бизнес-процессов
5.2.1. Цели моделирования БП
5.2.1.1. Разобраться в структуре и динамике огранизации
5.2.1.2. Удостовериться в том, что заказчики, конечные пользователи и разработчики имеют одинаковое понимание организации
5.2.2. Выбор методологии моделирования БП
5.3. System Engineering (Системная инженерия)
5.3.1. Принципы системной инженерии
5.3.1.1. Знание проблемы, клиента и потребителя
5.3.1.2. Использование основанных на потребностях критериев эффективности для принятия системных решений
5.3.1.3. Задание требований и управление ими
5.3.1.4. Выявление и оценка альтернатив для оценки решения
5.3.1.5. Верификация и проверка правильности требований, а также функционирования решения
5.3.1.6. Обеспечение целостности системы
5.3.1.7. Использование согласованного и документированного процесса
5.3.1.8. Организация действий согласно плану
6. 3. Определение системы
6.1. Организация информации о требованиях
6.1.1. Документ-концепция
6.1.1.1. Vision 1.0
6.1.1.2. Delta Vision