Характеристики качества спецификации

Рассмотрим характеристики качества, предъявляемые к документу спецификация требований:

· полнота, согласованность,

· способность к модификации

· трассируемость.

Полнота и согласованность

Спецификация должна быть полной, т.е. все требования и необходимые данные должны быть документированы в спецификации. Требования не должны конфликтовать друг с другом, а также с требованиями пользователей и бизнес-требованиями. Конфликты должны быть устранены до начала процесса проектирования. Для уменьшения времени согласование рекомендуется хранить сведения об авторах требований.

Способность к модификации

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

Трассируемость

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

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

4. Управление требованиями

4.1. Причины изменений требований

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

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

· понимание пользователями возможностей системы, решаемых ею задач, может измениться;

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

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

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

С точки зрения разработки требования можно разделить на два класса:

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

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

Управление изменениями

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

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

1. Все изменения должны вноситься в соответствии с документированным и утвержденным процессом. Неофициальные запросы на изменение не рассматриваются. Запрос на изменение не гарантирует его выполнение. Текст запроса не должен изменяться или удаляться.

2. Для каждого изменения должен выполняться анализ его влияния. Обоснование утверждения или отклонения запроса на изменение должно быть документировано.

3. Реализовывать неутвержденные изменения запрещено.

Диаграмма переходов состояний для типового процесса внесения изменений в спецификацию требований приведена на рис. 7.2.

Рис. 7.2

Процесс инициируется запросом на внесение изменения, или предложением об изменении, оформленным в соответствии с утвержденными правилами и поступивший по официальным каналам. Если запрос не содержит требования, то процесс переходит в состояние «Разработка требования», в котором аналитик и инициатор изменения формируют требование. Полученное требование анализируется для определения ожидаемого от него эффекта и определения стоимости внесения изменения в спецификацию требований и в структуру и код системы. Принимается решение об одобрении или отклонении изменения. В случае положительного решения оформляется документ, содержащий решение об изменении и изменение (например, извещение об изменении, или ИИ), после чего вносится изменение в спецификацию и систему.

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

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