Рассмотрим характеристики качества, предъявляемые к документу спецификация требований:
· полнота, согласованность,
· способность к модификации
· трассируемость.
Полнота и согласованность
Спецификация должна быть полной, т.е. все требования и необходимые данные должны быть документированы в спецификации. Требования не должны конфликтовать друг с другом, а также с требованиями пользователей и бизнес-требованиями. Конфликты должны быть устранены до начала процесса проектирования. Для уменьшения времени согласование рекомендуется хранить сведения об авторах требований.
Способность к модификации
Во время выполнения проекта требования изменяются. Появляются новые требования, модифицируются существующие. Спецификация требований должна обеспечивать возможность простого внесения изменений, сохранять историю изменений. Для этого каждое требование должны быть уникально идентифицировано, и встречаться в спецификации один раз.
Трассируемость
Возможности анализа требований и их реализации во многом определяются трассируемостью спецификации. Трассируемость должна позволять выполнять прослеживание как вперед, от требования до реализующего его кода, так и назад, от кода к требованию.
Спецификация считается трассируемой, если в ней явно прослеживается происхождение каждого требования и если она позволяет быстро найти любое требование для его использования в разработке.
6.1.2. Аттестация требований
Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности:
· экспертиза спецификации,
· прототипирование,
· автоматизированный анализ.
Экспертиза спецификации
Экспертиза спецификации [4, 7] требований позволяет эффективно выявить неполные и некорректные требования, требования неясные или неподдающиеся проверке, несогласованные и не тестируемые требования.
Неофициальные экспертизы проводится во время разработки спецификации, знакомства с продуктом и не носят регулярный характер. Такие просмотры могут проводиться в виде «проверки за столом», когда автор просит коллегу исследовать спецификацию, или коллективной проверки – параллельного исследования спецификации несколькими людьми.
Официальная проверка – это документированный процесс, завершением которого является отчет, содержащий мнения рецензентов о приемлемости спецификации.
Рис. 6.1
Процесс экспертизы начинается с ее планирования (см. рис. 6.1). Председатель (координатор) совместно с автором спецификации определяют число и состав участников, материалы, которые должны получить эксперты до первого совещания, количество совещаний, темп проведения экспертизы.
При подготовке к встрече эксперты анализируют спецификацию с целью определения возможных дефектов, используя списки типичных дефектов (см. рис.6.2). Этот этап очень важен, т.к. большинство дефектов определяется на нем.
Рис. 6.2
На совещании автор знакомит экспертов с каждым требованием спецификации, перефразируя их своими словами. Цель совещания выявить как можно больше ошибок. При обсуждении дефектов и других проблем они заносятся в протокол. В заключение совещания принимается решение: принять спецификацию без изменений, с незначительными изменениями или значительно ее переработать.
После выявления дефектов, автор спецификации перерабатывает ее с учетом сделанных замечаний.
На этапе обработки результатов экспертизы председатель совместно с автором должны убедиться, что все проблемы разрешены, а ошибки исправлены. На основе проведенного анализа координатор принимает решение, удовлетворяет ли спецификация принятым выходным критериям. Стандартными выходными критериями являются: все возникшие вопросы сняты, все изменения внесены корректно, все проблемы разрешены.
Для организации помощи экспертам в проведении экспертизы спецификации требований разрабатываются контрольные списки дефектов [4]. На рис. 6.2. приведен список дефектов для варианта использования. Список содержит вопросы, на которые должен ответить эксперт при проведении анализа. Списки могут изменяться, сообразуясь с требованиями проекта. Если список велик, то его можно разбить на подсписки, которые эксперты будут использовать при подготовке.
Проблемы при просмотре требований
Большой объем документации. Размеры спецификации определяются объемом проекта. Для больших проектов спецификация может представлять собой многостраничный документ, экспертиза которого занимает большой промежуток времени. Для его сокращения экспертизу можно проводить по мере разработки спецификации, подвергая тщательному просмотру только области повышенного риска.
Большая команда экспертов. Список желающих участвовать в просмотре спецификации может быть достаточно длинным. При большом числе участников трудно составить график совещаний, на совещании много посторонних разговоров, экспертам трудно прийти к согласию по каждому вопросу и принять решение. Экспертиза – это работа с людьми, поэтому при ее планировании председатель должен убедиться, что каждый участник понимает свою задачу – выявлять дефекты, а не отстаивать свою позицию. Можно собрать несколько небольших групп экспертов и провести параллельный просмотр спецификации. Практика показывает, что это приводит к лучшим результатам.
Прототипирование
При аттестации требований прототип демонстрируется пользователям, которые, экспериментируя с ним, могут убедиться в том, что он отвечает их потребностям.
Автоматизированный анализ
Использование автоматизированных средств возможно, если требования представлены в виде структурных или формальных системных моделей. Для автоматизированной проверки непротиворечивости требований строится база данных требований, а соответствующий анализатор требований готовит отчет обо всех обнаруженных противоречиях.
6.5. Тестирование требований
Экспертиза спецификации требований – это просмотр документа, для которого не требуется компьютер. Тестирование – процесс динамический, который выполняется на компьютере, и поэтому может быть применен только для функциональных требований [9].
Для того, чтобы представить себе, как будет в определенных условиях вести себя система, нужно на основе требований, записанных в спецификации, разработать варианты тестирования. Варианты тестирования – это еще один способ анализа и выявления дефектов требований. Варианты тестирования, разрабатываемые совместно разработчиком и пользователем, позволяют не только выработать общее понимание работы продукта, но и будут незаменимы для оценки моделей, прототипов и требований. Варианты должны охватывать не только поведение продукта в нормальном режиме, но и все исключительные ситуации, определенные в ходе анализа.
Исходной информацией для функциональных требований и вариантов тестирования являются пользовательские требования, поэтому их разработка должна вестись параллельно. Разработчик пишет функциональные требования, а тестировщик – варианты тестирования для них. По мере проектирования и реализации приложения варианты тестирования также будут наполняться конкретным содержанием. Нужно заметить, что разработку и тестирование (созидание и разрушение) лучше поручить разным исполнителям.
Планирование процесса тестирования должно производиться параллельно с проектированием. Виды планов, разрабатываемых на разных этапах проектирования, хорошо иллюстрируются на примере V-образной модели жизненного цикла (см. рис. 6.3).
Рис. 6.3
Пунктирными линиями здесь соединены этапы, которые нужно рассматривать параллельно [10]. Остановимся на первых двух связях.
Требования к проекту и планирование
Здесь определяются требования, и производится планирование ресурсов. Этот этап связан с этапами эксплуатации и сопровождения, предваряемые приемочными испытаниями. Приемочные испытания позволяют пользователю протестировать функциональные возможности системы на их соответствие с исходными требованиями, после чего продукт принимается в эксплуатацию. Планирование приемочных испытаний проводится на фазе разработки требований, а разработка тестов должна выполняться пользователями.
Требования к продукту и анализ спецификации
На этом этапе происходит планирование системного тестирования, которое позволяет проверить функционирование системы в условиях реального окружения в соответствии со спецификацией требований. Основной критерий при проведении системного тестирования – критерий приемлемости, который определяет степень соответствия продукта задокументированным требованиям. Разработка тестов для системного тестирования также должна выполняться пользователями.
Тесты приемлемости отслеживают, в основном, нормальные линии поведения вариантов использования. При оценке приемлемости основные группы пользователей должны обращать внимание на наиболее общие и важные варианты использования. Для минимизации трудоемкости тестирования, в котором участвуют пользователи, нужно использовать средства автоматизации.
Вопросы для самоконтроля
1.Какие характеристики определяют качество спецификации?
2.Как определяется полнота и согласованность требований?
3.Почему важны способность к модификации спецификации и трассируемость требований?
4.Что такое экспертиза спецификации? Почему этот процесс должен быть документирован?
5.Каковы основные роли участников экспертизы?
6.Чем тестирование требований отличается от аттестации?
7.Что определяет критерий приемлемости?
8.Кто должен разрабатывать тесты приемочных испытаний?
7. Управление требованиями
Изучив тему, Вы будете знать:
§ почему изменяются требования, виды изменяемых требований;
§ принципы управления требованиями, изменениями и версиями;
§ связанные с требованиями риски.
При освоении темы необходимо акцентировать внимание:
§ на методах и средствах управления версиями спецификации и отдельных требований;
§ на методах анализа влияния и стоимости внесения изменения;
§ на управлении статусом требований;
§ на анализе рисков, связанных с требованиями.
7.1. Причины изменений требований
На этапе анализа разрабатываются пользовательские и системные требования к программной системе, которые оформляются в виде единого документа – спецификации требований, – являющегося формальным соглашением заказчика с разработчиком системы.
Практика показывает, что требования к разрабатываемой программной системе постоянно изменяются. Это обусловлено тем, что проектирование системы довольно длительный процесс, во время которого:
· понимание пользователями возможностей системы, решаемых ею задач, может измениться;
· происходят изменения в деловой среде, техническом, программном (и т.д.) обеспечении системы, которые должны быть учтены;
· понимание разработчиками поставленных перед ними задач меняется.
Кроме этого достижение компромисса между требованиями и приоритетами разных группы пользователей (часто противоречивыми) – это длительный процесс, который может завершиться только на последних стадиях проекта.
С точки зрения разработки требования можно разделить на два класса:
1.Постоянные требования – это достаточно стабильные требования, которые определяются предметной областью и деятельностью организации, в которой будет эксплуатироваться система.
2.Изменяемые требования отображают изменения, происходящие во время разработки и эксплуатации системы. На рис. 7.1 приведена классификация изменяемых требований и источники их возникновения.
Рис. 7.1
Изменения в требованиях оказывают большое влияние на выполнение проекта. Введение новых или изменение существующих требований приводит к тому, что:
· увеличиваются затраты на разработку за счет, например, привлечения дополнительных специалистов или сверхурочной работы;
· для сохранения графика выполнения проекта приходится жертвовать качеством продукта или откладывать реализацию других требований.
Для исключения негативного влияния изменений требований управлению требованиями должно быть уделено достаточно большое и серьезное внимание.
7.2. Принципы управления требованиями
Под управлением требованиями понимают все действия, направленные на поддержание целостности, точности и актуальности спецификации требования в процессе проектирования: управление изменениями и версиями спецификации, контроль состояния требования и его взаимосвязи с другими требованиями и элементами системы.
К действиям по управлению требованиями относятся:
1.Определение основной (базовой) версии спецификации требований для конкретной версии продукта;
2.Анализ предлагаемых изменений требований, оценка воздействия и стоимости каждого изменения до его принятия;
3.Включение одобренных изменений при помощи определенной процедуры;
4.Согласование плана проекта с требованиями;
5.Отслеживание отдельных требований от проектирования до кода приложения и его тестирования;
6.Отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Базовая версия требований
Под базовой версией спецификации понимается спецификация требований, содержащая набор функциональных и нефункциональных требований, которые разработчики обязались реализовать в определенной версии продукта. Базовая версия проходит процесс разработки и согласования. После официальной экспертизы и утверждения базовая версия спецификации требований становится основным документом в проектировании системы и передается для управления конфигурацией. Теперь внесение изменений в базовую версию может быть осуществлено только при выполнении определенного процесса.
Процесс управления требованиями
В организации (или проекте) должны быть определены действия по управлению требованиями. Эти действия должны быть задокументированы и выполняться всеми участниками проекта. При разработке процесса нужно определить:
· методы и средства управления версиями спецификации и отдельных требований;
· процесс разработки, согласования, экспертизы и утверждения базовой версии;
· процесс присвоения, контроля и изменения статуса требования;
· процесс передачи новых требований и изменений существующих требований заинтересованным лицам;
· методы анализа влияния и стоимости внесения изменения.
Кроме этого описание процесса должно содержать определение участников проекта, ответственных за выполнение каждой конкретной задачи.
Контроль версий
Контроль версий предполагает, что каждый участник проекта должен иметь доступ к текущей версии спецификации и других документов. Каждая версия спецификации должна иметь уникальное имя и содержать историю переработки, описывающую кто, когда, по какой причине внес изменение.
Для небольшого проекта можно разработать соглашение об именовании версий и контролировать их «вручную», но наиболее надежный способ контроля версий – это использование соответствующих программных средств.
Идентификация отдельных требований
Минимальной единицей управления в спецификации требований является отдельное требование, поэтому вопрос идентификации требования достаточно важен.
Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атрибутов. Атрибутами могут быть: дата создания требования, номер текущей версии требования, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обоснование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование его состояние и статус.
Статус требования
В процессе выполнения проекта требование, обычно, изменяет свое состояние от начального («предложено»), до конечного, например, «реализовано». Статус требований позволяет оценить степень готовности проекта. В [4] рекомендуют использовать состояния требования, приведенные в табл. 7.1.
Таблица 7.1.
| Состояние | Определение |
| Предложено (proposed) | Требование запрошено авторизированным источником |
| Одобрено (approved) | Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии продукта. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики обязались его реализовать |
| Реализовано (implemented) | Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода |
| Проверено (verified) | Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается завершенным |
| Удалено (deleted) | Утвержденное требование удалено из базовой версии. Зафиксируйте причины и лицо, принявшее это решение |
| Отклонено (rejected) | Требование предложено, но не запланировано для реализации ни в одной из будущих версий. Зафиксируйте причины и лицо, принявшее это решение |
В процессе управления требованиями должны быть определены лица, которые могут изменить статус требования. Управление статусом позволяет численно определить степень готовности проекта, считая, например, что основная часть работы закончена, если все требования имеют статус «Проверено» или «Удалено».
Управление изменениями
После разработки, согласования и утверждения спецификация требований становится основным документом в проектировании системы (версии системы). Изменения в этот документ разрешается вносить только через определенный в организации (или проекте) процесс внесения изменений.
Контроль над изменениями осуществляет руководство, поэтому важно определить его политику в этом вопросе, которая должна быть доведена до всех сотрудников. Основой могут служить следующие положения.
1.Все изменения должны вноситься в соответствии с документированным и утвержденным процессом. Неофициальные запросы на изменение не рассматриваются. Запрос на изменение не гарантирует его выполнение. Текст запроса не должен изменяться или удаляться.
2.Для каждого изменения должен выполняться анализ его влияния. Обоснование утверждения или отклонения запроса на изменение должно быть документировано.
3.Реализовывать неутвержденные изменения запрещено.
Диаграмма переходов состояний для типового процесса внесения изменений в спецификацию требований приведена на рис. 7.2.
Рис. 7.2
Процесс инициируется запросом на внесение изменения, или предложением об изменении, оформленным в соответствии с утвержденными правилами и поступивший по официальным каналам. Если запрос не содержит требования, то процесс переходит в состояние «Разработка требования», в котором аналитик и инициатор изменения формируют требование. Полученное требование анализируется для определения ожидаемого от него эффекта и определения стоимости внесения изменения в спецификацию требований и в структуру и код системы. Принимается решение об одобрении или отклонении изменения. В случае положительного решения оформляется документ, содержащий решение об изменении и изменение (например, извещение об изменении, или ИИ), после чего вносится изменение в спецификацию и систему.
Формализация процесса внесения изменений позволяет обрабатывать изменения последовательно, управлять и контролировать внесение изменений в спецификацию.
Стандарты достаточно строго и точно определяют процессы оформления и внесения изменения в спецификацию (документ), но действия по анализу требования и его стоимости, принятия решения об изменении, внесение изменений в код системы – должны быть определены в организации (или проекте).
Описание процесса контроля изменений должно содержать:
1.Границы применения процесса. Должны быть перечислены те продукты или изменения, которые не принадлежат процессу.
2.Роли и ответственность. Должны быть определены члены проекта (роли), участвующие в контроле изменений и их ответственность.
3.Описание процедуры прохождения запроса на изменение.
4.Описание процедур анализа и оценки запроса на осуществимость, влияния и стоимости изменения, принятия решения и изменения состояния запроса.
Стоимость внесения изменения в требования сильно зависит от фазы жизненного цикла, на котором находится система и может быть очень велика [1, 4, 10], поэтому принятие решения об изменении – достаточно сложная и ответственная проблема. Лучшее практическое решение этой проблемы – совет по управлению изменениями [4]. Совет по управлению изменениями – это небольшая группа людей, принимающая решение о том, какие предлагаемые изменения требований, новые функции, интерфейс будут включены в продукт. Для эффективной работы совет должен иметь утвержденные структуру, полномочия и рабочие процедуры (устав).
Управление версиями
Следующая функция, направленная на поддержание целостности, точности и актуальности спецификации требования – это управление версиями спецификации.
Управление версиями требует выполнения следующих видов деятельности:
1.Определение конфигурации требований: именование отдельных требований и версий спецификации.
2.Определение состава версии спецификации.
3.Управление процессом внесения изменений.
4.Хранение истории каждой версии спецификации, содержащей сведения о внесенных изменениях.
5.Проведение аудита для обеспечения целостности имеющихся требований.
За время выполнения проекта спецификация требований изменяется путем включения новых требований и изменения (получения новых редакций, или версий) существующих требований. Управление версиями позволяет разработчикам иметь спецификацию, содержащую только те требования, которые должны быть реализованы в конкретном выпуске системы и в нужной их редакции.
Наиболее надежный способ контроля версий – это использование соответствующих программных средств.
7.5. Управление связями требований
Результатом проекта должна быть программа, которая удовлетворяет требованиям, перечисленным в спецификации. Если четко контролировать выполнение каждого требования от проекта до кода, реализующего требование, то эта цель достигнута. Возможность отображать каждое требование на соответствующие части проекта называется трассированием, или прослеживанием требований.
Трассируемость требований позволяет решить следующие задачи.
1.Продемонстрировать, что все требования проекта реализованы.
2.Снизить вероятность того, что при внесении изменений будет упущено требование, на которое оказывает влияние изменение.
3.Упростить внесение изменения на поздних фазах проектирования, а также фазе эксплуатации и сопровождения продукта.
4.Зафиксировать опыт проектирования, упростить повторное проектирование и повторное использование.
5.Упростить поиск, локализацию и исправление ошибок при тестировании.
Многие из перечисленных выгод относятся к долгосрочным выгодам, снижающим общие стоимость жизненного цикла продукта. За них нужно платить увеличением затрат на сбор и управление информации трассируемости, поэтому при принятии решения о трассировании требований нужно помнить о том, что трассирование – это сложный и трудоемкий процесс, который будет отвлекать разработчиков от проектирования.
Трассирование требований выполняется вручную, поэтому процедуры сбора, хранения и управления информацией о трассируемости должны быть документированы, и выполняться всеми разработчиками на всех этапах выполнения проекта. Если информация о трассируемости устареет, то восстановить ее будет невозможно.
Матрица трассируемости требований
Трассирование требований – это определение связей между требованием и другими артефактами проекта. Такая информация обычно представляется в виде матрицы [1, 4]. На рис. 7.3 приведен один из возможных форматов такой матрицы.
Рис. 7.3
Строки матрицы поименованы идентификаторами требований пользователя. Первый столбец содержит имена функциональных требований, с которым связано данное пользовательское требование. Этот столбец заполняется по спецификации требований. Остальные столбцы получают свои значения по мере выполнения проектирования. Можно добавить деталей трассируемости для повышения точности расположения связанных с требованием элементов проекта, но объем работы по управлению трассированием при этом возрастет.
Дополнительным достоинством матрицы является то, что по ней можно выполнять как прямую (от требования к коду и далее) трассировку, так и обратную трассировку. Кроме этого, разрешив определять несколько позиций в ячейке матрицы, мы получаем возможность фиксировать не только бинарные отношения, но и связи вида «один ко многим» или «многие ко многим». Дело в том, что одно функциональное требование, например, может проверяться несколькими вариантами тестирования, а несколько вариантов использования могут порождать множества функциональных требований, пересечение которых не пусто. Другие варианты матриц трассируемости требований можно найти в [4].
Трассируемость нефункциональных требований – более сложная проблема. Например, требования к производительности определяют выбор структур данных и алгоритмов обработки и могут быть не связаны с определенным кодом. Требования мобильности определяют инструментальные средства и не приводят к написанию какого-либо кода и т.д. Трассировка нефункциональных требований должна основываться на анализе этих требований и отдельном решении для каждого требования.
Ранее было сказано, что трассирование требований выполняется вручную. На самом деле вручную выполняется заполнение ячеек матрицы трассируемости. Поддержание матрицы в актуальном состоянии без использования средств управления требованиями возможно только для очень небольших проектов. Связано это с большими объемами информации, хранить которую в документальном виде, а также обновлять, вносить изменения, хранить и обрабатывать множество атрибутов и т.д. невозможно.
Существующие средства управления требованиями позволяют: импортировать требования из исходных документов, определять значения атрибутов, контролировать связи трассирования требований, соединять требования с элементами, хранящимися в других средствах разработки и т.д. В [4] правильно замечено, что, несмотря на большой объем функций, выполняемых этими средствами, они не являются средствами разработки требований, а значит, не могут помочь в определении заинтересованных лиц (пользователей) или выявлении и сборе требований.
7.6. Риски, связанные с требованиями
Риск отражает возможные потери при выполнении программного проекта, которые оказывают на него негативное влияние. С каждым из этапов разработки требований связаны свои риски. В [4, 6] рассматриваются вопросы управления рисками их отслеживание и контроль. Приведем основные риски, связанные с требованиями.
7.6.1. Риски этапа выявления требований
| Наименование риска | Причина возникновения | Методы уменьшения риска |
| Концепция проекта | Если лица, заинтересованные в проекте не имеют ясного мнения о том, что должен представлять собой продукт, то вероятность расползания границ системы возрастает | Разработайте документ об образе и границах продукта, который содержит бизнес-требования и используйте его при выработке решений о принятии или изменении требований |
| Время, затраченное на разработку требований | Жесткие сроки проекта заставляют разработчиков и пользователей пренебрегать разработкой требований и сразу переходить к кодированию | Собирайте статистику о времени и усилиях, затраченных на разработку требований в каждом проекте, и используйте ее для улучшения планирования следующего проекта |
| Полнота и корректность спецификации требований | Жесткие сроки проекта | Концентрируйтесь на определении пользовательских задач, используйте для определения потребностей пользователя наиболее понятные для него средства: сценарии использования, прототипы и т.п. |
| Определение нефункциональных требований | Основное внимание уделяется на функциональность продукта | Выясняйте у пользователей качественные характеристики продукта: надежность, производительность, простота использования и т.п. Документируйте эти требования и критерии их оценки в спецификации |
| Единство мнений пользователей относительно требований | Отсутствие или неполное согласование требований со всеми пользователями | Определите основных пользователей, сторонников продукта для получения нужного представительства. Удостоверьтесь, что вы полагаетесь на правильно выбранных людей, имеющих полномочия для принятия решений |
7.6.2. Риски этапа анализа и спецификации требований
| Наименование риска | Причина возникновения | Методы уменьшения риска |
| Определение приоритетов требований | Не все требования имеют приоритет и приписаны к конкретной версии продукта | Определите приоритеты всех требований, оценивайте приоритет каждого нового требования по отношению к объему оставшейся работы |
| Незнакомые технологии, методы, инструменты | Недооценка времени на обучение работе с новыми технологиями, методами, инструментами | Выделяйте достаточное время на обучение работе с новыми технологиями, методами, инструментами |
| Понимание требований | Различия в интерпретации требований пользователями и разработчиками | Используйте опытных аналитиков требований, используйте прототипы и модели, представляющие требования с различных точек зрения и позволяющие выявить неясные и неопределенные требования |
| Неоднозначная терминология | Недостаточное знакомство с предметной областью, недостаточная квалификация пользователей | Разработайте словарь определения бизнес и технических терминов. Создайте словарь данных, определяющий элементы и структуры данных. Проведите экспертизу спецификации для общего понимания ключевых терминов и концепций |
| Неутвержденные требования | Недостаток времени | Выделите время и ресурсы на совместную экспертизу требований, согласование и утверждение спецификации |
7.6.3. Риски управления требованиями
| Наименование риска | Причина возникновения | Методы уменьшения риска |
| Изменение требований | Изменение понимания пользователями и разработчиками решаемых системой задач, изменения в деловой среде, техническом, программном обеспечении | Для уменьшения расползания границ проекта используйте документ, описывающий его концепцию. Активное участи пользователей в выявлении требований, контроль качества требований уменьшают вероятность изменений требований, проектируйте легко модернизируемую систему |
| Процесс изменения требований | Не документированность процесса изменения | Разработайте, документируйте, утвердите и контролируйте процесс внесения изменений |
Вопросы для самоконтроля
1.Перечислите несколько причин изменения требований.
2.Чем отличаются постоянные и изменяемые требования?
3.Перечислите основные функции по управлению требованиями.
4.Что такое базовая версия требований?
5.Для чего используются атрибуты требований? Назовите несколько атрибутов и обоснуйте их выбор.
6.Что такое статус и состояние требования?
7.Кто принимает решение о внесении изменений в требования?
8.Какие задачи позволяет решить трассируемость требований?
8. CASE-средства для управления требованиями
Изучив тему, Вы будете знать:
§ каковы достоинства CASE-средств управления требованиями;
§ чем определяется выбор CASE-средств управления требованиями;
§ возможности некоторых CASE-средств управления требованиями.
При освоении темы необходимо акцентировать внимание:
§ на недостатках документального хранения требований;
§ на взаимосвязи между уровнями зрелости и используемыми инструментами;
§ на возможностях CASE-средств управления требованиям.
8.1. Выбор CASE-средств для управления требованиями
Как было уже замечено документальное хранение требований весьма трудоемко и имеет много недостатков, основные из которых – это трудности:
· во внесении изменений, поддержке непротиворечивости и актуальности документов;
· в хранении атрибутов, управлении статусом требований;
· в управлении версиями и т.д.
Поэтому использование инструментальных средств является необходимым условием успешности выполнения проекта. Средства автоматизации и поддержки, используемые в процессе разработки программных систем, принято называть CASE-средствами (Computer-Aided Software Engineering). Нас интересуют средства, которые можно использовать на этапе разработки и анализа требований к программной системе, т.е. средства, поддерживающие: выявление и документирование требований пользователей, разработку системных требований, анализ требований и управление требованиями.
Существует достаточно большое число средств, позволяющих управлять требованиями, но нет средств, которые могли бы помочь процессу разработки требований, например:
· при определении заинтересованных лиц, пользователей системы;
· при выявлении и сборе требований.
CASE-средства не могут заменить «ручные» методы выявления требований.
CASE-средства позволяют более точно и производительно управлять требованиями, но не всегда внедрение автоматизации в этот процесс приводит к успеху. Многие авторы [4, 6] говорят о том, что даже лучшие средства могут не оправдать ожиданий, если их используют разработчики, не имеющие должной квалификации и мотивации. Дело в том, что для перехода к оперативным приемам работы с требованиями необходим новый образ мышления, достаточный уровень зрелости функциональных возможностей.
Дата: 2018-11-18, просмотров: 469.
