Недвусмысленность и непротиворечивость
Недвусмысленность требований предполагает, что все читатели требований интерпретируют их одинаково. Для этого требования должны быть написаны просто, кратко и точно. Не должно быть конфликтующих между собой требований.
Проверяемость и прослеживаемость.
Должна существовать возможность проверить требование после реализации, тестировать требование. Требование, которое невозможно протестировать не имеют большой ценности. Для контроля требования (от момента принятия до реализации) требование должно быть прослеживаемым.
1.4. Особенности разработки требований к программным
системам
Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов (см. рис. 1.2).
Рис. 1.2
1. Анализ предметной области.
2. Позволяет выделить сущности предметной области, определить первоначальные требования к функциональности и определить границы проекта.
3. Анализ осуществимости. Должен выполняться для новых программных систем. На основании анализа предметной области, общего описания системы и ее назначения принимается решение о продолжении или завершении проекта.
4. Формирование и анализ требований. Взаимодействуя с пользователями, обсуждая и анализируя с ними задачи, возлагаемые на систему, разрабатывая модели и прототипы, разработчики формулируют пользовательские требования.
5. Документирование требований. Сформированные на предыдущем этапе пользовательские требования должны быть документированы. При этом нужно учесть, что основными читателями этого документа будут пользователи, поэтому основными требованиями к нему будут ясность и понятность.
6. Детализация требований. Разработчики детализируют требования пользователей, формируя более точные подробные системные требования.
7. Согласование и утверждение требований. На этом этапе пользовательские и системные требования должны быть оформлены в виде единого документа, содержащего все функциональные и нефункциональные требования. Такой документ, обычно, называется спецификацией требований.
К особенностям разработки требований относятся:
1. Сложность процесса.
2. Итеративность процесса.
3. Процесс не заканчивается на стадии жизненного цикла «Анализ требований». И на следующих этапах проекта требования могут изменяться, появляться новые требования и исключаться существующие.
4. Для сохранения целостности, точности и актуальности требований должен выполняться процесс управления требованиями.
Вопросы для самоконтроля
1. Как определить понятие «требование»?
2. Какие требования и почему имеют самый высокий уровень?
3. Кто определяет функциональные требования?
4. Какие требования и почему наиболее важны для пользователей?
5. Какие требования и почему наиболее важны для разработчиков?
6. Чем определяются типы внешних требований, которые должны быть определены в спецификации?
7. Какими основными свойствами должны обладать требования?
8. Какие из этих свойств взаимосвязаны?
Определение образа и границ проекта
Анализ предметной области
Одна из первых задач, с решением которых сталкивается разработчик программной системы – это изучение, осмысление и анализ предметной области. Дело в том, что предметная область сильно влияет на все аспекты проекта: требования к системе, взаимодействие с пользователем, модель хранения данных, реализацию и т.д.
Анализ предметной области, позволяет выделить ее сущности, определить первоначальные требования к функциональности и определить границы проекта. Модель предметной области должна быть документирована, храниться и поддерживаться в актуальном состоянии до этапа реализации.
Для управления обсуждением области действия проекта можно использовать методику «будет – не будет». В простейшем случае – это список с двумя столбцами, в одном из которых записывается, что проект будет делать, а во втором – что не входит в проект. Такой список, формируется заинтересованными лицами при рассмотрении каждой бизнес-цели проекта, используя любую технику, например метод «мозгового штурма». Полученные характеристики позволяют четко определить границы проекта и довольно просто преобразуются в предположения, которые фиксируются в документе.
Функциональная область действия определяет услуги, предоставляемые системой, и вначале до конца неизвестны. В определении услуг системы может помочь список «Действующее лицо/Цель», в котором перечислены все цели пользователя, поддерживаемые системой. При его разработке в первую графу вписываются имена основных действующих лиц, т.е. тех, кто имеет цели, во вторую графу – цель каждого действующего лица, а в третью – приоритет или предположение о том, в какую версию войдет эта услуга.
Для определения основных функций продукта можно использовать, например, краткое описание варианта использования. Описание каждой функции можно представить также в виде списка, состоящего из трех граф: действующее лицо, цель и краткое описание варианта использования.
Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.
Анализ осуществимости
Разработка новых программных систем должен начинаться с анализа осуществимости. На основании анализа предметной области, общего описания системы и ее назначения необходимо принять решение о продолжении или завершении проекта. Для этого необходимо ответить на следующие вопросы.
1. Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?
2. Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?
3. Можно ли объединить систему с другими уже эксплуатируемыми системами?
Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,
· что произойдет с организацией, если система не будет введена в эксплуатацию;
· как система будет способствовать целям бизнеса;
· какие текущие проблемы поможет решить система и т.д.
После получения и обработки информации готовится отчет, в котором должны быть даны рекомендации относительно продолжения разработки системы.