- •1.Виды, взаимосвязь и свойства требований
- •1.1.Что такое «требование»?
- •1.2.Виды требований
- •1.2.1.Функциональные требования
- •1.2.2.Нефункциональные требования
- •1.2.2.1.Нефункциональные требования к продукту
- •1.2.2.2.Нефункциональные требования к процессу
- •1.2.2.3.Внешние нефункциональные требования
- •1.5.Вопросы для самоконтроля
- •2.Определение образа и границ проекта
- •2.1.Анализ предметной области
- •2.2.Анализ осуществимости
- •2.3.Определение целей и области действия
- •2.4.Документирование образа и границ проекта
- •2.5.Вопросы для самоконтроля
- •3.Выявление требований
- •3.1.Определение способа сбора и анализа требований
- •3.1.1.Источники возникновения требований
- •3.1.2.Заинтересованные в проекте лица
- •3.2.Опрос (интервью)
- •3.2.1.Подготовка
- •3.2.2.Проведение опроса
- •3.2.3.Определение последующих действий
- •3.3.Совместные семинары
- •3.4.”Мозговой штурм”
- •3.4.1.Роли во время сеансов
- •3.4.2.Правила проведения сеанса
- •3.4.3.Подготовка к сеансу
- •3.4.4.Проведение сеанса
- •3.4.5.Обработка результатов сеанса
- •3.5.Сценарии
- •3.5.1.Сценарии событий
- •3.5.2.Варианты использования
- •3.5.3.Применение модели msc uml
- •3.6.Выявление требований на основе различных точек зрения. Метод vord
- •3.6.1.Идентификация точек зрения
- •3.6.2.Структурирование точек зрения
- •3.6.3.Документирование и отображение системы точек зрения
- •3.7.Этнографический подход
- •3.8.Вопросы для самоконтроля
- •4.Разработка системных требований
- •4.1.Детализация требований пользователей
- •4.2.Системные модели
- •4.2.1. Модели потоков данных
- •4.2.2.Модели конечных автоматов
- •4.2.3.Модели данных
- •4.3.Прототипы
- •4.3.1.Роль прототипов при разработке требований
- •4.3.2.Виды прототипов
- •4.4.Разработка прототипов
- •4.4.1.Экспериментальное прототипирование
- •4.4.2.Эволюционное прототипирование
- •4.4.3.Риски прототипирования
- •4.5.Системные требования
- •4.5.1.Структурированный естественный язык
- •4.5.2.Языки описания программ
- •4.5.3.Графические нотации
- •4.6.Документирование системных требований
- •4.7.Вопросы для самоконтроля
- •5.Документирование требований
- •5.1.Спецификация требований
- •5.2.Состав спецификации требований
- •5.3.Рекомендации по разработке требований
- •5.4.Стандартные шаблоны спецификации
- •5.5.Вопросы для самоконтроля
- •6.Анализ спецификации требований
- •6.1.Оценка качества спецификации требований
- •6.1.1.Характеристики качества спецификации
- •6.1.2.Аттестация требований
- •6.2.Экспертиза спецификации
- •6.3.Прототипирование
- •6.4.Автоматизированный анализ
- •6.5.Тестирование требований
- •6.6.Вопросы для самоконтроля
- •7.Управление требованиями
- •7.1.Причины изменений требований
- •7.2.Принципы управления требованиями
- •7.3.Управление изменениями
- •7.4.Управление версиями
- •7.5.Управление связями требований
- •7.6.Риски, связанные с требованиями
- •7.6.1.Риски этапа выявления требований
- •7.6.2.Риски этапа анализа и спецификации требований
- •7.6.3.Риски управления требованиями
- •7.7.Вопросы для самоконтроля
- •8.Case-средства для управления требованиями
- •8.1.Выбор case-средств для управления требованиями
- •8.2.Уровень зрелости и используемые инструменты
- •8.2.1.Моделирование требований
- •8.2.2.Трассировка требований
- •8.2.3.Управление версиями
- •8.3.Возможности case-средств управления требованиями
- •8.3.1. Средства idf-моделирования
- •8.3.2.Средства uml
- •8.4.Вопросы для самоконтроля
- •Список литературы
1.2.2.2.Нефункциональные требования к процессу
Нефункциональные требования к процессу зависят от политики и организационных процедур заказчика и разработчика. Они определяют ограничения, связанные с использованием определенных технологий и стандартов разработки, ограничения реализации, например, использования определенного языка программирования и методов проектирования, требования к документации, срокам изготовления программного продукта и т.д.
1.2.2.3.Внешние нефункциональные требования
Внешние нефункциональные требования учитывают факторы, внешние по отношению к системе и процессу ее разработки. Они определяют взаимодействие проектируемой системы с другими системами, требования по квалификации персонала, юридические требования, логистические требования, требования среды, этические, экологические и т.п. требования.
Гагарина с. 36-46
Словарь терминов
Словарь терминов представляет собой краткое описание
основных понятий, используемых при составлении спецификаций.
Он предназначен для повышения степени понимания предметной области и исключения риска возникновения разногласий при обсуждении моделей между заказчиками и разработчиками [1].
Обычно описание термина в словаре выполняют по следующей схеме:
• термин;
• категория (понятие предметной области, элемент данных,
условное обозначение и т. д.);
• краткое описание.
Пример:
Термин Web-сайт
Категория Интернет-программирование
Описание Совокупность Web-страниц с повторяющимся дизайном, объединенных по смыслу, навигационно и физически находящихся на одном сервере.
1.3.Свойства требований
Требования должны удовлетворять определенным характеристикам качества. Основные характеристики – это полнота, корректность, необходимость, осуществимость, приоритет, недвусмысленность, непротиворечивость (согласованность), проверяемость и прослеживаемость (см. рис. 1.1).
Рис. 1.1
1.3.1.Полнота и корректность
Требование должно полно и точно описывать функцию, которую необходимо реализовать в продукте, содержать всю необходимую для разработчиков информацию. Контроль над корректностью требований возлагается на пользователей, т.к. только требование, согласующееся с источником (пожеланиями пользователей) считается корректным.
1.3.2.Необходимость и осуществимость
Каждое требование должно отражать функциональность или ограничение, которая действительно необходима для пользователя или для удовлетворения внешних требований. Должна существовать возможность реализации каждого требования в ограничениях проекта.
1.3.3.Приоритет
Для реализации в определенной версии продукта каждому функциональному требованию или характеристике должен быть назначен приоритет. Это позволит упростить управление проектом при учете ограничений времени, бюджета и постоянного изменения требований.
1.3.4.Недвусмысленность и непротиворечивость
Недвусмысленность требований предполагает, что все читатели требований интерпретируют их одинаково. Для этого требования должны быть написаны просто, кратко и точно. Не должно быть конфликтующих между собой требований.
1.3.5.Проверяемость и прослеживаемость.
Должна существовать возможность проверить требование после реализации, тестировать требование. Требование, которое невозможно протестировать не имеют большой ценности. Для контроля требования (от момента принятия до реализации) требование должно быть прослеживаемым.
1.4.Особенности разработки требований к программным системам
Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов (см. рис. 1.2).
Рис. 1.2
Анализ предметной области.
Позволяет выделить сущности предметной области, определить первоначальные требования к функциональности и определить границы проекта.
Анализ осуществимости. Должен выполняться для новых программных систем. На основании анализа предметной области, общего описания системы и ее назначения принимается решение о продолжении или завершении проекта.
Формирование и анализ требований. Взаимодействуя с пользователями, обсуждая и анализируя с ними задачи, возлагаемые на систему, разрабатывая модели и прототипы, разработчики формулируют пользовательские требования.
Документирование требований. Сформированные на предыдущем этапе пользовательские требования должны быть документированы. При этом нужно учесть, что основными читателями этого документа будут пользователи, поэтому основными требованиями к нему будут ясность и понятность.
Детализация требований. Разработчики детализируют требования пользователей, формируя более точные подробные системные требования.
Согласование и утверждение требований. На этом этапе пользовательские и системные требования должны быть оформлены в виде единого документа, содержащего все функциональные и нефункциональные требования. Такой документ, обычно, называется спецификацией требований.
К особенностям разработки требований относятся:
Сложность процесса.
Итеративность процесса.
Процесс не заканчивается на стадии жизненного цикла «Анализ требований». И на следующих этапах проекта требования могут изменяться, появляться новые требования и исключаться существующие.
Для сохранения целостности, точности и актуальности требований должен выполняться процесс управления требованиями.