21. Запись функциональных требований к информационной системе с помощью вариантов использования. Пример диаграммы вариантов использования интернет-системы бронирования авиабилетов.(125, 162)
Во время процесса аттестации должны быть выполнены следующие типы проверок документации требований:
Проверка правильности требований. Пользователь может считать, что система необходима для выполнения некоторых определенных функций. Практика показывает необходимость введения дополнительных или новых функций. Системы предназначены для пользователей с разными потребностями, и поэтому набор требований будет представлять собой некоторый компромисс между требованиями пользователей системы.
Проверка на непротиворечивость. В спецификациях требований не должно быть противоречащих друг другу ограничений или различных описаний одной и той же системной функции.
Проверка на полноту. Спецификация требований должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.
Проверка на выполнимость. На основе знания существующих технологий разработки разных типов приложений, требования должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы.
Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности.
Обзор требований. Это процесс просмотра системной спецификации для нахождения неточных описаний и ошибок, а также проверки непротиворечивости требований и их полноты.
Прототипирование. Это построение относительно простой системы, которая реализует наиболее важные требования пользователя. Основная функция прототипа системы - помочь в понимании требований. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику для того, чтобы убедиться в том, что он отвечает их потребностям.
Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. В противном случае это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.
Одной из причин изменения требований в процессе разработки систем является то, что во время этого процесса неизбежно меняется понимание разработчиками поставленных перед ними задач. Другой причиной является обеспечение преемственности «улучшенных» систем к действующим, которая связана с многообразием контингента пользователей, требования которых и их приоритеты различны; деловая среда и техническое окружение системы изменяются, что должно найти отражение в системе и т.д.
Поэтому управление требованиями – это процесс управления изменениями системных требований, который выполняется совместно с другими процессами разработки требований.
При формировании требований основное внимание сосредоточено на возможностях создаваемого ПО, бизнес – целях и других бизнес – системах организации. После формирования требований достигается более глубокое понимание потребностей пользователей, вследствие чего может возникнуть необходимость в изменении ранее сформулированных требований. Кроме того, существует временной фактор с точки зрения изменений окружения и бизнес – требований к системе, что также должно найти отражение в измененных требованиях.
(СДЕЛАЙ ЕГО ДЛЯ БРОНИРОВАНИЯ БИЛЕТОВ)
Рис. 6.20. Диаграмма вариантов использования для книжного Internet-магазина