Нефункциональные требования к процессу
Нефункциональные требования к процессу зависят от политики и организационных процедур заказчика и разработчика. Они определяют ограничения, связанные с использованием определенных технологий и стандартов разработки, ограничения реализации, например, использования определенного языка программирования и методов проектирования, требования к документации, срокам изготовления программного продукта и т.д.
Внешние нефункциональные требования
Внешние нефункциональные требования учитывают факторы, внешние по отношению к системе и процессу ее разработки. Они определяют взаимодействие проектируемой системы с другими системами, требования по квалификации персонала, юридические требования, логистические требования, требования среды, этические, экологические и т.п. требования.
Свойства требований
Требования должны удовлетворять определенным характеристикам качества. Основные характеристики – это полнота, корректность, необходимость, осуществимость, приоритет, недвусмысленность, непротиворечивость (согласованность), проверяемость и прослеживаемость (см. рис. 1.1).
Рис. 1.1
Полнота и корректность
Требование должно полно и точно описывать функцию, которую необходимо реализовать в продукте, содержать всю необходимую для разработчиков информацию. Контроль над корректностью требований возлагается на пользователей, т.к. только требование, согласующееся с источником (пожеланиями пользователей) считается корректным.
Необходимость и осуществимость
Каждое требование должно отражать функциональность или ограничение, которая действительно необходима для пользователя или для удовлетворения внешних требований. Должна существовать возможность реализации каждого требования в ограничениях проекта.
Приоритет
Для реализации в определенной версии продукта каждому функциональному требованию или характеристике должен быть назначен приоритет. Это позволит упростить управление проектом при учете ограничений времени, бюджета и постоянного изменения требований.
Недвусмысленность и непротиворечивость
Недвусмысленность требований предполагает, что все читатели требований интерпретируют их одинаково. Для этого требования должны быть написаны просто, кратко и точно. Не должно быть конфликтующих между собой требований.
Проверяемость и прослеживаемость.
Должна существовать возможность проверить требование после реализации, тестировать требование. Требование, которое невозможно протестировать не имеют большой ценности. Для контроля требования (от момента принятия до реализации) требование должно быть прослеживаемым.
Особенности разработки требований к программным системам
Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов (см. рис. 1.2).
Рис. 1.2
Анализ предметной области.
Позволяет выделить сущности предметной области, определить первоначальные требования к функциональности и определить границы проекта.
Анализ осуществимости. Должен выполняться для новых программных систем. На основании анализа предметной области, общего описания системы и ее назначения принимается решение о продолжении или завершении проекта.
Формирование и анализ требований. Взаимодействуя с пользователями, обсуждая и анализируя с ними задачи, возлагаемые на систему, разрабатывая модели и прототипы, разработчики формулируют пользовательские требования.
Документирование требований. Сформированные на предыдущем этапе пользовательские требования должны быть документированы. При этом нужно учесть, что основными читателями этого документа будут пользователи, поэтому основными требованиями к нему будут ясность и понятность.
Детализация требований. Разработчики детализируют требования пользователей, формируя более точные подробные системные требования.
Согласование и утверждение требований. На этом этапе пользовательские и системные требования должны быть оформлены в виде единого документа, содержащего все функциональные и нефункциональные требования. Такой документ, обычно, называется спецификацией требований.
К особенностям разработки требований относятся:
Сложность процесса.
Итеративность процесса.
Процесс не заканчивается на стадии жизненного цикла «Анализ требований». И на следующих этапах проекта требования могут изменяться, появляться новые требования и исключаться существующие.
Для сохранения целостности, точности и актуальности требований должен выполняться процесс управления требованиями.