- •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.Вопросы для самоконтроля
- •Список литературы
4.5.Системные требования
Как уже было сказано системные требования – это более детальное описание требований пользователей, которое служит разработчикам в качестве базы для проектирования. Системные требования состоят из подробно сформулированного полного списка конкретных свойств и функциональности, которую должна иметь программная система. Каждое из этих требований должно идентифицироваться и отслеживаться по ходу разработки. Предполагается, что основная аудитория для системных требований – это разработчики, но пользователи также должны иметь возможность их понять или прокомментировать большинство из них, поэтому уровень детализации системных требований должен быть полным, но не чрезмерным.
Учитывая важность спецификации и различные группы ее читателей, основные требования к спецификации – это ясность и понятность.
Требования в спецификации могут быть записаны при помощи:
структурированного естественного языка,
языков описания программ,
различных графических нотаций,
математических спецификаций или специальных языков описания требований.
4.5.1.Структурированный естественный язык
Чтобы уменьшить неоднозначность естественного языка для спецификации требований используют его сокращенную форму, что позволяет сохранить выразительность и понятность языка и структурировать описание требований.
Для структурированности языка используют стандартизованные шаблоны (схемы) и четко определенную (в спецификации) терминологию. Стандартные формы описания функциональных требований, например, должны содержать:
описание объекта или функции;
описание входных и выходных данных их источников и приемников;
предусловия и постусловия функции;
побочные эффекты и т.д.
Стандартные схемы (шаблоны) спецификаций будут рассмотрены в следующем разделе.
4.5.2.Языки описания программ
Дальнейшее уточнение описаний возможно путем ограничения и формализации действий, структур данных и управления, используемых в структурированном естественном языке.
Примером такого подхода является язык описания программ PDL (program description language). Этот язык строится по образцу языков программирования, управляющие операторы которых определяют:
внешний синтаксис, т.е. описание структуры управления;
внутренний синтаксис – описание структур данных и процедур их обработки – не определен и выбирается проектировщиком.
С одной стороны такой подход позволяет использовать в описании предложения, написанные на естественном языке, для повышения читаемости требования. С другой – использовать конструкции известных языков программирования и проверять синтаксис и семантику требований существующими программными средствами. Очевидно, что такой подход позволяет получить очень подробные и детальные требования, которые будут доступны для понимания ограниченному числу пользователей спецификации.
Пример 4.4.
Если использовать в описании процесса на PDL предложения, написанные на естественном языке, то описание будет достаточно простым для понимания. На рис. 4.7 приведено описание процесса «Принять программу в архив», рассмотренного в разделе 3.
Рис. 4.7