Классификация требований к программному обеспечению и ее представление в стандартах и методологиях

Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.

Булуй Ю. И. Независимый консультант

[e-mail]

и

СМ-Консалт http://www.cmcons.com/

Содержание

SWEBOK

ГОСТ 34

К. Вигерс

RUP

IEEE 830

IEEE Std 610.12, “IEEE Standard Glossary of Software Engineering Terminology” IEEE Std 610.12, “IEEE Standard Glossary of Software Engineering Terminology”

Что такое «требование» ?

• Условие или возможность требуемая пользователем для решения задач или

• Условие или возможность требуемая пользователем для решения задач или достижения целей.

достижения целей.

• Условие или возможность, которые должны удовлетворяться

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

или др. регулирующих документов.

• Документальная репрезентация условий или возможностей, перечисленных в

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

пред. пунктах.

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

Ian Sommerville & Pete Sawyer

Ian Sommerville & Pete Sawyer

«Условие или возможность которой должна удовлетворять система» (A requirement is «Условие или возможность которой должна удовлетворять система» (A requirement is

defined as “a condition or capability to which a system must conform”).. defined as “a condition or capability to which a system must conform”)

Rational Unified Process, Version 2003.06.13

Rational Unified Process, Version 2003.06.13

Дискретность требований

Бесформенный набор	Отдельные (дискретные)
	утверждения, составляющие
предложений	целостную картину

Дискретность вытекает в т.ч. и из «характеристик хороших требований» и свойства трассируемости требований.

Предпосылки

•При большом количестве требований в конкретном

проекте навигация и понимание сути проекта, без организации информации каким-либо образом,

становится затруднительной.

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

•Требование само по себе может иметь набор свойств

(атрибутов).

•Требования могут иметь сложную структуру отношений и связей (например иерархическую).

Знание начинается с … классификации!

•Классификация – система или способ группировки

субъектов наблюдения или исследования в

соответствии с их общими признаками

(ru.wikipedia.org/wiki/Классификация)

•Природа требований позволяет их классифицировать,

остается только определить классификационные

признаки.

•Наличие классификации позволяет использовать

общие шаблоны (паттерны?) для работы с

требованиями (общие наборы атрибутов, правила отношений и связей, …)

Требования в SWEBOK

Ключевые темы

SWEBOK определяет структуру области знаний Программные

требований (статика) и указывает на основные виды

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

требованиями (динамика)

Классификация требований в SWEBOK

•Требования к продукту и процессу – параметры относящиеся к продукту или процессу его создания.

•Функциональные и нефункциональные требования:

–Функциональные описывают функции которые выполняет ПО

–Нефункциональные требования накладывают определенные ограничения

•Независимые свойства – требования которые не

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

•Системные или программные требования. Относятся

ксистеме в целом или к программной составляющей.

«Dimensions»

•Отношение требования к функциональным или

нефункциональным;

•Является ли требование производным от более

высокоуровневых требований, является ли

«независимым свойством» или было непосредственно получено от заинтересованных

лиц;

•Требования к продукту или к процессу;

•Приоритет требований;

•По области действия (глобальные, на компонент, …);

•По степени стабильности;

Выводы по SWEBOK

•SWEBOK не описывает в «чистом виде» подходы к

классификации требований как таковой, а в большей

степени описывает возможности по группировке

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

•SWEBOK отмечет, что имеется явное пересечение между описанными в нем «dimensions» и атрибутами (свойствами) требований.

–Многие «критерии» предлагаемой группировки требований по сути – группировка по значению атрибута.