Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Разработка требований к программному продукту. Учебное пособие
.pdf
на некотором этапе работы они становятся неинформативными. Это может выражаться в следующем:
пользователи уже не предлагают новых задач, которые они смогут
решать с помощью разрабатываемого продукта;
пользователи предлагают новые задачи, но их выполнение воз-
можно с использованием уже запланированного функционала продукта;
предлагаемые новые пользовательские или
функциональные тре-
бования выходят за рамки проекта;
предлагаемые требования имеют низкий приоритет для реализа-
ции в данном проекте или могут быть реализованы, например, в следующей версии продукта;
при оценке качества требования разработчики и тестировщики
практически не задают уточняющих вопросов.
19. Какие характеристики определяют качество
отдельных требований?
Полнота
Полное требование
информации, когда оно понятно любому заин-
содержит достаточно
тересованному лицу. Если это функциональное требование, то имеющейся информации должно быть достаточно
для продолжения работ на следующем этапе разработки проекта.
Корректное требование описывает опре-
Корректность
деленную потребность заинтересованного
лица проекта и функцию продукта, которую
нужно разработать для удовлетворения этой потребности. Оно также
имеет описание первоисточника требования (пользователя, высокоуровневое системное требование, вариант использования, бизнес-правило или другой документ).
Осуществимое требование может быть
Осуществимость
реализовано с использованием определен-
ных программных инструментов и ресурсного обеспечения проекта. Построение прототипов позволяет проверять
осуществимость требований. Если требование решено удалить из-за его
неосуществимости, то следует учесть его
влияние на концепцию и гра-
ницы проекта.
21
Необходимое требование может пре-
Необходимость
доставить заинтересованным лицам воз-
можность решать задачу в конкретной
предметной области, выделить продукт на рынке или позволить выполнить требования внешних стандартов. Источник каждого требования
имеет право предлагать требования. Важно отследить каждое требование до бизнес-целей. Это самый неоспоримый источник требований.
Двусмысленность требований можно
Недвусмысленность
обнаружить
в процессе оценки качества
требований заинтересованными лицами.
Они могут сравнить свое понимание требований с пониманием других
людей и при необходимости уточнить формулировки двусмысленных требований. Полностью устранить двусмысленность из требований в условиях ограниченных ресурсов проекта невозможно. В таких
случаях может выручить способность специалистов правильно понимать некорректные требования. На это
лучше не рассчитывать, но самые досадные и значимые двусмысленности таким способом удастся
устранить.
Проверяемое требование имеет тесты
Проверяемость
для проверки правильности его реализа-
ции. Если соответствующих тестов нет, то
правильность реализации требования может быть только оценена экспертами, но не объективно подтверждена результатами тестирования.
Неполные, невыполнимые или двусмысленные требования также
не поддаются качественной проверке. Важно привлекать тестировщиков к оценке качества требований на их пригодность для проверки
уже на этапе разработки требований, что в будущем сохранит ресурсы проекта.
Если считать все требования одинаково
Назначение
приоритетов
важными для реализации, то внесение новых
требований или корректировка имеющихся
может привести к существенному нарушению сроков
завершения проекта.
Приоритеты требований из предметной области целесообразно
определять на основании их важности для получения требуемой пользы.
Исходя из этого, для конкретного выпуска продукта можно назначить
приоритеты каждому функциональному или пользовательскому требованию, варианту использования или функции.
22
Для приоритизации требований следует привлекать заинтересованных лиц проекта – это позволит учесть их интересы в получении
продукта.
20. Какие дополнительные способы представления информации
кроме текста можно использовать в проекте?
Сложность понимания, оценки качества и корректировки списка
требований, оформленного в виде текста, заставляет привлекать различные модели анализа информации, используемой для формулирования
требований к продукту.
В процессе общения с заинтересованными лицами аналитику нужно
выделить ключевые слова, которые задают конкретные элементы выбранных моделей анализа данных. В табл. 2 показано возможное соответствие ключевых слов, выделенных аналитиком у пользователей,
компонентам моделей, которые частично рассматриваются в настоящем
учебном пособии.
Таблица 2
Соответствие между ключевыми словами
и компонентами моделей анализа [1, с. 263]
Тип Примеры Компоненты модели анализа
Существительное
Глагол Действия, задачи,
Условие Если…, то… Решения (деревья решений, таблицы решений
Люди, организации,
ПО, данные, объекты
которые пользователь может выполнить; события, которые могут произойти
Внешние сущности, хранилища данных, потоки
данных (диаграммы потоков данных).
Действующие лица (диаграммы вариантов использования).
Сущности или их атрибуты (диаграммы «Сущность – связь»).
Дорожки (диаграммы swimlane).
Объекты с состояниями (STD)
Процессы (диаграммы потоков данных).
Шаги процессов (диаграммы swimlane).
Варианты использования (диаграммы вариантов
использования).
Взаимосвязи (диаграммы «Сущность – связь»).
Переходы (диаграммы переходов состояний).
Действия (диаграммы действий).
События (таблица событий и реакций)
или диаграммы действий).
Ветвление (диаграмма swimlane или диаграмма
действий)
23
В процессе проектирования нужно будет определять связи каждого
компонента той или иной модели с конкретными пользовательскими
требованиями.
В табл. 2 перечислены разнообразные компоненты модели анализа
данных, сами модели указаны в скобках. Для каждого проекта нужно
решить, какой набор моделей использовать с целью упорядочения информации об объекте, для которого разрабатывается продукт
. На принятое решение будут влиять сложность процессов работы объекта,
наличие версии продукта, уровень подготовки заинтересованных лиц
и опыт команды разработчиков.
В настоящем учебном пособии все модели анализа данных подготовлены для системы закупок химических веществ, описанной в [1]
и приложении 3. Примеры рассматриваемых моделей анализа в учебном пособии размещены в
приложениях 4–8 (ссылки даются из описа-
ния модели анализа данных того или иного типа).
При разработке моделей анализа данных нужно моделировать сложные в организации и опасные по последствиям возможных событий
участки или процессы объекта. В таких случаях цена неправильно понятых сведений, использованных для формулирования требований,
резко возрастает, поскольку увеличивается риск
ошибок при проекти-
ровании.
В табл. 3 частично приведены способы представления различных
компонентов исследуемой системы.
Таблица 3
Способы представления различных компонентов
исследуемой системы [1, с. 265]
Отображаемая
информация
Процессы Общее представление о преобразовании потоков данных
в исследуемой системе дает диаграмма потоков данных.
Диаграмма swimline определяет лица и устройства, которые
выполняют действия в процессах.
Детальное описание процессов преобразования данных
можно выполнить, используя диаграммы потоков данных
и диаграммы swimline на более низких уровнях описания.
Для описания деталей процессов также можно использовать
диаграммы потоков и диаграммы действий
Способы представления
24
Окончание табл. 3
Отображаемая
информация
Данные
и связи объектов данных
Состояния
системы
и объектов
Сложная
логика
Пользовательские интерфейсы
Способы представления
Диаграмма сущность – связь показывает логические отношения между объектами данных (сущностями). Диаграмма
классов показывает логические связи между классами объектов и связанными с ними данными
Диаграммы переходов состояния и таблицы состояния
дают представление высокого уровня общности возможных
состояний системы и переходов между состояниями, которые происходят при определенных условиях. Этот тип моделей полезен, если в исследуемой системе определяют значительное число состояний.
Можно создать таблицу событий и реакций для определения
границ продукта. В этой таблице можно привести отдельные функциональные требования, определяя внешние
обстоятельства и состояния системы, а также реакцию системы на них.
Функциональные требования описывают, как действия системы и пользователя изменяют состояние системы
Дерево решений показывает результаты связанных условий
и решений. Таблица решений определяет уникальные функциональные требования, связанные с различными комбинациями результатов TRUE и FALSE для наборов решений
или условий
Карта диалоговых окон предоставляет высокоуровневое
представление предлагаемого или фактического пользовательского интерфейса, показывая разные элементы отображения и пути навигации между ними.
Макеты экрана и прототипы показывают, как должны вы-
глядеть элементы интерфейса
21. Какую модель анализа можно использовать
для анализа потоков данных в исследуемом объекте?
Для анализа потоков данных в исследуемой системе используют,
как правило, диаграммы потоков данных. Это основной инструмент
структурного анализа. Диаграмма потоков данных определяет процессы преобразования данных и материалов в системе, хранилища
25
данных или материалов, которыми система управляет, а также потоки
данных или материалов между процессами, хранилищами и внешним
миром.
В сложных случаях для системного анализа процессов преобразования данных и материалов в системе используют метод декомпозиции.
При этом возникает иерархическая совокупность диаграмм потоков
данных. Такой подход хорошо описывает потоки данных в
системах
с большой функциональностью.
Дополнительно к моделям потоков данных строят диаграммы
swimlane. Они показывают весь процесс преобразования потока данных
или материалов, включая информацию о лицах или устройствах, выполняющих преобразования. Следует отметить, что модели потоков данных четко демонстрируют совместную переработку нескольких потоков данных и последствия этого процесса. Это средство
часто используется при интервьюировании клиентов, потому что очень просто набросать диаграмму потоков данных на доске при обсуждении того, как работает бизнес пользователя.
Диаграммы потоков данных рекоменду-
Когда
использовать?
ется использовать в следующих случаях:
для обнаружения пропущенных требо-
ваний к данным;
определения функциональных требований, поскольку диаграммы
потоков данных описывают
, как пользователь выполняет свои задачи.
Дополнительно в диаграммах «сущность – связь» и в словаре данных полезно представить данные, поступающие в систему от внешних
сущностей.
Диаграммы потоков данных помогают участникам проекта лучше
понять друг друга, поэтому команды могут при необходимости разрабатывать дополнительные правила построения этого типа моделей анализа данных.
Процессы принято обозначать круж-
Правила
построения модели
потоков данных
ком, хранилища данных – прямоугольником, потоки данных – стрелками.
Разрешены переходы потоков дан-
ных от одного процесса к другому только
через хранилище данных или от одного хранилища данных к другому
только через процесс.
26
Диаграммы потоков данных не предназначены для описания эта-
пов процесса.
Рекомендуется для имен процессов использовать шаблон «дей-
ствие (глагол) + объект» (например, «Создать список покупок»). Нужно
использовать термины, которые заинтересованные лица используют в
своих предметных областях. Подобные термины и их синонимы указывают в словаре проекта.
Рекомендуется в
именах процессов использовать шаблон: [номер
уровня детализации] + [порядковый номер на своем уровне детализации]. Процессам нужно присваивать уникальные номера согласно
иерархии.
На одном уровне диаграммы потоков данных продуктивно разме-
стить 8–10 процессов. Диаграммы с большим количеством процессов
трудно анализировать. Это правило можно реализовать, используя метод декомпозиции для процессов.
Следует особо тщательно анализировать процессы, которые
имеют или только входящие, или только исходящие потоки данных,
чтобы исключить возможные неточности в описании процесса преобразования данных в системе.
При анализе диаграммы потока данных важно убедиться, что на ней
отображены все известные и относящиеся к делу процессы и что у них
нет
отсутствующих или ненужных входящих или исходящих потоков.
Чаще всего при анализе диаграммы потоков данных выявляются новые группы пользователей, процессы и связи с другими системами.
Полезным видом диаграммы потока данных
Контекстная
диаграмма
является контекстная диаграмма, которая представляет всю исследуемую систему как единое
целое (один процесс) в виде кружка. Это самый
высокий уровень
обобщения описания исследуемой системы в моделях
анализа.
Контекстная диаграмма показывает информационные и материальные связи системы с внешними объектами. Информационные потоки на
контекстной диаграмме часто представляют сложные структуры данных, определенные в словаре данных.
В приложении 4 приведен пример диаграммы потоков данных для
системы из приложения 3.
27
22. Какая модель анализа может пошагово представить
описание процессов исследуемой системы, а также участвующих
в них лиц или устройств?
Для этой цели используют диаграммы swimlane, которые отличает
простота понимания и соответственно частое использование для описания процессов и взаимодействия между пользователем и системой.
Для пошагового описания процессов в диаграммах используют следующие
обозначения:
прямоугольники представляют шаги процесса;
стрелки показывают переходы между шагами процесса;
ромбы с несколькими исходящими ветками и надписями иллю-
стрируют условия и принимаемые решения;
горизонтальные или вертикальные линии выделяют дорожки
(swimlane), которые задают роли, подразделения или системы, выполняющие непосредственно действия на данном шаге процесса.
Использование
диаграммы
swimlane
Диаграммы этого
в семинарах с заинтересованными лицами
для выявления детальных требований на
каждом шаге анализируемого процесса,
типа используют
а также для описания процессов, выделен-
ных в диаграмме потоков данных кружками.
Диаграммы swimlane иногда называют межфункциональными диаграммами. Они похожи на UML-диаграммы действий и помогают связать вместе функциональные требования, которые позволяют пользователям
выполнять определенные задачи.
В приложении 5 приведен пример частичной диаграммы swimlane
для системы заказов химикатов (описание системы см. в приложении 3).
23. Как полно без пропусков представить разрешенные
и запрещенные изменения состояний исследуемой системы?
Понимание поведения системы существенно облегчается, если
в спецификации представлено полное описание возможных состояний системы и переходов между ними. Обеспечить
такой вариант
описания на естественном языке сложно. Чаще получается фрагментарное описание с пропусками некоторых состояний.
28
Диаграмма переходов состояний (swimlane) позволяет получить
полное и недвусмысленное представление о состояниях объекта или системы и возможных переходах между ними.
В унифицированном языке моделирования UML, который моделирует состояния объекта в течение его жизненного цикла, есть полезный
инструмент – диаграмма состояний. На диаграмме используются следующие обозначения:
1) прямоугольники показывают возможные состояния
системы;
2) стрелки между состояниями (прямоугольниками) задают разре-
шенные переходы;
3) каждая стрелка имеет текстовое пояснение, указывающее на со-
бытия или условия, вызывающие соответствующий переход;
4) диаграмма переходов состояний может иметь несколько конеч-
ных состояний. У конечных состояний есть входящие стрелки переходов, но нет исходящих.
Заинтересованные лица могут понимать диаграммы переходов
со-
стояний и работать с ними после небольшого инструктажа.
Диаграммы переходов состояний помогают найти пропущенные,
лишние или неверные состояния и переходы и скорректировать требования. Это сложнее сделать, оценивая функциональные требования.
Модели анализа предоставляют менее детализированную информацию, но нередко такой вариант представления информации обеспечивает обнаружение проблем в описании
исследуемой системы, что отражается на качестве требований. Различные модели анализа описывают
исследуемую систему на разных уровнях детализации, дополняя друг
друга.
Все возможные переходы между состояниями можно определить
с помощью таблиц состояний в виде матрицы.
Все состояния записывают в первом
Правила построения таблицы
состояний
столбце и повторяют в первой строке. Содержимое ячейки на пересечении
столбца
и строки указывает на возможность перехода из состояния, заданного в левом
столбце, в состояние, заданное в верхней строке матрицы, а также указывает событие перехода между состояниями.
Диаграмма переходов состояний дает возможность тестировщикам разработать тесты на ранних стадиях проектирования продукта,
что способствует успеху проекта в целом. Эта
модель анализа дает
29
возможность проверить в функциональных требованиях полноту и
правильность представления всех возможных состояний системы и
переходов между ними.
В приложении 6 приведены примеры частичной диаграммы переходов состояний и таблицы состояний для системы заказов химикатов
(описание системы см. в приложении 3).
24. Как можно в графической форме представить
дизайн пользовательского интерфейса?
Дизайн пользовательского
интерфейса на высоком уровне абстракции представляет карта диалоговых окон. Высокий уровень абстракции
нужен на ранних стадиях разработки продукта для получения целостного представления о дизайне.
Карта диалоговых окон включает в себя элементы диалоговых окон
в системе и навигационные связи между ними без подробного дизайна
экранов.
Важно!
Полезным является подход, когда пользователь
ский интерфейс рассматривается как набор изменений
-
состояний. В данный момент активным может быть
только один элемент окна, например, меню, рабочая область, диалоговое
окно или командная строка. У пользователя есть возможность начать работу с любым определенным в окне элементом. Важно, что все возможные пути навигации можно определить, несмотря на
их большое количе-
ство и сложность в некоторых случаях.
Для того чтобы выработать общее пред-
Правила использования карт
диалоговых окон
ставление разработчиков и пользователей
о взаимодействии пользователя с продуктом
для выполнения его задач, им нужно изучать
карты диалоговых окон. Для моделирования
визуальной архитектуры веб-сайта тоже используют этот тип моделей
анализа. Ссылки для перемещений по веб
-сайту представляют как переходы. При этом возможности перемещения с помощью поля ввода URLадреса или кнопок «Вперед» и «Назад» не показывают.
Для выявления отсутствующих, неправильных или ненужных требований пользователям нужно определить отсутствующие, неправильные или ненужные переходы на картах диалоговых окон. Такая карта,
проанализированная и отредактированная вместе с требованиями,
30
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]