Ясность

Полнота

СВОЙСТВА ТРЕБОВАНИЙ

СПОСОБЫ ПОВЫШЕНИЯ КАЧЕСТВА ТРЕБОВАНИЙ

ЛЕКЦИЯ 11

Документирование требований в MSF

В начале фазы проектирования проектная группа работает с проектными требованиями. Они подразделяются на:

бизнес-требования,

требования к эксплуатации,

системные требования,

требования пользователя.

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

инструкцией команде разработчиков о том, что они должны будут создать;

основой для оценки объема работ;

четкое соглашение с Заказчиком о том, что должно быть сделано;

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

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

Типовой пример оформления требования к программе электронной почты - "Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов".

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

· полнота,

· ясность,

· корректность,

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

· верифицируемость,

· необходимость,

· полезность при эксплуатации,

· осуществимость,

· модифицируемость,

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

· упорядоченность по важности и стабильности,

· наличие количественной метрики.

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

Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.

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

Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.

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

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

Корректность и согласованность (непротиворечивость)

Корректность - одно из важнейших свойств требований. Оно вводится через точность описания функциональности. В этом смысле корректность в определенной степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит - как минимум одно из них некорректно. В иерархии требований можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования - требованиям пользователя.

Верифицируемость (пригодность к проверке)

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