Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
11. Афанасьев Ф. Управление проектами в стиле ДРАЙВ / Ф. Афанасьев. –
Издательские решения, 2017. – 102 с. – URL: http://izhmmc.ru/wp-content/
uploads/2020/02/управление-проектами-в-стиле-драйв.pdf (дата обращения:
10.03.2023).
12. Redmine как универсальный инструмент для управления проектами. –
URL: https://www.redmineup.com/pages/ru/blog/redmine-project-management-system
(дата обращения: 10.03.2023).
13. Печенкин Г. Чего я хочу от разработки инструментов разработки требований. Затычки, костыли и грабли СУТ / Г. Печенкин. – 2014. – URL:
https://habr.com/ru/company/sqalab/blog/217737 (дата обращения: 10.03.2023).
14. Инструменты управления требованиями: что это такое, бесплатные инструменты и приложения. – 2022. – URL: https://businessyield.com/ru/
management/requirement-management-tools (дата обращения: 10.03.2023).
15. Как писать техническое задание?! – 2022. – URL: https://tdocs.su/1349
(дата обращения: 10.03.2023).
51
ПРИЛОЖЕНИЯ
Приложение 1
СПОСОБЫ УТОЧНЕНИЯ НЕОДНОЗНАЧНЫХ СЛОВ
В ТРЕБОВАНИЯХ
Ниже приведен список часто используемых при формулировании
требований неоднозначных слов и способы их уточнения. Более полный
список размещен в работе [1, с. 250].
№
п/п
1 Приемлемый, адек-
2 И/или Указать точно, что имеется в виду – «и» или
3 Практически выпол-
4 По меньшей мере,
5 Наилучший, самый
6 Между, от Х до Y Указать, входят ли конечные точки в диапазон
7 Зависит от Определить природу зависимости. Например,
Неоднозначные
слова
ватный
нимо
как минимум, не более чем, не должно
превышать
большой, большинство
Способы уточнения
Определить, что понимается под приемлемостью и как система может это оценить
«или», чтобы не заставлять читателя гадать
Указать дату, к которой задача должна быть
выполнена
Указать минимальное и максимальное значения
Указать, какой уровень требуется, а также минимальный приемлемый уровень
обеспечивает ли другая система ввод данных
в проектируемую систему, надо ли установить
другое ПО до запуска проектируемой системы
и зависит ли проектируемая система от другой
при выполнении определенных расчетов
52
Продолжение таблицы
№
п/п
Неоднозначные
слова
8 Эффективный
9 Быстрый, скорый
10
Гибкий, универсальный
11
Улучшенный, лучший, более быстрый, более качественный
12
Включает; включает
в себя, но не ограничен этим; такой как,
в частности
13
В большинстве случаев, обычно, как
правило, практически всегда
14 Не обязательно
15
Обычно, в идеальном варианте
16
Возможно, желательно, должно
17
Разумный, при необходимости, когда
уместно, по возможности
Способы уточнения
Определить, насколько эффективно проектируемая система будет использовать ресурсы,
насколько быстро она выполняет определенные
операции и как быстро пользователи смогут с
ее помощью выполнять определенные задачи
Указать минимальное приемлемое время,
за которое проектируемая система выполнит
определенное действие
Описать способы адаптации проектируемой
системы при изменении условий работы, платформы или бизнес-правил
Определить количественно, насколько лучше
или быстрее должны стать показатели в определенной функциональной области или аспект
качества
Перечислить все возможные значения
или функции, а не только примеры. Указать,
где можно посмотреть исчерпывающий список.
Иначе разные читатели могут по-разному понимать, что должен содержать полный список
и где он должен заканчиваться
Уточнить, когда указанные условия или сценарии неприемлемы и что должно происходить
в таком случае. Описать, как пользователь или
проектируемая система должны различать разные случаи
Указать, кто или что делает выбор: пользователь, разработчик, проектируемая система
Описать внештатные или неидеальные условия
и как проектируемая система должна вести
себя в таких ситуациях
Уточнить, возможно или невозможно
Четко объяснить, как разработчик или пользователь должен оценивать разумность и уместность
53
Окончание таблицы
№
п/п
18 Цельный, прозрач-
19 Несколько, некото-
20 Не следует Лучше формулировать требования в позитив-
21 Дружественный,
Неоднозначные
слова
ный, корректный
рые, много, немного, множественный
простой, легкий
Способы уточнения
Четко объяснить, как разработчик или пользователь должен оценивать цельность и прозрачность. Выразить ожидания пользователя, применяя характеристики продукта, которые
можно наблюдать
Указать сколько или задать минимальную
и максимальную границу диапазона
ной форме, описывая, что именно проектируемая система будет делать
Описать системные характеристики, которые
будут отвечать потребностям пользователей
и их ожиданиям, касающимся легкости и простоты использования проектируемой системы
54
Приложение 2
ПРИМЕРЫ ТРЕБОВАНИЙ ДО И ПОСЛЕ КОРРЕКТИРОВКИ
Ниже приведены примеры первоначальных формулировок требований и эти же требования после корректировки. Примеры взяты из работы [1]. В указателях на примеры дополнительно отмечается первоначальная (до) и усовершенствованная (после) версия требования.
Любой из приведенных примеров при желании можно усовершенствовать. Нужно уметь остановить процесс улучшения формулировок
требований, когда станет ясно
, что в существующем виде набор требований в спецификации проекта позволяет перейти к следующей стадии
разработки при приемлемом уровне риска.
Пример 1 – «До»
Диспетчер фоновых задач должен предоставлять сообщения о состоянии через регулярные интервалы, каждый из которых составляет
не менее 60 секунд.
Такая формулировка вызывает много вопросов.
Что
понимается под сообщениями о состоянии?
При каких условиях и как именно они поставляются пользова-
телю?
Как долго они должны отображаться на экране?
Достаточно ли отображения на протяжении половины секунды?
Этот список вопросов далеко не полон. Есть и другие проблемы:
например, продолжительность временного интервала не сформулирована точно, а
слово «каждый» только вносит дополнительную неяс-
ность.
Надежным способом оценки качества требования является получение информации от пользователя о его понимании смысла данного требования. Если пользователя не удовлетворяет это требование, то его
нужно переформулировать.
Можно продолжить список вопросов к требованию.
В этом примере интервал должен быть «не менее 60
секунд»; таким образом, если сообщение будет появляться раз в год, это нормально?
Если промежуток не должен превышать 60 секунд, то не будет ли
интервал, составляющий одну миллисекунду, слишком коротким?
55
Следует отметить, что вопросы не выходят за рамки первоначального требования, но очевидно, что потребности пользователя задокументированы нечетко.
Приведем вариант исправленного требования после получения дополнительной информации от пользователя.
Пример 1 – «После»
Диспетчер фоновых задач (ДФЗ) должен отображать сообщения
о состоянии в определенной области пользовательского интерфейса.
ДФЗ должен обновлять сообщения
каждые 60 5 секунд после за-
пуска фоновой задачи.
Сообщения должны оставаться видимыми все время, пока работает фоновая задача.
Если взаимодействие с фоновой задачей возможно, то ДФЗ должен
отображать процент выполнения фоновой задачи.
По завершении фоновой задачи ДФЗ должен отобразить сообщение «Выполнено».
Если фоновая задача «зависла»
, то ДФЗ должен отобразить соот-
ветствующее сообщение.
При переписывании несовершенного требования его формулировка
становится длиннее из-за необходимости включения отсутствовавшей
информации. Разделение требования на несколько дочерних разумно,
потому что для каждого понадобится отдельный тест, кроме того, так их
проще отслеживать.
Скорее всего, будут также дополнительные сообщения о состоянии,
отображаемые ДФЗ
. Если они задокументированы в другом месте,
например в спецификации интерфейса, то нужно добавить эту информацию по ссылке, не дублируя ее.
Перечисление сообщений в таблице условий позволит предоставить
информацию более лаконично, чем при написании множественных
функциональных требований.
В измененном требовании не указан способ отображения сообщения о состоянии (!) – указано просто «
в определенной области пользо-
вательского интерфейса». Такая формулировка делает размещение
сообщений задачей дизайна, что допустимо в большинстве ситуаций.
Если сейчас определить место отображения сообщений, то разработчики воспримут ее как ограничение. Излишние подробности дизайна
56
ограничивают разработчиков, кроме того, в этом случае вряд ли можно
рассчитывать на оптимальный продукт.
Однако представьте, что мы добавляем эту функциональность в существующее приложение, у которого уже есть строка состояния, где
пользователи привыкли видеть важные сообщения. Для единообразия
имеет смысл предусмотреть условие, что сообщения о состоянии ДФЗ
должны отображаться
в строке состояния, т. е. можно специально нало-
жить ограничение дизайна, имея на то серьезную причину.
Пример 2 – «До»
Если возможно, номера счетов следовало бы проверять по списку
корпоративных счетов.
Такая формулировка вызывает вопросы. Что означает «если возможно»? Значит ли это «технически осуществимо» (вопрос для разработчика) или «когда
доступен основной список счетов»?
Если нет уверенности, что можно реализовать функцию, то нужно
отметить, что проблема еще не решена. После проверки возможности
реализации функции станет понятно, что нужно либо удалить пометку,
либо требование.
В требовании также не описаны действия, которые необходимо реализовать в продукте, если проверка пройдет успешно или окончится
неудачей. В приложении 1 приведен список неточных слов и даны рекомендации, как откорректировать требование, чтобы проработать неточность в его формулировке.
Пример 2 – «После»
В момент ввода номера счета продукт должен отобразить сообщение об ошибке, если этого номера счета нет в основном корпоративном списке счетов.
Для полноты
списка требований нужно проверить наличие связанного требования с условием исключения: основной список счетов недоступен во время проверки.
Пример 3 – «До»
Тестер должен позволять пользователю легко подключать дополнительные компоненты, в том числе импульсный генератор, вольтметр, измеритель емкости и нестандартные тестовые платы.
57
В примере сформулировано требование к продукту со встроенным
программным обеспечением, которое используется для тестирования
различных типов измерительных приборов.
Слово «легко» относится к неясным терминам. Нужно заменить это
слово так, чтобы реализацию требования в продукте можно было проверить. Уточнение «в том числе» не приводит к пониманию, полный ли
это список
внешних устройств, которые должны подключаться к испытательному устройству. Такие альтернативные требования содержат некоторые преднамеренные ограничения дизайна.
Пример 3 – «После»
1. Тестер должен содержать USB-порт, чтобы пользователь смог
подключить любой измерительный прибор, у которого есть USB-
разъем.
2. USB-порт должен быть установлен на передней панели для того,
чтобы квалифицированный оператор
мог подключить измерительный
прибор за 10 секунд или менее.
Бизнес-аналитик не должен по собственной инициативе переписывать требования так, чтобы они налагали ограничения дизайна. Вместо
этого нужно стремиться обнаруживать несовершенные требования и обсуждать их с соответствующими заинтересованными лицами для уточнения требований.
Пример 4
Система должна проверять наличие
несоответствий данных сче-
тов между журналом активных счетов и архивом диспетчера счетов.
Логика, применяемая для создания этих сравнений, должна основываться на логике существующего средства проверки соответствия.
Иначе говоря, код не нужно создавать с нуля. В качестве основы разработчики должны использовать код существующего средства проверки соответствия. Однако нужно
добавить дополнительную логику
определения базы данных, являющейся полномочным источником. Новая функциональность будет включать запись данных в таблицы, указывающие, как и где разрешать несоответствия. Кроме того, код должен проверять наличие исключительных сценариев по базе данных
средств безопасности. При обнаружении несоответствий в команду
безопасности должны отправляться автоматизированные уведомления о
сообщениях электронной почты.
58
Зачастую требования представляют собой такой неструктурированный текст. Ниже приведены некоторые советы и вопросы, которые помогут устранить недостатки данного текста.
Есть ряд требований, который нужно разбить на отдельные требо-
вания.
Если логика сравнения «основывается» на логике существующего
средства проверки соответствия, то какая конкретно часть может повторно
использоваться и как ее нужно изменить?
Какие функции различаются в новой системе и в существующем
средстве?
Какую «дополнительную логику» нужно добавить?
Как конкретно система может определить, какая база данных яв-
ляется «полномочным источником»?
Новая функциональность «включает» запись данных в таблицы.
Нужно определить, «включена» ли другая функциональность, о
которой
не сказано явно?
Нужно уточнить, что означает «как и где», когда речь идет о раз-
решении несоответствий.
В некоторых местах нужно использовать слово «должен».
Какое соотношение между «исключительным сценарием» и «несо-
ответствием»? Если это синонимы, то следует выбрать один термин и
придерживаться именно его. В словаре
терминов можно уточнить, что
это – одно и то же или разное и какая между ними связь.
Какую информацию система должна отправлять в команду без-
опасности при обнаружении несоответствия?
Как уже было отмечено ранее, невозможно создать идеальные требования. Однако практически всегда их можно сформулировать лучше.
59
Приложение 3
ОПИСАНИЕ СИСТЕМЫ ЗАКАЗОВ ХИМИКАТОВ
Ниже представлено краткое описание системы заказов химикатов,
для которой в приложениях 4–8 приведены примеры моделей анализа.
В описании выделены некоторые слова, которые определяют важные
элементы для анализа процессов системы. Значимые уникальные существительные выделены полужирным начертанием, глаголы (действия) – курсивом, а условия – полужирным курсивом.
«Химик или сотрудник склада химикатов может разместить
за-
каз на один или несколько химикатов, если пользователь уполномо-
чен делать такие заказы. Заказ может быть выполнен или посредством
доставки контейнера с химикатом, который числится в инвентарной
описи товаров на складе химикатов, или посредством размещения заказа на химикат у стороннего поставщика. Если химикат относится
к опасным, то он может
быть доставлен, только если пользователь про-
шел соответствующее обучение. Сотрудник, размещающий заказ,
подготавливая заказ, должен иметь возможность искать в интерактивном режиме нужный химикат в каталогах поставщиков. Системе
необходимо отслеживать состояние каждого заказа с момента его
подготовки и до момента его выполнения или отмены. Ей также необходимо отслеживать историю
каждого контейнера с химикатом с мо-
мента его получения компанией до его полного расходования или ути-
лизации» [1, с. 264].
60
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]