Технология управления требованиями с использованием IBM

требованиями к программному обеспечению (software requirements management) — процесс, включающий идентификацию, выявление,

документирование, анализ, отслеживание, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.
Цель управления требованиями состоит в том, чтобы гарантировать что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц.
Требование определяется как «условие или особенность, которой должна удовлетворять система». Требованием может быть:
Функциональность, необходимая заказчику или пользователю для разрешения проблем (или получения прибыли).
Функциональность, которая должна быть реализована в системе в соответствии с контрактом, стандартом, спецификацией, инструкцией или другим официальным документом.
Ограничение, наложенное заинтересованным лицом.

что организация документирует, проверяет и удовлетворяет потребности и ожидания её

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

оказывает влияние разрабатываемая система.
Два главных типа заинтересованных лиц –

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

(как в процессе разработки, так и после его завершения), а

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

могут быть разделены на различные типы. Несколько типов требований, наиболее

часто использующихся в проектах:
Потребности заинтересованного лица: требование от заинтересованного лица.
Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика.
Сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий.
Дополнительное требование: другое требование (обычно нефункциональное), которое не может быть охвачено сценариями использования.
Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов.
Сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования.

находятся функциональные особенности, сценарии использования и дополнительные требования. Достаточно часто

на разных уровнях этих требований могут быть выяснены детали различного уровня.
Чем ниже уровень, тем более детально описывается требование. Например, потребность может быть следующей: «Данные должны быть неизменными». Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных».
На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle 9i». Чем дальше вниз, тем более детальным становится требование.
Один из лучших способов управления требованиями – обобщать требования, по крайней мере, на двух различных уровнях. Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне.

бизнес-аналитиков.
Главное отличие между потребностями и функциональными особенностями – в

источнике требований. Потребности поступают от заинтересованных лиц, а функциональные особенности формулируются бизнес-аналитиками.
Роль тестовых сценариев – проверить, корректно ли были реализованы сценарии использования и дополнительные требования. Алгоритмы помогают получить сценарии использования из тестовых сценариев, а также способствуют проектированию и реализации определенных путей через сценарии использования.
В RequisitePro можно определить многие другие типы требований, такие как термины справочника и действующие лица. Они не являются в чистом виде требованиями, подходящими под приведенное определение требований. Но если их представить их в RequisitePro в качестве требований, то мы получим возможность отслеживать их атрибуты и трассировку (связь), используя те же механизмы, применяемые к остальным типам требований.

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

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

Все, что требовал заказчик, было реализовано.
Подтверждение, что приложение делает только

то, что было заказано: Не реализовывать то, что заказчик никогда не просил.
Анализ воздействия: Какие элементы будут затронуты при добавлении новых требований или изменении текущих?
Помощь в управлении изменениями: Когда некоторые требования изменяются, мы хотим знать, какие тестовые сценарии должны быть изменены, чтобы протестировать данное изменение.
Элемент трассировки – это элемент проекта, который должен быть получен (трассирован) из другого элемента. В терминах RequisitePro под ним понимается все, что принадлежит какому-либо типу требований.
Примеры типов требований в RequisitePro: потребности заинтересованных лиц, функциональные особенности, сценарии использования, действующие лица и термины справочника. В RequisitePro есть очень удобный способ отображения трассировки (связи) с помощью специальных представлений (views).

считаться «хорошим требованием» оно должно иметь следующие характеристики:
Помимо этих критериев

для отдельных требований и для набора требований применяются три критерия. Требования должны быть:
Постоянными.
Немногословными.
Завершенными.

в виде неопределенных акронимов. Например:
Треб.1: Система должна быть реализована с

использованием ASP.
Что значит ASP – Active Server Pages или Application Service Provider? Для разрешения этой ситуации, нкжно указать полное наименование и предоставить акроним в скобках:
Треб.1: Система должна быть реализована с использованием Active Server Pages (ASP).
Другой пример:
 Треб.1: Система не должна принимать пароли более 15-ти символов.
Не совсем ясно, что система должна делать:
Система не должна позволять пользователю вводить более чем 15 символов.
Система должна отсекать введенную строку до 15-ти символов.
Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.
Исправленное требование содержит пояснение:
 Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.

реализовано корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы

быть пригодным для тестирования, требование должно быть ясным, точным и недвусмысленным. Использование некоторых слов может сделать требование невозможным для тестирования:
Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.
Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Такие требования могут выглядеть примерно следующим образом:
Треб.1: Функция поиска должна позволять пользователю искать заказ на основе Фамилии, Имени, Даты, и т.д.
В этом требовании все критерии поиска должны быть детально перечислены. Дизайнер и разработчик не могут догадаться, что пользователь имел в виду под сокращением «и т.д.».

или информации. Они должны быть изложены кратко и просто:
Треб.1: Иногда

пользователь будет вводить Airport Code (Код Аэропорта), который система будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города.
Это предложение может быть заменено на более простое:
Треб.1: Система должна идентифицировать аэропорт на основании Airport Code (Кода Аэропорта) или City Name (Названия Города).

Корректность

Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цены на аренду машин должны включать все соответствующие налоги (включая налог штата - 6%)
Налог зависит от штата, так что представленная цифра в 6 % - некорректна.

быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо

«будет», «обязан» или «может».

Правдоподобность (Реальность, Выполнимость)

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

Независимость

Чтобы понять требование, не нужно знать какое-либо другое требование.
Треб.1: Список доступных рейсов должен включать номер рейса, время отправления и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно.

связи):
Треб.1: Система должна предоставлять возможность бронировать рейс, покупать билет,

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

Необходимость

В требовании нет необходимости, если:
Ни одному заинтересованному лицу требование не нужно.
или
Удаление требования не повлияет на систему.
Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы.

дизайне и реализации системы:
Треб.1: Информация должна храниться в текстовом

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

Постоянство

Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные.
Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации:
Треб.1: Дата должна отображаться в формате мм/дд/гггг.
Треб.1: Дата должна отображаться в формате дд/мм/гггг.

должно перекрываться другим требованием:
Треб.1: Для удобства ввода даты рейса в

системе должен быть доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.
Первое требование (относящееся только к дате рейса) является частью второго требования (относящееся к любой дате, вводимой пользователем).

Завершенность

Требование должно быть описано для всех возможных условий:
Треб.1: Страна назначения не должна отображаться для рейсов в пределах США.
Треб.2: Для рейсов через море система должна отображать страну назначения
Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев:
Изменяемый: Если требование элементарное и немногословное, то оно обычно изменяемое.
Трассируемое: Если оно краткое и имеет уникальный идентификатор (ID), то оно обычно трассируемое (способное к отслеживанию связи).

следующие основные пункты:
Формирование плана управления требованиями.
Сбор требований.
Разработка документа Концепции (Vision).
Создание

сценариев использования (Use Cases).
Дополнительная спецификация.
Создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases).
Создание тестовых сценариев (Test Cases) из дополнительной спецификации.
Проектирование системы.
Первый шаг (план управления требованиями) определяет пирамиду требований. На каждом из последующих семи шагов строится один элемент пирамиды.

полное прохождение по пирамиде. На любой итерации мы можем вернуться

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

– это разработка Плана Управления Требованиями (Requirements Management Plan –

RMP). RMP содержит в себе общие подходы к управлению требованиями в проекте. Документ детально описывает, каким образом создаются требования, как они упорядочиваются, изменяются и отслеживаются в течение жизненного цикла проекта.
Несколько вопросов, на которые может ответить документ RMP:
Будет использоваться инструмент для управления требованиями?
Какие типы требований будут присутствовать в проекте?
Каковы атрибуты этих требований?
Где будут создаваться требования – в базе данных или в документах?
Между какими требованиями должна осуществляться трассировка?
Какие документы необходимы?
Какие требования и документы будут использоваться как контракт с заказчиком?

будут использоваться как контракт со сторонними разработчиками?
Нужно следовать RUP или

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

это сценарии использования (use cases). Они извлекаются из функциональных особенностей.
Сценарий

использования – это описание системы в терминах последовательности действий. Он должен иметь значимый результат или определенное значение для действующего лица (действующее лицо – это некто или нечто, взаимодействующее с системой).
Сценарии использования:
Инициируются действующим лицом.
Являются моделью взаимодействий между действующим лицом и системой.
Описывают последовательность действий.
Содержат в себе функциональные требования.
Должны иметь некоторое значение для действующего лица.
Представляют полный и имеющий смысл сценарий событий.
Назначение сценариев использования - способствовать соглашению между разработчиками, заказчиками и пользователями на тему того, что именно система должна делать. Сценарий использования становится своего рода контрактом между разработчиками и заказчиками. Он также является основой для реализации сценариев использования, которые играют большую роль в проектировании системы.

способность к сопровождению), а также некоторые функциональные требования, распространяющиеся за

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

Создание Тестовых Сценариев (Test Cases) из Сценариев Использования

Как только все требования собраны, следует разработать способ проверить, правильно ли они реализованы в конечном продукте. Тестовые сценарии (test cases) показывают тестерам, какие шаги должны быть сделаны для того, чтобы протестировать все требования. На этом шаге следует концентрироваться на создании тестовых сценариев из сценариев использования.

RMP).
RMP содержит в себе общие подходы к управлению требованиями в

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

Когда Создается Документ RMP (пример)
RMP может быть создан из включенного в RequisitePro шаблона. Однако для создания проекта в RequisitePro, нужно зафиксировать решения в документ RMP. Мы можем решить эту проблему следующими способами:
Подход 1.
Принимаются все решения относительно требуемых документов и типов требований, но они не оформляются документально в RMP.
Создается проект RequisitePro.
Документ RMP создается из шаблона RequisitePro.
Подход 2.
Документ RMP создается в Microsoft Word. Он по-прежнему содержит все пункты из шаблона RequisitePro, но создается вне инструмента.
Создается проект RequisitePro на основе RMP.
Документ Microsoft Word c RMP импортируется в RequisitePro.

Как собираются эти требования, рассмотрено в лекц. 2.
Разработка Документа

Концепции (Vision)
Рассмотрено в лекц. 2.
Создание Сценариев Использования (Use Cases)
Наилучшая форма описания функциональных требований – это сценарии использования (use cases). Они извлекаются из функциональных особенностей.
Сценарий использования – это описание системы в терминах последовательности действий. Он должен иметь значимый результат или определенное значение для действующего лица. Сценарии использования:
Инициируются действующим лицом.
Являются моделью взаимодействий между действующим лицом и системой.
Описывают последовательность действий.
Содержат в себе функциональные требования.
Должны иметь некоторое значение для действующего лица.
Представляют полный и имеющий смысл сценарий событий.

способность к сопровождению). А также некоторые функциональные требования, распространяющиеся за

пределы системы, и вследствие этого, сложные для отображения в сценариях использования.

Проектирование Системы
Требования являются основой для проектирования системы, которое чаще всего сопровождается использованием Универсального Языка Моделирования – Unified Model Language (UML). Для этого могут быть применены инструменты, такие как Rational Rose, Rational Software Architect, Rational Data Architect и Rational Software Modeler.
Один из подходов заключается в одновременном создании диаграмм взаимодействия из алгоритмов и определении функциональности классов.

управления требованиями. Он позволяет вводить, обновлять, отслеживать и просматривать требования

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