лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 21 из 62

Спецификация нефункциональных требований

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

Атрибуты требований

Описания требований должны быть операбельны. Для этого все требования должны учитываться в той или иной учетной системе, будь то электронная таблица MS Excel, специализированная база данных, либо интегрированная среда управления изменениями. При регистрации требования оно проходит классификацию в соответствии с определенной системой признаков. Основные признаки (атрибуты) требований были рассмотрены в "Понятие требования. Классификации требований" . Кроме того, для оперативного управления требованиями бывает полезно назначить им такие свойства, как проект, ответственное лицо, статус, риск, степень законченности и т.п. В RUP для управления атрибутами требований предусмотрен артефакт "Атрибуты требований".

Артефакт "Атрибуты требований", предлагаемый RUP, представляет собой репозиторий текстов требований, их атрибутов и трассируемости.

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

Трассируемость описывается в виде дерева, показывающего в графическом виде входящие и (или) исходящие связи трассируемости (см. "Введение в управление требованиями" ).

Какие модели использовать

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

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

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

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

На сегодня в арсенале аналитика существуют десятки методик, языков, визуальных представлений, позволяющих моделировать требования к системе. При создании информационных систем стандартом де-факто является универсальный язык моделирования, UML [9.1,9.2]. Некоторые другие нотации были упомянуты в "Контекст задачи анализа требований" .

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

Как определить целесообразность использования тех или иных приемов, методик, языков моделирования при анализе требований? Здесь можно предложить три практические рекомендации.

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

Во-вторых, анализ требований должен находить ответ на то, ЧТО делает система, абстрагируясь от деталей реализации, т.е. того, КАК она это делает. Поэтому, допустим, диаграмму взаимодействия объектов, реализующих тот или иной вариант использования, можно рассматривать скорее, как иллюстрацию внутреннего устройства системы, полезную для программиста, чем модель для заказчика.

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