1-software_engineering_requirements (1133541), страница 9
Текст из файла (страница 9)
Вопределенном смысле, можно и необходимо говорить о том или ином уровне атомарноститребований (что не исключает связей между требованиями), представляемой такой метафорой.7.4 Трассировка требований (Requirements Tracing)Трассировка требований обеспечивает связь между требованиями и отслеживание источниковтребований. Трассировка является фундаментальной основой проведения анализа влияния (impactanalysis) при изменении требований, помогая предсказывать эффект от внесения таких изменений.Трассировка предполагает направленную связь (представляется в виде сложного направленногоациклического графа) между требованиями, то есть зависимости.Требования (B) обладают обратной зависимостью (то есть вторичны) по отношению к требованиям(A) и заинтересованным лицам, которые являются источником либо образуют причину появлениярассматриваемых требований (B).
И, наоборот, требования (A) трассируются напрямую к темтребованиям (B) и элементам дизайна (например, модели или, в общем случае, кода, запросов наизменения и т.п.), которые порождаются или удовлетворяют требованиям (A).7.5 Измерение требований (Measuring Requirements)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru20Основы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.С практической точки зрения, обычно полезно иметь нечто, позволяющее определить “объем”требований для заданного (создаваемого) программного продукта.
Это число полезно дляисследования “масштабов” изменений в требованиях, оценки стоимостных характеристик (costestimation) разработки и поддержки программной системы, опосредовано – оценки продуктивностиразработки и эффективности поддержки на этапах реализации требований и внесения изменений ит.п.Измерение объема функциональности (Functional Size Measurement, FSM) техника такого родачисленной оценки, определена на концептуальном уровне в стандарте IEEE 14143.1. СтандартыISO/IEC и другие источники описывают частные методы FSM (например, модель COCOMO II дляоценки стоимости, например, может использоваться в тесной связи с методами функциональныхточек – functional points для оценки масштабов функциональности, то есть требований,предъявляемых заданной программной системе).Дополнительная информация по стандартам и подходам в оценке масштабов представлена вобласти знаний “Процесс программной инженерии” (Software Engineering Process).В дополнение к практическим соображениям, представленным в SWEBOK, на фоне общейтенденции разработки моделей <оценки> зрелости, стоит отметить, что существуют определенныеработы и по созданию различных моделей зрелости требований.
Например, наиболее популярнаямодель зрелости в индустрии программного обеспечения – CMMI включает разный объем исодержание работ по определению и управлению требованиями для уровней зрелости 2 и 3.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru21.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
