Юзабилититестирование программного

• Название: Юзабилититестирование программного
• Дата: 16.09.2022
• Размер: 0.61 Mb.
• Имя файла: Mejennaya_TPO.docx
• Тип: Документы; #679821
• страница: 3 из 10

Лабораторная работа №2 Разработка требований

Цель: выявить и описать пользовательские требования в виде вариантов ис- пользования (Use Cases).
Планзанятия:

1. 
   Изучить теоретические сведения.
   
2. 
   Выполнить практическое задание по лабораторной работе.
   
3. 
   Оформить отчет и ответить на контрольные вопросы.
   

Теоретическиесведения

Требование (Requirement) – описание того, какие функции и с соблюдением каких условий должен выполнять программный продукт в процессе решения по- лезной для пользователя задачи.

Требования позволяют понять, что и с соблюдением каких условий система должна делать; предоставляют возможность оценить масштаб изменений и управ- лять изменениями; являются основой для формирования плана проекта (в том числе плана тестирования); помогают предотвращать или разрешать конфликтные ситуации; упрощают расстановку приоритетов в наборе задач; позволяют объек- тивно оценить степень прогресса в разработке проекта.

Работа над требованиями включает следующие этапы: выявление требований; анализ требований (моделирование бизнес-процессов, прототипирование интер- фейсов, приоритизация требований, результат этапа – визуализация требований); документирование требований (результат этапа – спецификация); тестирование (валидация) требований. Работу с требованиями на этапах выявления, анализа, до- кументирования, как правило, выполняет бизнес-аналитик. Тестирование требова- ний выполняет тестировщик.

В иерархии требований существует три уровня: уровень бизнес-требований, уровень пользовательских требований, уровень продуктных требований (функци- ональные и нефункциональные требования).

Бизнес-требования выражают цель, ради которой разрабатывается продукт (зачем он нужен, какая от него ожидается польза).

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

15

использованы для оценки объема работ, стоимости проекта, времени разработки. Пользовательские требования оформляются в виде вариантов использования (Use Cases), пользовательских историй (User Stories), пользовательских сценариев (User Scenarios).

Функциональные требования описывают поведение системы, т. е. ее действия (вычисления, преобразования, проверки, обработку и т. д.). Нефункциональные требования описывают свойства системы (удобство использования, безопасность, надежность, расширяемость и т. д.), которыми она должна обладать при реализа- ции своего поведения.

Выявлениеиописаниетребований:UseCase

Вариант использования (Use Case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица. Действующим лицом может быть человек, другая система ПО или аппаратное устройство, взаимодей- ствующее с системой для достижения некой цели.

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

Описание варианта использования включает следующие категории:

• 
  уникальный идентификатор;
  
• 
  имя, кратко описывающее задачи пользователя в формате «глагол + объ- ект», например «разместить заказ»;
  
• 
  краткое текстовое описание на естественном языке;
  
• 
  список предварительных условий, которые должны быть удовлетворены до начала разработки варианта использования;
  
• 
  выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования;
  
• 
  пронумерованный список действий, иллюстрирующий последователь- ность этапов взаимодействия лица и системы от предварительных условий до вы- ходных условий.
  

Пример варианта использования приведен в таблице 2.1.


16

Таблица 2.1 – Пример варианта использования

Категории варианта использования	Описание
1	2
Идентификатор и название	UC-1 Запросить химикат
Основное действующее лицо	Сотрудник, разместивший заказ на химикат
Описание	Сотрудник, разместивший заказ на химикат, указывает в запросе необходимый химикат, вводя его название или идентификатор или импортируя его структуру из со- ответствующего графического средства. Система выполняет запрос, предлагая контейнер с химикатом со склада или позволяя создать запрос на заказ у поставщика
Триггер	Сотрудник указывает, что хочет заказать химикат
Предварительные условия	PRE-1. Личность пользователя аутентифицирована. PRE-2. Пользователь имеет право запрашивать химикаты. PRE-3. База данных по запасам химикатов доступна
Выходные условия	POST-1. Запрос сохраняется в Chemical Tracking System. POST-2. Запрос отправлен на склад химикатов или поставщику
Нормальное направление развития варианта использования	Запросить химикат со склада Сотрудник указывает требуемый химикат. Система перечисляет контейнеры с необходимым химиктом, имеющиеся на складе. Сотрудник может просмотреть историю любого контейнера. Сотрудник выбирает определенный контейнер или просит отправить запрос поставщику (см. п. 1.1). Сотрудник вводит остальную информацию, чтобы завершить запрос. Система сохраняет запрос и отправляет его на склад химика- тов

17

Продолжение таблицы 2.1

1	2
Альтернативное направление развития варианта использования	Запросить химикат у поставщика Сотрудник ищет химикат по каталогам поставщика (см. п. 1.2). Система отображает список поставщиков, где также указаны размеры, класс и цена контейнеров. Сотрудник выбирает поставщика, размер, класс и количество контейнеров. Сотрудник вводит остальную информацию, необходимую для запроса. Система сохраняет запрос и перенаправляет его поставщику
Исключения	Химиката нет в продаже Система отображает сообщение «У поставщиков нет такого химиката». Система предлагает сотруднику запросить другой химикат или выйти из программы. 1.2.3.1 Сотрудник просит запросить другой химикат (см. п. 1.2.3.2). 1.2.4.1 Система заново начинает нормальное направление варианта использования. 1.2.3.2 Сотрудник решает выйти из системы. 1.2.4.2 Система завершает вариант использования
Бизнес-правила	BR-28, BR-31

Существует несколько сценариев варианта использования (см. таблицу 2.1). Один сценарий считается нормальным направлением развития (normal course)

варианта использования, его также называют основным направлением, главным успешным сценарием и благоприятным путем. Нормальное направление для вари- анта использования «Запрос химиката» – запрос химиката, который есть на складе.

Другие допустимые сценарии из варианта использования называются альтер- нативными направлениями (alternative courses) или вторичными сценариями (sec- ondary scenarios). Они также могут привести к успешному выполнению задания и удовлетворяют выходным условиям варианта использования. Однако они пред- ставляют вариации решения задачи или диалоговой последовательности, необхо- димой для выполнения задачи. В определенной точке принятия решений в диало- говой последовательности нормальное направление может перейти в альтернатив- ное, а затем вернуться обратно в нормальное.

Условия, препятствующие успешному завершению задания, называются ис- ключениями (exceptions). Если в процессе сбора информации не указано, как об- рабатывать исключение, то возможны два пути:
18

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

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

Расширение(extend)ивключение(include)

При составлении вариантов использования часто можно столкнуться с ситуа- цией, когда альтернативное направление варианта использования само по себе можно выделить в автономный вариант использования. В таком случае можно расширить (extention) нормальное направление, включив этот отдельный вариант использования в нормальный поток.

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

Иногда же несколько вариантов использования имеют общие наборы этапов. Чтобы избежать повторения этих этапов в каждом варианте использования, можно определить отдельный вариант использования и указать, что он включен (include) в другие варианты использования как подвариант.

Пример. Если покупатель совершает покупку товара, то он обязательно дол- жен его оплатить. При этом процесс оплаты сам по себе достаточно сложный, включающий различные шаги и альтернативные варианты (оплата различными способами). Поэтому логично его выделить в отдельный вариант использования, при этом включить в вариант использования «Покупка товара».

Определениевариантовиспользования

Определить варианты использования можно несколькими способами:

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

19

гировать, а затем соотнести эти события с участвующими лицами и определенны- ми вариантами использования;

• 
  определить вероятные варианты использования на основе функциональ- ных требований; если какие-либо требования невозможно проследить до какого- либо варианта использования, необходимо задуматься, нужны ли они.
  

Как правило, пользователи сначала определяют самые важные варианты ис- пользования, поэтому порядок предлагаемых тем позволит получить представле- ние о приоритетах.

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

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

Существуют также и преимущества технического характера. С помощью ва- рианта использования можно выявить некоторые важные объекты предметной об- ласти и их взаимоотношения. Разработчики, использующие объектно- ориентированные методы проектирования, могут преобразовать варианты исполь- зования в объектные модели, такие как диаграммы классов и диаграммы последо- вательностей.
Практическоезадание:

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

20

3. 
   Полностью описать три варианта использования подлежащего разработке программного продукта.
   
4. 
   Для каждого варианта использования указать уникальный идентификатор; имя в формате «глагол + объект»; краткое текстовое описание; предварительные условия; выходные условия; пронумерованный список действий нормального направления развития.
   
5. 
   Для каждого варианта использования при необходимости указать прону- мерованный список действий альтернативного направления (направлений) разви- тия.
   

ния.

6. 
   Для каждого варианта использования при необходимости указать исключе-
   

7. 
   Оформить отчет и защитить лабораторную работу.
   

Содержаниеотчета:

1. 
   Цель работы.
   
2. 
   Описание вариантов использования подлежащего разработке программно- го продукта.
   
3. 
   Выводы по работе.
   

Контрольныевопросы:

1. 
   Что такое требование?
   
2. 
   Какое значение имеют требования в проекте по разработке программного обеспечения?
   
3. 
   Какие существуют этапы работы над требованиями?
   
4. 
   Кто выполняет работу с требованиями?
   
5. 
   Какие существуют уровни требований?
   
6. 
   Что такое вариант использования?
   
7. 
   Для чего нужен вариант использования?
   
8. 
   Какие элементы входят в состав описания варианта использования?
   
9. 
   Что такое основной сценарий варианта использования?
   
10. 
    Что такое альтернативный сценарий варианта использования?
    
11. 
    Что описывают в исключениях варианта использования?
    
12. 
    В чем отличие альтернативного сценария от исключения в описании вари- анта использования?
    

21