Главная | Обратная связь | Поможем написать вашу работу!

Постоянные и изменяемые требования

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

Рис. 6.14. Эволюция требований

С точки зрения разработки требования можно разделить на два класса.

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

2. Изменяемые требования. Эти требования отображают изменения, сделанные во время разработки системы или после ввода ее в эксплуатацию.

В работе [157] предложено классифицировать изменяемые требования по пяти классам. Но я считаю, что из этих классов два тесно связаны, поэтому предлагаю классификацию, показанную в табл. 6.1.

Таблица 6.1. Классификация изменяемых требований

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

Планирование управления требованиями

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

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

2. Управление процессом внесения изменений. Это ряд операций, которые оценивают воздействие на систему вносимых изменений, а также стоимость изменений. Более подробно этот вопрос рассматривается в следующем разделе.

3. Стратегия оперативного контроля. Определяет отношения между требованиями, а также между требованиями и проектированием системы.

4. Поддержка CASE-средств. Управление требованиями предполагает обработку большого объема информации о требованиях. В этом процессе могут использоваться разнообразные инструментальные средства, например электронные таблицы или простые системы баз данных.

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

Существует три типа информации, используемой в оперативном контроле.

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

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

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

Информация для оперативного контроля часто представляется в виде специальных матриц, которые связывают требования с лицами, предложившими эти условия, требования между собой и требования с системными модулями. Если матрица оперативного контроля связывает требования между собой, то каждое требование представлено в матрице как строкой, так и столбцом. Тогда, если между требованиями существует зависимость, это указывается в ячейках на пересечении строк и столбцов, соответствующих этим требованиям. Пример простой матрицы зависимостей между требованиями показан в табл. 6.2. Символ U (от use – использование) на пересечении строки и столбца показывает, что требование в строке использует средства, определенные в требованиях, представленных в столбце. Символ R (от relation – связь, зависимость) означает, что существует некоторая взаимосвязь между требованиями. Например, оба требования определяют один и тот же системный модуль.

Таблица 6.2. Матрица оперативного контроля

Требования	1.1	1.2	1.3	2.1	2.2	2.3	3.1	3.2
1.1		U	R			U		U
1.2			U			R
1.3	R			R				U
2.1			R		U			U
2.2								U
2.3		R		U
3.1								R
3.2							R

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

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

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

2. Управление изменениями требований. Процесс управления изменениями (рис. 6.15) упрощается, если есть эффективные средства поддержки.

3. Управление оперативным контролем. Как отмечалось выше, средства поддержки оперативного контроля позволяют обнаруживать взаимосвязанные требования.

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

⇐ Предыдущая 43 44 45 46 474849 50 51 52 Следующая ⇒