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

ВАЖНОСТЬ КАЧЕСТВЕННЫХ ТРЕБОВАНИЙ

Есть множество формальных и эмпирических свидетельств неадекватности типичных спецификаций. На практике слишком многие требования оказываются неоднозначными, неполными, неосуществимыми, не поддающимися проверке, плохо упорядоченными по приоритетам и взаимно противоречивыми [2]. Фактически, основной причиной неудач при реализации многих проектов является низкое качество отдельных требований и описывающих их спецификаций [6]. Очевидно, что существующие подходы к разработке и проверке требований непригодны для выявления и устранения дефектов в таких спецификациях.

НЕДОСТАТКИ СЛОЖИВШИХСЯ ПОДХОДОВ

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

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

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

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

Например, полная неспособность групп разработки требований справляться с выявлением критически важных архитектурных факторов стала одной из основных причин появления Quality Attribute Workshop (QAW). Этот метод, предложенный Институтом разработки программного обеспечения (Software Engineering Institute, SEI), предназначен для идентификации и документирования качественных требований [5]. По той же причине первыми шагами метода SEI ATAM являются проверки, позволяющие установить наличие качественных факторов для оценки архитектуры [1]. Подобные подходы достаточны для оценки архитектуры, но не заменяют процесса разработки требований и не предоставляют надлежащих качественных требований другим участникам (например, разработчикам, программистам или тестировщикам).

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

Выявление требований

  • Учтены ли мнения всех заинтересованных лиц по поводу качественных требований? - Опрошены ли самые влиятельные лица? - Все ли категории заинтересованных лиц участвовали в опросе? - Являются ли участники опроса достаточно репрезентативной группой, представляющей интересы всех заинтересованных лиц? - Достаточно ли велико число опрошенных для статистической значимости результатов?
  • Учтены ли при разработке качественных требований все относящиеся к делу законы, инструкции и стандарты?

Анализ требований

В отличие от функциональных требований, для выявления которых достаточно лишь аналитического метода (например, моделирования сценариев), раскрыть все качественные требования с помощью одного метода не удается. Скажем, такие методы оценки рисков, как анализ дерева ошибок (fault tree analysis, FTA), анализ дерева событий (event tree analysis, ETA) или анализ характера и последствий отказов (failure modes and effects analysis, FMEA), вполне пригодны для составления требований к обеспечению безопасности [4], но непригодны для выявления требований к надежности и производительности. Нужно определить следующее.

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

Типы качественных требований

  • Модель качества. Использовалась ли подходящая модель качества для выявления типов качественных требований?
  • Стандарт. Использовалась ли стандартная модель качества (соответствующая международным, национальным, военным или отраслевым стандартам) или разработанная специально для данного случая?
  • Полнота. Была ли модель качества достаточно полной для охвата всех относящихся к делу типов качественных требований?
  • Факторы качества. Были ли требования к качеству основаны лишь на качественных факторах (например, производительности) или для идентификации подтипов качественных требований использовались качественные субфакторы (такие как устойчивость синхронизации данных, время оклика, предсказуемость или пропускная способность).

Структура качественных требований

Требования к качеству конкретной системы обуславливаются моделью качества (рис. 1), собственно, и определяющей для этой системы представление о качестве. Каждое качественное требование предписывает, что разрабатываемая система должна соответствовать заданному значению конкретного качественного фактора или субфактора, определенного моделью качества. Таким образом, все требования к качеству должны иметь сходные форму и содержание вне зависимости от качественных факторов, к которым они относятся. Как показано на рис. 2, каждое требование должно состоять из трех частей.

  • Критерий качества. Центральной частью каждого качественного требования является критерий качества, в соответствии с которым система должна демонстрировать один из аспектов своего качества. Конкретный критерий зависит от системы, но он описывает обобщенный тип качества — как определено в ассоциированной модели качества.
  • Условия. Каждое требование к качеству, как правило, содержит соответствующий набор условий, определяющих, при каких обстоятельствах должен соблюдаться критерий качества. Если условия явно не указаны, обычно подразумевается, что критерий качества должен выполняться всегда. Однако этот критерий может быть неуместен при запуске или остановке системы либо в некоторых вырожденных режимах работы. Возможно, он пригоден лишь для некоторых рабочих режимов (например, рулежка, взлет, набор высоты, полет по маршруту, снижение и посадка воздушного судна). Многие качественные требования лишены полноты, поскольку не содержат соответствующих условий применимости.
  • Пороговое значение. Все требования к качеству нацелены на достижение определенного значения некоторого качественного фактора, поэтому составной частью требования должно быть пороговое значение на избранной шкале измерения. Без такого порога требование не устанавливает критериев приемлемого качества и превращается в недостижимую цель.

Оцените форму и содержание каждого качественного требования по следующим направлениям.

  • Критерий качества. Содержит ли требование хорошо определенный, относящийся к делу, зависящий от системы критерий качества, который адекватно описывает отдельный аспект системы в терминах соответствующего качественного фактора или одного из его субфакторов?
  • Цели как требования. Не является ли требование простым пожеланием того, чтобы система характеризовалась тем или иным качественным фактором или субфактором (например, «система должна быть безопасной»)? Такие пожелания описывают не требования, поддающиеся проверке, а недостижимые цели.
  • Шкала измерения и пороговое значение. Связан ли с требованием порог, точно устанавливающий, каких значений качественного фактора или субфактора необходимо достичь? Хорошо ли определен порог в терминах выбранной шкалы измерения? Соответствует ли измерительная шкала критерию качества?
  • Условия. Содержит ли требование условия, при которых должен выполняться критерий качества? Если с критерием не связаны какие-либо условия, означает ли это, что он должен выполняться всегда (например, при запуске и остановке системы, в вырожденном режиме)? Все ли режимы и состояния системы были рассмотрены при определении области применения качественного требования?

Качество самих требований

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

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

Ввести в практику

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

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

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

ЛИТЕРАТУРА
  1. Paul Clements, Rick Kazman, Mark Klein. Evaluating Software Architectures: Methods and Case Studies. Addison Wesley, 2002.
  2. Donald Firesmith, Specifying Good Requirements. Journal of Object Technology, Vol. 2, no. 4, July-August 2003; www.jot.fm/issues/issue_2003_07/column7.
  3. Donald Firesmith, Using Quality Models to Engineer Quality Requirements. Journal of Object Technology, vol. 2, no. 5, September-October 2003; www.jot.fm/issues/issue_2003_09/column6.
  4. Nancy Leveson, Safeware: System Safety and Computers. Addison Wesley, 1995.
  5. Software Engineering Institute Quality Attribute Workshop. 2005; www.sei.cmu.edu/architecture/products_services/ qaw.html.
  6. The Standish Group International. The CHAOS Report, 1994; www1.standishgroup.com/sample_research/ chaos_1994_1.php.

Дональд Файерсмит (dgf@sei.cmu.edu) — старший технический сотрудник Института разработки программного обеспечения (Software Engineering Institute, SEI). В 1984 году Файерсмит начал заниматься объектными технологиями и написал пять книг на эту тему. За последние четыре года он разработал самый большой в мире (более 1100 Web-страниц) открытый сайт (www.opfro.org), посвященный многократному использованию инженерных компонентов.

Translated from «Quality Requirements Checklist» by Donald G. Firesmith in Journal of Object Technology (JOT), vol.4, No 9, pages 31-38. Translated into Russian for Open Systems Journal under special permission of the original publisher. Copyright JOT November-December 2005. Original article at http://www.jot.fm/issues/issue_2005_11/column4.