Поставка программных продуктов Oracle
+7(343)287-52-37
 
 

Наши стандарты ведения бизнеса.

Разработка требований


Разработка требований - это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований: анализ технической осуществимости создания системы, формирование и анализ требований, специфицирование требований и создание соответствующей документации, а также аттестация этих требований.


Анализ осуществимости


Для новых программных систем процесс разработки требований должен начинаться с анализа осуществимости. Началом такого анализа является общее описание системы и её назначения, а результатом анализа - отчёт, в котором должна быть чёткая рекомендация, продолжать или нет процесс разработки требований проектируемой системы. Другими словами, анализ осуществимости должен осветить следующие вопросы.


Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?


Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости? Можно ли объединить систему с другими системами, которые уже эксплуатируются? Необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе.

Формирование и анализ требований

После выполнения анализа осуществимости следующим этапом процесса разработки требований является формирование (определение) и анализ требований. На этом этапе команда разработчиков ПО работает с заказчиком и конечными пользователями системы для выяснения области применения, описания системных сервисов, определения режимов работы системы и её характеристик выполнения, аппаратных ограничений и т.д.

Процесс формирования и анализа требований проходит через ряд этапов.

Анализ предметной области: аналитики должны изучить предметную область, где будет эксплуатироваться система.

Сбор требований: это процесс взаимодействия с экспертами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

Классификация требований: на этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.

Разрешение противоречий: без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.

Назначение приоритетов: в любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.

Проверка требований: на этом этапе определяется их полнота, последовательность и непротиворечивость.

Процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому. Цикл начинается с анализа предметной области и заканчивается проверкой требований. Понимание требований предметной области увеличивается в каждом цикле процесса формирования требований.

Подходы к формированию требований: метод, основанный на множестве опорных точек зрения, сценарии и этнографический метод. Другие подходы, которые могут использоваться в процессе разработки требований, - это методы структурного анализа и методы прототипирования. Не существует универсального подхода к формированию и анализу требований.

Обычно для разработки требований одновременно используется несколько подходов.

Аттестация требований

Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование. Во время процесса аттестации должны быть выполнены различные типы проверок документации требований.

Проверка правильности требований.
Пользователь может считать, что система необходима для выполнения некоторых определённых функций. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций. Системы, предназначены для разных пользователей с различными потребностями, и поэтому набор требований будет представлять собой некоторый компромисс между требованиями пользователей системы.

Проверка на непротиворечивость.
Спецификация требований не должна содержать противоречий. Это означает, что в требованиях не должно быть противоречащих друг другу ограничений и различных описаний одной и той же системной функции.

Проверка на полноту.
Спецификация требований должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.

Проверка на выполнимость.
На основе знания существующих технологий требования должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы.

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности.

Обзор требований.
Требования системно анализируются рецензентами.

Прототипирование.
На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.

Генерация тестовых сценариев.

В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.

Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей.

Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в базе данных.

 

Разработчик: ЗАО "Софт Плюс" г.Екатеринбург, ул. Чкалова 4, офис 5. Тел: +7(343) 287-52-37 E-mail: mike@softplus.ru


Support Wikipedia