- •1.Виды, взаимосвязь и свойства требований
- •1.1.Виды требований
- •1.1.1.Функциональные требования
- •1.1.2.Нефункциональные требования
- •1.1.2.1.Нефункциональные требования к продукту
- •1.1.2.2.Нефункциональные требования к процессу
- •1.4.Сценарии
- •1.4.1.Сценарии событий
- •2.Разработка системных требований
- •2.1.Детализация требований пользователей
- •2.1.1.Модели потоков данных
- •2.1.2.Модели конечных автоматов
- •2.2.Прототипы
- •2.2.1.Роль прототипов при разработке требований
- •2.2.2.Виды прототипов
- •2.3.Разработка прототипов
- •2.3.1.Экспериментальное прототипирование
- •2.3.2.Эволюционное прототипирование
- •2.4.Системные требования
- •2.4.1.Структурированный естественный язык
- •2.4.2.Языки описания программ
- •2.4.3.Графические нотации
- •2.5.Документирование системных требований
- •3.Анализ спецификации требований
- •3.1.Оценка качества спецификации требований
- •3.1.1.Характеристики качества спецификации
- •4.Управление требованиями
- •4.1.Причины изменений требований
- •4.2.Управление изменениями
2.1.2.Модели конечных автоматов
Модели конечных автоматов используются для моделирования поведения системы, которая реагирует на внутренние или внешние события. Эта модель показывает состояние системы и события, которые служат причиной перехода системы в следующее состояние, не описывая поток данных внутри системы.
Популярность конечных автоматов состоит в том, что данная техника развивается уже достаточно давно, и теоретические результаты были с успехом использованы при решении многих практических задач. В частности, системы автоматизации проектирования, спецификации и программирования, основанные на конечных автоматах и их модификациях, активно развиваются и применяются десятки лет. Особенно часто конечные автоматы применяются в конкретных предметных областях, где можно обойтись без использования универсальных моделей вычислимости. В результате очень многие пользователи, инженеры и программисты хорошо знакомы с конечными автоматами и применяют их без затруднений. Наконец, важным практическим обстоятельством является тот факт, что автоматы очень легко программируются средствами обычных языков программирования.
Модель конечного автомата системы предполагает, что в каждый момент времени она находится в некотором устойчивом состоянии. При получении входного сигнала (события) система может изменить свое состояние или остаться в прежнем состоянии.
Пример 4.2.
На рис. 4.3 приведена диаграмма конечного автомата, описывающего процесс «Принять программу в архив».
Рис. 4.3
Система находится в начальном состоянии и ожидает запроса. После его получения она переходит в состояние «Контроль запроса», где выясняет, имеет ли разработчик полномочия для сдачи программы в архив. Если полномочий недостаточно или программа уже находится в архиве, то система возвращается в начальное состояние.
2.2.Прототипы
При разработке требований трудно предвидеть, как система будет взаимодействовать с другими системами, как она повлияет на трудовой процесс, какие операции нужно автоматизировать. Анализ требований позволяет снять некоторую неопределенность, но четкое определение требований к разрабатываемой системе, их проверка – задача весьма сложная. Разработка прототипа позволяет сделать требования более реальными, помогает заинтересованным лицам прийти к общему пониманию требований, ускоряет процесс разработки и анализа.
2.2.1.Роль прототипов при разработке требований
Прототип – это начальная версия программной системы, которая используется для демонстрации концепций, заложенных в системе, проверки вариантов требований, а также поиска проблем, которые могут возникнуть как в ходе разработки, так и при эксплуатации системы, чтобы пользователи могли начать экспериментировать с ним как можно раньше [9].
Прототип полезен в решения следующих задач:
Разработка требований.
Прототип представляет собой предварительную (возможно, неполную) версию системы или ее части, экспериментируя с которой пользователи получают новые идеи и формулируют требования.
Проверка требований.
Оценка прототипа позволяет найти ошибки и неточности в требованиях и исправить их без больших затрат. Действующий прототип помогает выявить различные толкования требований, неполные или несогласованные требования.
Разработка взаимодействия с пользователем.
Прототип позволяет реализовать различные варианты взаимодействия, исследовать альтернативные решения и выбрать оптимальный вариант.
Спецификация системных требований.
Прототип может служить основой для написания высококачественных системных требований.