Для выявления требований чаще всего используются следующие техники:

• 
  Интервью (либо переписка) – опрос, часто в формате вопрос ответ между аналитиком и заказчиком / пользователем
  
• 
  Фокусные группы – расширенное интервью с несколькими пользователями
  
• 
  Мозговой штурм – позволяет за короткий промежуток времени собрать большое количество идей, которые в дальнейшем изучаются и анализируются
  
• 
  Наблюдение – позволяет выявить процессы, о которых не упомянули в интервью, занимает много времени
  
• 
  Прототипирование – один из лучших способов понять и уточнить требования
  

Так же существуют более сложные методы, при котором аналитик должен «сам во всем разобраться», и уточнить собранную информацию у заказчиков:

• 
  Анализ документов
  
• 
  Моделирование процессов
  
• 
  Самостоятельное описание
  

Классификация требований (типы и уровни требований)

Существует значительное количество различных методов классификации требований, рассмотрим требования, используя терминологию, аналогичную рассмотренной в книге Карла Вигерса "Разработка требований к программному обеспечению".

Почти в каждом проекте существует 3 заинтересованных стороны:

• 
  Заказчики продукта
  
• 
  Пользователи продукта
  
• 
  Разработчики продукта
  

Все они смотрят на «продукт» со своей колокольни, следовательно, требования разделяются на соответствующие группы или уровни.



Рисунок 1 - Представление продукта разными группами

Уровень заказчика (бизнес-требований)

На этом уровне находится только один тип требований – бизнес требования (business requirements).

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

Основываясь на этих требованиях можно получить общее видение проекта.

Уровень пользователя

Описывают “взгляд” на продукт глазами пользователя.

Включает в себя:

• 
  Пользовательские требования (user requirements) — описание задач, которые может выполнять пользователь при помощи системы. Оформляются в виде пользовательских историй (user stories, cases, scenarios). Эти требования могут быть использованы для оценки времени, сложности, стоимости разработки.
  
• 
  Бизнес правила (business rules) — описывают особенности принятых в предметной области процессов, ограничений, правил.
  
• 
  Атрибуты качества (quality attributes) — описывают ключевые показатели качества продукта.
  

---

Уровень разработки (требований продукта)

Содержит наиболее детализированное описание функций продукта, которые должны быть реализованными.

Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.

К уровню разработки относятся следующие типы требований[19]:

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

Примеры: 

• 
  «API метод должен возвращать список ресторанов в короткой форме: id, название, адрес» или «Никакая личная информация пользователя (логин, пароль, номера телефонов, и тд.) не должна отображаться в отчетах» - это функциональные требования, они описывают поведение системы.
  
• 
  «Объем используемой оперативной памяти не должен превышать 256 Мб» или «Все данные системы должны храниться в БД под управлением СУБД MySQL» - это нефункциональные требования, они описывают свойства системы.
  

Разработка и управление требованиями (выявление требований)



Рисунок 2 - Разработка и управление требованиями

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

Выявление и сбор требований (elecitation)

Этот этап включает в себя все действия, связанные с выявлением требований, таких как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся:

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

---

Анализ требований[19]

Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:

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

Документирование

Представление и хранение знаний о требованиях определенным способом. Например, в письменные требования, диаграммы пригодные для дальнейшего использования.

Утверждение требований

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

Нельзя создать идеальные требования. Если смотреть с практической точки зрения, то цель разработки требований — накопить общее понимание требований необходимое для разработки очередной порции продукта.

Управление требованиями[19]

Это процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, установку приоритета требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.

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

---

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

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

1.4 ТЕСТИРОВАНИЕ ТРЕБОВАНИЙ, ТЕХНИКИ РАБОТЫ С ТРЕБОВАНИЯМИ

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

Тестирование требований выполняется на предмет их соответствия критериям качества требований (рисунок 3) [10]. 



Рисунок 3 - Критерии качества требований

Завершённость (completeness)

Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». 

Типичные проблемы с завершённостью: 

• 
  Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (пример: «пароли должны храниться в зашифрованном виде», а каков алгоритм шифрования?). 
  
• 
  Указана лишь часть некоторого перечисления (пример: «экспорт осуществляется в форматы PDF, PNG и т.д.», а что следует понимать под «и т.д.»?). 
  
• 
  Приведённые ссылки неоднозначны (пример: «см. выше» вместо «см. раздел 123.45.b»).
  

---

Атомарность, единичность (atomicity)

Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости, и оно описывает одну и только одну ситуацию.

Типичные проблемы с атомарностью: 

• 
  В одном требовании, фактически, содержится несколько независимых (пример: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя»: здесь в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах).
  
• 
  Требование допускает разночтение в силу грамматических особенностей языка (пример: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату»: здесь описаны три разных случая, и это требование стоит разбить на три отдельных требования во избежание путаницы). Такое нарушение атомарности часто влечёт за собой возникновение противоречивости.
  
• 
  В одном требовании объединено описание нескольких независимых ситуаций (пример: «когда пользователь входит в систему, должно отображаться приветствие; когда пользователь вошёл в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание»: все эти три ситуации заслуживают того, чтобы быть описанными отдельными и более детальными требованиями) [10]. 
  

Непротиворечивость, последовательность (consistency)

Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

Типичные проблемы с непротиворечивостью: 

• 
  Противоречия внутри одного требования (пример: «после успешного входа в систему пользователя, не имеющего права входить в систему…»: а как пользователь вошёл в систему, если не имел такого права?).
  
• 
  Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (пример: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей»: так всё же красной или синей?). 
  
• 
  Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (пример: «в случае, если разрешение окна составляет менее 800x600…»: разрешение есть у экрана, у окна есть размер) [10]. 
  

Недвусмысленность (unambiguousness, clearness)

---

Смотрите также файлы

• Все мы едины, все мы оренбургцы так писал поэт и общественный деятель Гавриил Романович Державин.docx

• Протокол от 2022г. Рассмотрено на педагогическом совете Протокол .docx

• Отчет по производственной практике (по профилю специальности) Лит. Листов 100 втжт филиал ргупс содержание.pdf

• 10кл. Бжб2. Жер планетасындаы ауіпті алдытар, леуметтік тесіздік адам ытары жне кмек.docx

• Седьмая.docx