Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
Ссылки обеспечивают актуальность требований при изменениях
и упрощают повторное использование одного правила в нескольких местах или проектах. Необходимость работать со ссылками является платой за отказ от дублирования информации при работе с требованиями.
31. Есть сложности в процессе разработки требований
к программному продукту с применением традиционного
ручного подхода?
Традиционный ручной
подход имеет недостатки. В частности, при
ручном подходе необходимо обеспечить следующее:
внесение одинаковых изменений во все нужные документы, кото-
рые содержат один и тот же модуль. Зачастую не во все документы вносятся нужные изменения, либо внесенные в разные документы изменения различаются;
внесение и хранение новых характеристик
для каждого требования. Нужно дополнительно фиксировать, в каких хранилищах размешены все данные обо всех требованиях;
определение взаимосвязей между требованиями и их наборами,
а также с другими элементами системы. Сложно строить целостную
картину взаимосвязей на основе разрозненной информации в текстовой
форме, которая отличается последовательным способом подачи информации;
управление наборами требований для различных выпусков продукта. При принятии решения об изменении выпуска, в котором будет
реализовано требование, нужно корректно вручную перенести информацию о требовании и связанных с ним требованиях в другой документ;
повторное использование требования. Нужно многократно копи-
ровать требование из спецификации, где находится исходное требование, в спецификацию требований соответствующих программных продуктов;
изменение требований несколькими участниками проекта, осо-
бенно если они географически разделены.
Кроме того, имеются и другие проблемы:
отсутствие удобного места хранения требований, которые были
предложены, но отклонены, или требований, удаленных из базовой версии;
41
тяжело создавать и отслеживать связи исправлений и моделей ана-
лиза в том же месте, что и требования;
сложность обнаружения пропущенных, дублирующихся или не-
нужных требований.
Средство разработки и управления требованиями позволяет снять
перечисленные ограничения, помогая выявить правильные требования
для проекта и оценить качество написания этих требований.
Средства управления
требованиями обеспечивают управление изменениями этих требований и отслеживание их связи с другими результатами проекта. В небольших проектах для управления требованиями
можно использовать электронные таблицы или простые базы данных.
В крупных проектах продуктивно использовать программные средства
управления требованиями.
Средства управления требованиями не могут выполнить за проекти-
ровщиков работу по выявлению
и формулированию требований.
Их можно использовать только в том случае, если в команде уже выработаны и используются определенные приемы создания требований
и управления ими. Тогда средства управления требованиями повышают
качество работы с ними.
Лучше использовать одно из коммерческих средств управления тре-
бованиями, чем тратить ресурсы проекта на разработку своего
средства,
используя средства офисной автоматизации общего назначения. Такой
подход требует значительных вложений, которых, как правило, в проектных командах нет.
32. Какие функции могут выполнять различные средства
управления требованиями?
Средства разработки требований обеспечивают эффективную коммуникацию в различных формах между разработчиками продукта и заинтересованными лицами проекта при выявлении и описании
требова-
ний [11–14].
На схеме на стр. 43 показаны основные возможности средств, работающих с требованиями [1, с. 596].
Программные инструменты подразделяют на средства выявления
требований, создания прототипов и моделирования. Имеются программные продукты, в которых реализованы функции всех трех названных типов инструментов разработки требований. Наиболее развитый
функционал имеют средства управления требованиями.
42
43 44
Средства выявления требований дают воз-
Средства
выявления
требований
можность фиксировать предоставляемые заинтересованными лицами сведения в процессе работы
над требованиями. Они позволяют разработчикам
анализировать предложенные суждения, выделять перспективные для работы идеи, определять основные термины и
задавать правильные вопросы заинтересованным лицам.
Средства создания прототипов предназна-
Средства
создания
прототипов
чены для разработки различных вариантов продукта, которые
могут быть представлены в форме
от электронных макетов до приложений с работающим функционалом.
Для быстрого представления макетов экранов и навигации между
ними часто применяют Microsoft PowerPoint.
Некоторые средства создания прототипов поддерживают управление версиями, создание связей между требованиями и генерацию кода.
При создании высококачественного прототипа нужно обязательно объяснить пользователю назначение разработанного
варианта продукта,
что позволит исключить ситуацию принятия пользователем прототипа
в качестве готового продукта.
Имеются средства создания прототипов, отображающие модели
«нарисованных от руки» экранов. Такая возможность способствует
управлению ожиданиями клиентов.
Средства моделирования требований по-
Средства
моделирования
могают разработчикам создавать разнообразные диаграммы. Система помощи таких
средств, содержащая шаблоны диаграмм
и примеры их использования
, предлагает ценную информацию для выбора эффективных форм представления информации с целью определения требований проекта. Шаблоны диаграмм обеспечивают качество созданных диаграмм и единообразие их оформления.
В специализированном средстве моделирования программного
обеспечения перемещение какого-либо элемента на диаграмме выполняется одновременно с перемещением связанных с этим элементом
стрелок и
меток. Такая возможность обеспечивает возможность внесе-
ния любого количества изменений в диаграмму.
Многие средства управления требованиями поддерживают некоторые возможности по моделированию. Развитые средства управления
дают возможность отслеживать связи отдельных требований к моделям
или даже конкретным элементам моделей. Например, можно создать
с помощью такого средства swimlane-диаграммы и отслеживать требования по конкретным шагам в диаграммах после их написания.
Следует подчеркнуть, что средства разработки требований не могут
определять пропуски требований или элементов модели, логическую
ненужность или
неточность формулировки требования. Эти средства позволяют определять ошибки определенного типа и не исключают необходимость проверять качество отдельных требований и наборов требований
в целом с привлечением к этой работе заинтересованных лиц.
33. Какие дополнительные возможности по разработке требований
предоставляют средства управления требованиями?
Средство управления требованиями исключает хранение требова-
ний в
документах за счет хранения сведений в многопользовательской
базе данных.
Для больших проектов системы управления требованиями предоставляют возможность импортировать требования из различных документов, экспортировать требования в различных форматах, определять
связи отслеживания и значения атрибутов требований, просматривать
результаты фильтрации базы данных требований, а также соединять
требования с элементами, хранящимися в других
средствах разработки
программного обеспечения. В небольших проектах можно ограничиться вводом текста требования и выбранными атрибутами каждого
требования.
Следует отметить, что решаемые с помощью средств управления
требованиями задачи проще, чем те, которые решаются средствами разработки требований. Средства управления требованиями выполняют
хорошо структурированные действия: ввод требований в базу данных и
выполнение стандартных операций с записями базы данных. Средства
разработки требований по идее должны помочь разработчикам найти
нужные сведения для определения требований из различных источников, сформулировать на этой основе требования к продукту и построить
диаграммы, позволяющие определить корректность и полноту требований, что значительно сложнее.
Существуют программные средства, которые выполняют задачи
и средств разработки требований, и средств управления требованиями.
45
34. Какие преимущества получают разработчики,
используя средства управления требованиями?
Ценность использования программных средств управления требованиями для проекта становится очевидной и неоспоримой в процессе работы над проектом. Они помогают не потерять контроль над требованиями, когда объем обрабатываемой информации увеличивается, а детали
начинают забываться.
Если в проекте предполагается разрабо-
тать
Управление
версиями
и изменениями
несколько версий продукта с разным
набором требований, то можно выбрать
средство управления требованиями с гибким управлением исходным набором требо-
ваний. Такое средство ведет историю изменения каждого требования,
что обеспечивает возможность определять основание для его изменения
и при необходимости возврат к предыдущей версии. Есть средства,
определяющие связи между предложением изменения
требования и но-
вым вариантом требования.
Средства управления требованиями авто-
Хранение
атрибутов
матически определяют различные системные
атрибуты для каждого требования, в частно-
сти дату создания и номер версии продукта, и
обеспечивают создание и выполнение стандартных операций обработки
требований с различными типами атрибутов.
Средство может ограничивать круг разработчиков, имеющих право
изменять атрибуты требований. Для
просмотра и анализа списков требований с нужными характеристиками необходимо тщательно продумывать набор атрибутов требований.
Средства управления требованиями пре-
Обеспечение
анализа
воздействия
доставляют возможность отслеживать связи
требования «вверх» до первоисточника требования, «по горизонтали» с другими требо-
ваниями, требованиями в других подсистемах и с прочими компонентами продукта (дизайном, тестами, кодом,
пользовательской
документацией), а также «вниз» – с производными
требованиями. Такой набор связей позволяет определять зависимые
требования при изменении, например, бизнес-правила или возможные
последствия для требований, связанных «по горизонтали» и «вниз».
46
Средства управления требованиями дают
р
Выявление
отсутствующих
и излишних
т
ебований
возможность определять пользовательские
требования, не имеющие связей с функциональными требованиями, что указывает на
обнаружение отсутствующих функциональ-
ных требований. При удалении требования
средства управления обеспечивают простоту удаления или изменения
связанных с ним требований. Выявление требований без источника решает вопрос поиска потенциально лишних требований.
Отслеживание
состояний
требований
Средство управления
нит все требования к продукту, что дает возможность более точно оценивать сложность
и проработанность проекта в целом. Послед-
требованиями хра-
нее определяется по статусу реализованности каждого отдельного требования.
В средствах управления требовани-
Управление
доступом
ями определяются права доступа различных групп пользователей и членов
распределенных команд разработчиков
к базам данных.
Все
Связь со всеми
заинтересованными
в проекте лицами
и заинтересованные лица работают с одним и тем же набором требований. Средство управления требованиями обеспе-
члены команды разработчиков
чивает обсуждение требований – например, с помощью обмена электронными сообщениями, при этом участники
обсуждения получают уведомление о появлении новых сообщений.
Повторное
использование
требований
Для повторного использования требова-
ний в других проектах лучше хранить
требования в единой базе данных. Кроме того, такой подход помогает исключить дублирова-
ние требований, поскольку есть возможность ссылаться на единственный экземпляр требования в базе данных.
В некоторых средствах управления тре-
Отслеживание
состояния
дефектов
бованиями предусмотрена возможность отслеживания состояния выявленных дефектов и связывания их с соответствующими
47
требованиями. Можно просматривать историю дефекта вплоть до его
устранения. При устранении дефекта можно определить, нужно ли обновить соответствующие требования.
Отслеживание дефектов с помощью специального программного
средства позволяет автоматически получать отчеты о ситуации с дефектами.
В процессе работы в проекте может возникнуть запрос на получение
Генерирование
произвольных
подмножеств
требований
списка требований для определенной
Например, возможен запрос на список требований, реализуемых на определенной итерации разработки продукта, или запрос на
список требований, качество реализации ко-
цели.
торых нужно проверить.
35. Как выбрать программное средство
управления требованиями?
При выборе средства управления требованиями нужно учитывать
наличие необходимых функций в средстве управления, а также доступность и
платформу. Все это должно соответствовать среде разработки
проекта и методам, используемым разработчиками.
В [1] предложен вариант организации процесса выбора средства
управления требованиями, которое удовлетворяет критериям, подготовленным специалистами команды разработчиков проекта. Следует отметить, что предложенный вариант действий по выбору можно использовать всякий раз, когда возникает задача выбора с определенными кри
териями.
Нужно учесть, что настройка средства управления требованиями
и заполнение базы данных требованиями предполагает наличие необходимых ресурсов в проекте. Кроме того, внедрение нового инструментального средства может потребовать изменения шаблонов некоторых
документов и внесения изменений в процессы разработки.
Если члены команды имеют низкую мотивацию, недостаточные знания и опыт
разработки или не хотят (не могут) тратить силы на освоение
новых инструментов, то никакое программное инструментальное средство не сможет восполнить этот дефицит и повысить качество разработки в целом.
-
48
ЗАКЛЮЧЕНИЕ
Для успешной разработки требований команде разработчиков сле-
дует:
считать вложения в разработку качественного набора требований
инвестицией в проект, которая окупается по мере развития проекта;
привлекать пользователей и других заинтересованных лиц к раз-
работке на ранних стадиях;
для документирования требований использовать кроме текста раз-
личные графические формы;
привлекать
ресованных лиц, в том числе пользователей, для принятия окончательного решения по качеству;
использовать единые и понятные всем заинтересованным лицам
способы представления информации о требованиях;
управлять корректировкой требований.
В работе [15] описаны продуктивные приемы подготовки технического задания на разработку автоматизированной системы в
ствии с ГОСТ 34.602–89.
к оценке качества разработанных требований заинте-
соответ-
49
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Вигерс К. Разработка требований к программному обеспечению : пер. с
англ. / К. Вигерс, Дж. Битти. – 3-е изд., дополн. – Москва : Русская редакция ;
Санкт-Петербург : БХВ-Петербург, 2014. – 736 с. – URL: https://viduus.net/wp-
content/uploads/2019/02/Razrabotka-trebovanij-k-programmnomuobespecheniyu.pdf (дата обращения: 10.03.2023).
2. Селютин Ю. Стоит прочитать: обзор книги Карла Вигерса «Разработка
требований к программному обеспечению» / Ю. Селютин. – URL: https://t
proger.ru/ books/obzor-knigi-karla-vigersa-razrabotka-trebovanij-k-programmnomu- obespecheniju (дата обращения: 10.03.2023).
3.
Анализ требований по Вигерсу (2004). Этапы сбора требований. – URL:
https://analytics.infozone.pro/requirements-analysis/analysis-of-requirementswiegers-2004 (дата обращения: 10.03.2023).
4. Лазовский А. Как писать требования, чтобы их понимали / А. Лазовский. – 2021. – URL: https://vc.ru/u/291078-anton-lazovskiy/220793-kak-pisattrebovaniya-chtoby-ih-ponimali (дата обращения: 10.03.2023).
5. Функциональные и нефункциональные требования: полное руководство. – 2021. – URL: https://bestprogrammer.ru/izuchenie/funktsionalnye-i-
nefunktsionalnye-trebovaniya-polnoe-rukovodstvo (дата обращения: 10.03.2023).
6. Разработка и анализ требований к программному обеспечению. – 2015. –
URL: https://spravochnick.ru/lektoriy/razrabotka-i-analiz-trebovaniy-k-programmnomu-obespecheniyu (дата обращения: 10.03.2023).
7. Коберн А. Современные
к системам / А. Коберн. – Лори, 2018. – 288 с.
8. Шикина В. Е. Техническая документация информационных систем :
учеб. пособие / В. Е. Шикина. – Ульяновск : УлГТУ, 2018. – 92 с.
9. Полный гайд по сбору требований к ПО для тестировщиков. – 2022. –
URL: https://tproger.ru/articles/vyjavlenie-i-sbor-trebovanij-k-po-ultimate-guide (дата
обращения: 10.03.2023).
10. Бесков Д. Как задавать требования к качеству ПО в цифрах? / Д
2022. – URL: https://www.software-testing.ru/library/around-testing/requirements/
3843-systemseducation (дата обращения: 10.03.2023).
методы описания функциональных требований
. Бесков. –
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]