Дополнительно / Булуй Ю. И. Классификация требований к программному обеспечению и ее представление в стандартах и методологиях
.pdf
Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
Булуй Ю. И. Независимый консультант
Yury.Buluy@gmail.com
и
СМ-Консалт http://www.cmcons.com/
Содержание
SWEBOK
ГОСТ 34 |
К. Вигерс |
RUP |
IEEE 830
Что такое «требование» ?
• Условие или возможность требуемая пользователем для решения задач или
• Условие или возможность требуемая пользователем для решения задач или достижения целей.
достижения целей.
• Условие или возможность, которые должны удовлетворяться
• Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующих документов.
или др. регулирующих документов.
• Документальная репрезентация условий или возможностей, перечисленных в
• Документальная репрезентация условий или возможностей, перечисленных в пред. пунктах.
пред. пунктах.
«Требования это спецификация того что должно быть получено. Требования «Требования это спецификация того что должно быть получено. Требования описывают поведение системы или атрибуты и свойства системы. Требования могут описывают поведение системы или атрибуты и свойства системы. Требования могут являться и ограничениями на процесс разработки системы» являться и ограничениями на процесс разработки системы»
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» и атрибутами (свойствами) требований.
–Многие «критерии» предлагаемой группировки требований по сути – группировка по значению атрибута.