Должна существовать возможность проверить требование после реализации, тестировать требование. Требование, которое невозможно протестировать не имеют большой ценности. Для контроля требования (от момента принятия до реализации) требование должно быть прослеживаемым.

1.4. Особенности разработки требований к программным
системам

Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов (см. рис. 1.2).

Рис. 1.2

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

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

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

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

5. Детализация требований. Разработчики детализируют требования пользователей, формируя более точные подробные системные требования.

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

К особенностям разработки требований относятся:

1. Сложность процесса.

2. Итеративность процесса.

3. Процесс не заканчивается на стадии жизненного цикла «Анализ требований». И на следующих этапах проекта требования могут изменяться, появляться новые требования и исключаться существующие.

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

Вопросы:

1. Требования к системе по стандартам IEEE

2. Требования к системе по стандарту ISO 12207

3. Три уровня требований и их польза

4. Функциональные требования

5. Нефункциональные требования

6. Нефункциональные требования к продукту

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

8. Атрибуты качества, важные для разработчиков и специалистов

9. Нефункциональные требования к процессу

10. Внешние нефункциональные требования

11. Свойства требований: полнота, корректность, необходимость, осуществимость

12. Свойства требований: приоритет, недвусмысленность, непротиворечивость, проверяемость, прослеживаемость

13. Этапы и особенности разработки требований

Определение образа и границ проекта

Изучив тему, Вы будете знать:

§ цели анализа предметной области;

§ некоторые методики анализа предметной области;

§ цели разработки документа об образе и границе проекта.

При освоении темы необходимо акцентировать внимание:

§ на методиках анализа предметной области и анализа осуществимости;

§ на содержании разделов документа об образе и границах проекта.

Анализ предметной области

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

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

Для управления обсуждением области действия проекта можно использовать методику «будет – не будет». В простейшем случае – это список с двумя столбцами, в одном из которых записывается, что проект будет делать, а во втором – что не входит в проект. Такой список, формируется заинтересованными лицами при рассмотрении каждой бизнес-цели проекта, используя любую технику, например метод «мозгового штурма». Полученные характеристики позволяют четко определить границы проекта и довольно просто преобразуются в предположения, которые фиксируются в документе.

Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список «Действующее лицо/Цель», в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу – цель каждого действующего лица, а в третью – приоритет или предположение о том, в какую версию войдет эта услуга.

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

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

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

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

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

2. Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?

3. Можно ли объединить систему с другими уже эксплуатируемыми системами?

Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,

· что произойдет с организацией, если система не будет введена в эксплуатацию;

· как система будет способствовать целям бизнеса;

· какие текущие проблемы поможет решить система и т.д.

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