Вступление
Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.
Классификация требований
В нашей компании принята следующая терминология в отношении требований:
- Бизнес-требования
Требования самого высокого уровня, которые определяют цель создания сайта и задачи, которые необходимо выполнить для достижения цели. Бизнес-требования определяются следующей метафорой: «Сайт как инструмент бизнеса, как его часть. Сайт – как лицо компании, как инструмент продаж и развития бизнеса». - Требования участников проекта
Требования, которые определяют, как представители компании-заказчика будут взаимодействовать с сайтом, что им нужно от сайта. Метафора: «Сайт как неотъемлемая часть бизнес-процессов в компании. Сайт как помощник сотрудникам». - Требования внешних пользователей
Требования, которые определяют, как внешние пользователи будут взаимодействовать с сайтом, и что им может потребоваться как посетителям ресурса и потенциальным клиентам компании. Метафора: «Сайт как инструмент продаж товаров и услуг компании через Интернет».
Бизнес-процесс по созданию клиентского сайта
Базовый бизнес-процесс по созданию клиентского сайта в нашей компании выглядит следующим образом:
- После получения заявки на разработку сайта, менеджер связывается с клиентом, уточняет его ценовые ожидания и, если они соответствуют нашим, договаривается о встрече.
- Перед встречей менеджер подготавливается к сбору бизнес-требований: читает информацию о компании заказчика, анализирует действующий сайт (если он существует), анализирует сайты конкурентов; создает примерное представление о том, какой сайт можно предложить клиенту.
- Далее следует очная встреча с клиентом, на которой менеджер занимается сбором бизнес-требований и требований участников проекта. На данном этапе главная задача менеджера состоит в том, чтобы максимально подробно расспросить клиента о бизнес-процессах внутри компании, понять их суть, чтобы затем предложить такой функционал на сайте, который бы позволил увеличить эффективность работы сотрудников компании клиента.
- После очной встречи с клиентом менеджер осуществляет оценку собранных требований на полноту и непротиворечивость.
- Оценка сделана, и менеджер трансформирует требования в описание примерного функционала сайта как совокупности ряда модулей: «Каталог товаров», «Корзина», «Форум» и т. д.
- Функционал будущего сайта согласовывается с клиентом как по содержанию, так и по стоимости. Возможны варианты, когда клиент выбирает для реализации лишь часть функционала.
- Если предварительное соглашение о функционале будущего сайта достигнуто, то менеджер приступает к описанию целевых групп посетителей и описанию сценариев использования сайта посетителями. Данное описание также согласовывается с клиентом.
- На основании согласованных сценариев использования сайта и функциональных модулей менеджер формирует техническое задание, в которое разработчик добавляет техническую информацию (требования к хостингу, например).
- Техническое задание подписывается двумя сторонами, прикладывается к договору, договор оплачивается, и начинается работа.
Схематично бизнес-процесс выглядит следующим образом:
Теперь более подробно рассмотрим, как осуществляет сбор требований на всех этапах работы.
Бизнес-требования
При сборе бизнес-требований определяется окружение сайта (см. рисунок) и анализируется, как данное окружение может использовать сайт и соответственно, какой функционал и информация должны быть представлены на сайте.
Например, бизнес заказчика крупный и постоянно привлекаются инвесторы для финансирования проектов. Соответственно, должен быть раздел на сайте с информацией о проектах компании, о формате возможного участия инвесторов и т.п.
Заметим, что требования сотрудников компании к сайту – это требования участников проекта, они будут рассмотрены в отдельной главе.
При проектировании с учетом бизнес-требований:
- Заказчик начинает фокусироваться на важных вопросах, касающихся целей и задач сайта, а не на том, «что на сайте будет в левом меню». Повышается мотивация и желание сделать хороший продукт.
- Большинство важных требований, которые не лежат на поверхности, выявляются в ходе последовательного прохода по внешнему окружению будущего сайта. Например: «…да, партнерам было бы хорошо предоставить личный кабинет…», «…далее сайт будет продвигаться и seo-специалистам необходимо следующее…», «…компания крупная и нужен хороший раздел с вакансиями…» и т.д.
Требования участников проекта
— это требования сотрудников компании к сайту.
После сбора бизнес-требований необходимо уделить время анализу требований сотрудников компании к сайту. Если клиент уже на встрече может предоставить список таких требований – это замечательно, однако не стоит останавливаться на этом. Важно продолжить диалог и попросить клиента рассказать о бизнес-процессах внутри организации, которой мы делаем сайт.
Важно на встрече не столько придумать все варианты использования сайта сотрудниками, а сколько понять и запомнить бизнес-процессы, а также функциональные обязанности работников, чтобы потом в офисе, в спокойной обстановке поразмыслить над тем, каким образом сайт может помочь сотрудникам.
Основной момент, который стоит подробнее изучить на встрече, – взаимодействие менеджера по продажам с клиентом и какую роль в этом взаимодействии должен играть сайт. Рассмотрим некоторые варианты практического применения сайта менеджером:
- Сайт может помогать менеджеру при непосредственном общении с клиентом – например, менеджер с экрана компьютера демонстрирует клиенту продукцию или услуги компании.
- Менеджер «конструирует» что-то на сайте, например, выбирает для клиента тур в Турцию или рассчитывает стоимость полиса ОСАГО. Частный пример – «конструктор кухонь» на сайте компании Ikea.
- Менеджер часто выезжает на встречу с клиентом на местах и с планшетного компьютера демонстрирует продукцию, представленную на сайте – (для себя мы сразу делаем пометку, что будет важна мобильная версия сайта и интерфейс работы с устройствами с сенсорным экраном).
- Сайт служит для сопровождения клиентов в процессе продажи товара и после. Это такие действия как: всевозможные консультации, отслеживание статуса заявки на покупку товара, обмен файлами, техническая поддержка.
- Во многих случаях менеджеру приходится давать подробные консультации клиентам, и в этом случае на помощь может прийти сайт, где в специальном разделе можно будет разместить справочную информацию. Частный случай: раздел FAQ, где можно посмотреть ответы на основные вопросы и задать свой.
В целом, вариантов использования сайта менеджером по продажам великое множество – ведь товаров и услуг, которые реализуют данные менеджеры, также очень много и в каждом случае – свои особенности процесса продажи. Поэтому, как уже было сказано выше, на встрече с клиентом очень важно получить подробную информацию о том, какие функции выполняют сотрудники, и как они взаимодействуют между собой и – что особенно важно — с клиентами компании.
Пример из жизни.
В нашу компанию обратился клиент, занимающий оптовой продажей мебельных комплектующих: гайки, стяжки, винты и т.п. Как правило, обычный человек не понимает всей специфики данного вида бизнеса. Поэтому в ходе диалога наш менеджер попросил клиента описать процесс продажи товара подробнее.
В данной ситуации, как мы видим, основная работа лежит на менеджере и его действия нельзя заменить каким-либо функционалом на сайте. В связи с эти было принято простое решение: на сайте организуется витрина товаров (все товары переносятся из электронных каталогов на сайт), покупатель выбирает требуемые товары, точно задает их параметры (размеры, материал покрытия, цвет) и количество и далее простым нажатие кнопки отправляет заявку менеджеру.
Вывод из этого примера достаточно простой: не домысливайте за клиента, а просто просите его подробно рассказать о своей работе.
В том случае, если клиент на встрече затрудняется или просто не желает подробно расписывать бизнес-процессы в компании, можно попытаться разговорить его, предлагая те или иные решения на сайте, которые будут полезны сотрудникам.
Например, можно взглянуть на сайт глазами бухгалтера и выдвинуть следующее требование: «Необходим функционал автоматического выставления счета на оплату».
Варианты потенциальных требований со стороны участников могут быть такими:
- Требования директора по персоналу:
a. «Управление вакансиями на сайте сделать по аналогии с сайтом SuperJob».
b. «Создать внутрикорпоративный портал и базу знаний».
c. «Создать личные странички сотрудников».
d. «Создать возможность проведения вебинаров для сотрудников через сайт». - Требования директора по рекламе, маркетолога:
b. «Сделать возможность выгрузки данных о товарах и услугах».
c. «Создать функционал проведения опросов через сайт».
d. «Создать возможность комментирования и обсуждения товара на сайте».
e. «Организовать кросспостинг материала в социальные сети».
f. «Создать рейтинги товаров». - Требования администратора сайта:
a. «Создать возможность одновременной работы нескольких человек в административном разделе».
b. «Создать функционал автоматического архивирования сайта».
c. «Создать возможность разграничения прав доступа для редакторов сайта». - Пиар-менеджер:
a. «Необходимо использовать фирменный стиль в дизайне, подчеркивать бренд».
b. «Создать функционал «рассылки», «форум», разместить виджеты социальных сетей».
c. «Создать определённые промо-страницы, промо-блоки, аудио-видео, flash». - Бизнес-аналитик:
«Осуществить специальную настройку процесса формирования и отправки заказа, чтобы появилась возможность оценивать конверсию посетителей в покупателей». - Юрист:
«Создать раздел для публикации документов, требующих публичного оглашения». - Представитель службы логистики:
«Создать раздел с подробными картами складов».
Определение целевых групп посетителей и сценарии использования
После того, как были определены бизнес-требования и требования участников проекта, начиная с базовых: «Я как собственник бизнеса хочу начать реализацию товаров и услуг компании через интернет» и заканчивая второстепенными, менеджер нашей компании упорядочивает всю информацию и формирует на ее основе описание основных функциональных модулей будущего сайта.
После согласования с клиентом функционала сайта и бюджета проекта менеджер определяет целевые группы посетителей сайта.
Типичными целевыми группами являются:
- Покупатели
a. Первичные.
b. Вторичные.
c. Не определившиеся.
d. Постоянные. - Соискатели работы.
- СМИ.
- Партнеры.
- Инвесторы.
Далее определяются сценарии использования сайта посетителями. Такими сценариями могут быть:
- Для покупателей:
a. Для первичных: покупка товара, ознакомление с ценами, сравнение товара, получений консультаций.
b. Для вторичных: повторный заказ товара, получение скидки.
c. Для не определившихся: поиск товара, участие в акциях, связь с компанией.
d. Для постоянных: покупка одних и тех же товаров, использование скидок, техподдержка. - Соискатели работы: поиск вакансий, отправка резюме.
- СМИ: импорт новостей, импорт графической информации.
- Партнеры: авторизация на сайте, загрузка прайс-листа, чат с персональным менеджером.
- Инвесторы: информация об акциях компании, графики котировок.
Каждый из этих базовых сценариев подробно расписывается и далее согласовывается с клиентом. Например, сценарий «Отправка резюме» в расширенном виде выглядит следующим образом:
«Для того чтобы отправить резюме, соискатель должен заполнить форму, расположенную на странице с вакансией, и прикрепить к ней сам файл резюме. Описание полей формы приведено в техническом задании».
Даже такие, казалось бы, банальные вещи необходимо описывать, чтобы потом не было претензий со стороны клиента: «А я думал, вы расположите данную форму на всех страницах сайта справа…».
Техническое задание
Техническое задание является конечным документом в процессе подписания договора по созданию сайта. Оно состоит из двух блоков: описание внешней части (дизайн, функционал, варианты использования сайта в т.ч. его функционала) и внутренней (сценарии использования административной части сайта).
Техническое задание состоит из следующих блоков:
- Подробные сценарии использования со стороны заказчика (как представители заказчика взаимодействует с сайтом, например, как менеджер обслуживает через сайт заявки, как менеджер по персоналу публикует вакансии и прочее).
- Описание структуры элементов и набор полей в административной части сайта.
- Структура сайта и навигация по нему (разделы сайта, порядок расположения элементов на типовых страницах).
- Сценарии использования основного функционала (как пользователь может отправить заявку, что получит в ответ, как пользователь использует поиск по сайту и прочее).
- Описание функционала основных модулей
- Компоновка элементов, дизайн (описываются все требования к дизайну)
- Описание работы отдельных сервисов (например, использование калькулятора ОСАГО)
Более подробно останавливаться на написании технического задания я не буду, однако приведу пример того, как требование заказчика в итоге было отражено в техническом задании.
- Представитель клиента озвучил следующее требование: «Хочу удобную систему публикации и представления вакансий на сайте, чтобы было удобно создавать новые вакансии, доставать из архива и активировать старые».
- После беседы с клиентом помимо прочего менеджер выделил функционал «Вакансии», который учел при оценке общей стоимости создания сайта.
- Далее менеджер определил целевые группы: «Соискатели работы» — со стороны посетителей сайта и «HR-менеджер» со стороны участников проекта.
- В итоговом техническом задании изначальное требование приобрело следующий вид:
a. В административном разделе сайта имеется возможность создавать новые вакансии на основе шаблонов, содержащих следующий набор полей: должность/требования/обязанности/зарплата/…
b. Администратор сайта имеет возможность изменить базовый шаблон или создать новый. Соответственно при публикации вакансии имеется возможность выбрать соответствующий шаблон из имеющихся и создать на его основе вакансию.
c. Раздел «Вакансии» расположен в основном разделе «О компании».
d. Список вакансий на странице «Вакансии» имеет табличный вид. Используются поля: «Должность», «Зарплата».
e. При переходе на конкретную вакансию пользователь видит следующее (см. эскиз дизайна).
f. На странице конкретной вакансии пользователь может отправить резюме, которое придет на определенный электронный адрес, а также сохранится в базе данных.
g. Форма отправки резюме имеет следующий вид…
Заключение
После того, как менеджеры нашей компании были обучены вести сбор требований по данной технологии, эффективность реализованных в компании сайтов стала выше. Сайты стали приносить больше пользы как сотрудникам компании клиента, так и посетителям.
А все от того, что мы сами начали лучше понимать заказчика, мы начали строить с ним более содержательные диалоги и более полно собирать требования и учитывать их при проектировании сайта.
Раньше менеджер в основном лишь слушал сумбурную речь заказчика о том, как тот видит главную страницу сайта, и что «нужно звездочками показывать рейтинг товара». Сейчас же менеджер целенаправленно обсуждает с клиентом все аспекты создания сайта, начиная с цели, ради которой создается сайт, и заканчивая описанием использования сайта потенциальными посетителями, а также сотрудниками компании.
Надеюсь, и вам данный материал поможет в процессе работы с заказчиком при разработке сайта.
Бизнес-анализ — это структурированное изучение проблемы, имеющей отношение к бизнесу. Бизнес-анализ проводится, чтобы лучше понять проблему, а затем оценить, что требуется для ее устранения.
Бизнес-кейс/коммерческое предложение. Коммерческая цель или выгода является причиной выполнения проекта и может официально фиксироваться в документе, называющемся бизнес-кейсом, или коммерческим предложением. Этот документ обычно включает финансовые показатели (например, прирост выручки, снижение издержек и т.п.) или другие параметры (например, повышение уровня обслуживания потребителей, повышение мотивированности персонала и т.д.).
Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:
- обязательными, т.е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это — провал;
- желательными. Эти требования не обязательны, но важны для заказчика, поэтому их стараются соблюдать, за исключением тех случаев, когда они влекут за собой неприемлемое увеличение стоимости или продолжительности проекта;
- необязательными — это те требования, без которых заказчик вполне может обойтись и которые удовлетворяются только по возможности.
Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, User Requirements.
Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.
Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы
Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).
Типовая структура требований выглядит как «Система должна … /утверждение о необходимом функциональном поведении системы/» или «система должна позволять … /утверждение о возможности, предоставляемой пользователю или внешней системе/.
Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».
Пример различий между пользовательскими и функциональными требованиями:
Пользовательское: «Система должна выводить отчеты на печать»
Функциональное: «Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги».
Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.
Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.
Схема процесса разработки с уровнями требований
Формирование и анализ требований
Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.
Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечёт за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.
Подготовка к интервью по сбору требований у заказчика
Компания — Бизнес-требования
Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта
Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:
- Описание контекста и списка ключевых заинтересованных лиц
- Описание целей создания системы и критериев достижения
- Ключевые бизнес-требования к решению и их приоритеты
- Существующие и возможные ограничения на решение
Контекст — это то, что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать.
Заказчик — Документ требований заинтересованных лиц
Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:
- Бизнес-назначение
- Бизнес-рамки
- Обзор бизнеса
- Заинтересованные лица
- Организационная среда
- Цели и результаты
- Бизнес-модель
- Информационная среда
- Бизнес-процессы
- Политики и правила
- Ограничения деятельности
- Организационная структура
- Концепция использования системы
- Сценарии эксплуатации
- Проектные ограничения
Пользователь — Требования пользователя
Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик
Эти требования должны определять только внешнее поведение системы, избегая по возможности определения структурных характеристик системы. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм.
Проблемы при формировании пользовательских требований
Отсутствие чёткости изложения. Иногда нелегко изложить какую-либо мысль естественным языком чётко и недвусмысленно, не сделав при этом текст многословным и трудно читаемым.
Смешение требований. В пользовательских требованиях отсутствует чёткое разделение на функциональные требования, на системные цели и проектную информацию.
Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.
Системные требования
Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.
Функциональные требования
Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Стандартные формы для специфицирования функциональных требований:
- Описание функции или объекта.
- Описание входных данных и их источники.
- Описание выходных данных с указанием пункта их назначения.
- Указание, что необходимо для выполнения функции.
- Если это спецификация функции, необходимо описание предварительных условий (предусловий), которые должны выполняться перед вызовом функции, и описание заключительного условия (постусловия), которое должно быть выполнено после завершения выполнения функции.
- Описание побочных эффектов (если они есть).
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Нефункциональных требований
Нефункциональные требования — Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой.
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.
Нефункциональные требования отображают пользовательские требования:
Нефункциональные требования основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика, возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п.
Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
- легкость и простота использования;
- легкость перемещения;
- целостность;
- эффективность и устойчивость к сбоям;
- внешние взаимодействия между системой и внешним миром;
- ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Требования предметной области
Требования предметной области характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не функциональными. Эти требования отображают условия, в которых будет эксплуатироваться программная система. Они могут быть представлены в виде новых функциональных требований или в виде ограничений на уже сформулированные функциональные требования или в виде указаний, как система должна выполнять вычисления. Невыполнение требований предметной области может привести к выходу системы из строя.
Требования к продукту
Требования к продукту описывают эксплуатационные свойства программного продукта. Это требования к производительности системы, объёму необходимой памяти, надёжности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.
Организационные требования
Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.
Требования к интеграции
Требования к интеграции описывают низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Цель данного документа обосновать и формализовать выбор метода интеграции. Документ содержит в себе описание методов и способов интеграции с внешними системами, сервисами.
Интеграция приложений – это технологические процессы, используемые для организации обмена данными между различными информационными системами с помощью средств интеграции, предоставляемыми приложениями. К средствам интеграции, предоставляемыми приложениями относятся API функции, пакеты обработки и экспорта/импорта данных.
Интеграция через ESB
Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:
- Физическое размещение сервисов.
- Размещение адаптеров к информационным системам.
- Предоставление канала для взаимодействия информационных систем.
- Обеспечение независимости от адресов, протоколов и интерфейсов при взаимодействии систем.
- Трансформация данных при взаимодействии.
- Маршрутизация сообщений.
- Обеспечение инфраструктурной функциональности, включая мониторинг, логирование, безопасность, и т. д.
Интеграция точка-точка
Интеграция приложений напрямую, является методом интеграции, при котором взаимодействие между системами происходит без применения универсального централизованного посредника, такого, как сервисная шина предприятия (ESB).
Интеграция данных
Интеграция данных – это процессы пакетного обмена данных между информационными системами, с помощью средств баз данных этих систем или экспорта-импорта файлов.
Задачи интеграции данных:
- Передачи больших объемов данных, включающая логику преобразования данных.
- Синхронизация (репликация) данных информационных систем
Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.
Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.
Требования к пользовательскому интерфейсу
Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:
- требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
- требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.
К первой группе можно отнести следующие типы требований:
- Требования к размещению элементов управления на экранных формах
- Требования к содержанию и оформлению выводимых сообщений
- Требования к форматам ввода
Ко второй группе относятся следующие типы требований:
- Требования к реакции системы на ввод пользователя
- Требования к времени отклика на команды пользователя
Управление требованиями — это процесс управления изменениями системных требований. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется на то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова.
С точки зрения разработки требования можно разделить на два класса.
Постоянные требования. Это относительно стабильные требования, которые исходят из основной деятельности организации и касаются непосредственно предметной области, где будет эксплуатироваться система.
Изменяемые требования. Эти требования отображают изменения, сделанные во время разработки системы или после ввода её в эксплуатацию.
Классификация изменяемых требований
Непостоянные требования — Требования, которые изменяются из-за изменений в окружении системы
Неожиданно возникающие требования — Требования, которые появляются во время разработки системы. В процессе проектирования может возникнуть необходимость добавления новых требований
Непрямые требования — Требования, которые являются результатом внедрения компьютерной системы, способной изменить организационные процессы и показать новые способы работы, которые приведут к новым системным требованиям
Вторичные требования — Требования, которые зависят от особенностей данной системы или от бизнес-проблем организации
Процесс управления изменениями
Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определённые предложения относительно изменений в требованиях.
Анализ осуществимости и расчёт их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.
Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.
Заказчики системы. Определяют требования, проверяют специфицированные требования на соответствие требованиям заказываемой системы. Они могут вносить изменения в спецификацию.
Руководство компании-разработчика. Использую спецификацию для расчёта цены системы и для планирования процесса разработки системы.
Разработчики системы. Используют спецификацию в процессе разработки системы.
Инженеры, тестирующие систему. Используют спецификацию при разработке тестов, необходимых для аттестации системы.
Инженеры поддержки системы. Спецификация помогает разобраться в системе и понять, как взаимодействуют её отдельные компоненты.
Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.
Метрика — измеримая характеристика проекта, продукта или процесса.
Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.
При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.
- Во-первых, надо помнить, что совершенствование процесса ради самого совершенствования бессмысленно. Поэтому спросите себя, действительно ли достижение цели даст искомый рост бизнес-ценности.
- Во-вторых, не стоит разочаровывать членов команды, ставя цели, которые нереально достичь, поэтому нужно хорошенько подумать, достижима ли поставленная цель в вашей среде. Чтобы цель улучшения была разумной, ответ на оба вопроса должен быть положительным.
Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:
- Правильно ли были проанализированы проблемы и выявлены их первопричины?
- Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
- Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
- Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
- Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
- Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?
Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.
Документы процесса разработки требований
- Процесс разработки требований описывает, как определить и классифицировать заинтересованных в проекте лиц в предметной области, а также как планировать действия по выявлению требований. Кроме того, здесь перечислены различные документы, касающиеся требований, модели, которые, как ожидается, будут созданы при выполнении проекта. Процесс разработки требований также определяет особенности анализа и проверки требований.
- Процедура назначения требований описывает, как назначать высокоуровневые требованиям к продукту конкретным подсистемам при разработке систем, состоящих из программных и аппаратных компонентов или множественных программных подсистем.
- Процедура назначения приоритетов требований описывает приемы и инструменты, используемые для определения приоритетов требований и динамической корректировки содержимого резерва в проекте.
- Шаблон документа о концепции и границах проекта помогает куратору проекта и бизнес-аналитику осмысливать бизнес-цели, метрики успех, концепцию продукта и другие элементы бизнес-требований.
- Шаблон вариантов использования задает стандартный формат для описания задач, которые пользователям необходимо выполнять с помощью программы.
- Шаблон спецификации требований к ПО представляет собой структурированный, последовательный способ организации функциональных и нефункциональных требований. Подумайте о возможности применения более чем одного шаблона, чтобы учесть различные типы и масштабы проектов, выполняемые вашей организацией.
- Контрольный список рецензирования требований. Официальное рецензирование документов, содержащих требования, — мощное средство повышения качества ПО. В списке рецензирования описано много типичных ошибок, присутствующих в документах требований, что позволяет рецензенту сосредоточиться на стандартных проблемных областях.
Документы процесса управления требованиями
- Процесс управления требованиями описывает действия работающей над проектом команды для различения версий требований, определения базовых версий, работой с изменениями требований, различными версиями документации по требованиям, учетом и отчетностью о состоянии требований и накоплением информации по отслеживанию.
- Процедура отслеживания состояния требований подразумевает мониторинг состояния каждого функционального требования и отчетность по нему.
- Процесс управления изменениями определяет пути предложения, передачи, оценки и разрешения нового требования или его модификации.
- Шаблон устава совета по управлению изменениями. Устав совета по управлению изменениями описывает состав, функции и рабочие процедуры этого совета.
- Контрольный список анализа последствий изменений в требованиях. Анализ последствий помогает вам рассмотреть задачи, побочные эффекты и риски, связанные с реализацией каждого изменения в требованиях, а также оценить объем работы по задачам.
- Процедура отслеживаемости требований определяет, кто предоставляет данные по отслеживаемости, которые позволяют отслеживать связи требований с другими артефактами проекта, кто их собирает и управляет ими и где они хранятся.
Пример дорожной карты совершенствования процессов работы с требованиями
0 0 Голос
Article Rating
Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях.
Этапу разработки требований может предшествовать технико-экономическое обоснование или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.
- Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
- Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде сценариев использования (англ. use case), пользовательских историй (англ. user stories), сценариев взаимодействия (scenario).
- Функциональный уровень (функции).
- Функциональный характер — требования к поведению системы
- Бизнес-требования
- Пользовательские требования
- Функциональные требования
- Нефункциональный характер — требования к характеру поведения системы
- Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
- Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным требованиям и ограничениям относятся:
- Ограничения на программные интерфейсы, в том числе к внешним системам
- Требования к атрибутам качества
- Требования к применяемому оборудованию и ПО
- Требования к документированию
- Требования к дизайну и юзабилити
- Требования к безопасности и надёжности
- Требования к показателям назначения (производительность, устойчивость к сбоям и т. п.)
- Требования к эксплуатации и персоналу
- Прочие требования и ограничения (внешние воздействия, мобильность, автономность и т. п.).
- Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
- Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
- Текущая организация деятельности объекта автоматизации
- Модели деятельности (диаграммы бизнес-процессов)
- Представления и ожидания потребителей и пользователей системы
- Журналы использования существующих программно-аппаратных систем
- Конкурирующие программные продукты
Характеристики качества требований по-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными[источник не указан 546 дней]:
| Характеристика | Объяснение |
|---|---|
| Единичность | Требование описывает одну и только одну вещь. |
| Завершённость | Требование полностью определено в одном месте и вся необходимая информация присутствует. |
| Последовательность | Требование не противоречит другим требованиям и полностью соответствует внешней документации. |
| Атомарность | Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости. |
| Отслеживаемость | Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано. |
| Актуальность | Требование не стало устаревшим с течением времени. |
| Выполнимость | Требование может быть реализовано в пределах проекта. |
| Недвусмысленность | Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено. |
| Обязательность | Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования. |
| Проверяемость | Реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ. |
- Интервью, опросы, анкетирование
- Мозговой штурм, семинар
- Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
- Анализ нормативной документации
- Анализ моделей деятельности
- Анализ конкурентных продуктов
- Анализ статистики использования предыдущих версий системы
Все требования должны поддаваться проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).
Определённые требования, по своей сути, не поддаются проверке. Они включают требования, которые говорят, что система никогда не должна или всегда должна показывать специфическое свойство. Надлежащее тестирование этих требований потребовало бы бесконечного цикла тестирования. Такие требования должны быть переопределены так, чтобы они стали поддающимися проверке. Как указано выше, все требования должны поддаваться проверке.
Нефункциональные требования, которые не поддаются проверке на программном уровне, все равно должны быть сохранены как документация намерений клиента. Такие требования к продукту могут быть преобразованы в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B (англ.).
При разработке требований часто возникают проблемы двусмысленности, неполноты, и несогласованности отдельных требований. Устранение этих проблем на этапе разработки требований стоит на несколько порядков меньше, чем устранение этих же проблем на поздних стадиях разработки. Для решения и устранения этих проблем существует процесс разработки требований.
При разработке требований существует технический компромисс между слишком неопределёнными требованиями и требованиями столь детализированными, что они:
- требуют много времени для разработки, иногда даже рискуют устареть к концу разработки;
- ограничивают возможные способы реализации;
- являются слишком дорогостоящими.
Требования обычно используются как средство коммуникации между различными заинтересованными лицами. Это означает, что требования должны быть просты и понятны для обычных пользователей и разработчиков. Один общий способ задокументировать требование — это написать утверждение о том, что должна сделать система.
В зарубежной и российской практике встречаются следующие типы документов требований:
Спецификацию программного обеспечения часто называют техническим заданием. Это ошибка. Спецификация требований является частью технического задания в случае создания автоматизированных информационных систем.[источник не указан 546 дней]
За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.
Для графических моделей требований исторически использовались диаграммы или методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).
В общем случае требования изменяются со временем. После того, как требования определены и одобрены, изменения должны попадать под контроль внесения изменений. Для многих проектов требования изменяются до завершения создания системы. Это происходит частично из-за сложности программного обеспечения и того факта, что пользователи не знают, что им нужно на самом деле. Эта особенность требований привела к появлению процесса управления требованиями.
- Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2.
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
- User story — показывает, чего вы ожидаете от команды разработки
- Use cases — показывают сценарии использования фичи
- Wireframes — средство визуализации своей идеи
Сегодня мы сосредоточимся на User story и Use cases.
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
As a/an <Название роли>, I want to <Цель, Действие>, so that <Ожидаемый результат>, to do <Что нужно сделать разработчику>
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Задачи пользователя:
- Загружать изображения
- Вставлять изображения в шаблон письма
- Удалять изображения
Для каждой задачи нужно написать свой use case — описание того, как пользователь взаимодействует с интерфейсом.
Примеры use case’ов:
Загрузка изображений:
- Email-маркетолог заходит в свой личный кабинет Retail Rocket
- Email-маркетолог открывает раздел «Галерея»
- Email-маркетолог загружает изображения через drag&drop или с помощью клика по кнопке «Выбрать файлы»
- Изображения загружаются
- Пользователь видит уведомление об успешной загрузке изображений
Удаление изображений:
- Пользователь кликает на изображение
- Изображение выделяется
- Выделение можно снять при помощи клика на область за пределами выделенного изображения
- Пользователь нажимает на иконку «три точки»
- Появляется контекстное меню
- Пользователь выбирает в нем ссылку «Удалить файл». Если было выделено несколько изображений, то удалятся все
- Изображение удаляется
Таким же образом расписываются все сценарии использования, что дает разработке четкое понимание, как выглядит взаимодействие пользователя с продуктом или фичей, и что для этого нужно сделать.
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
- нужно ли удаление файла вообще?
- будет ли это ручное удаление или автоматически стираются самые старые файлы при загрузке новых, если превышен лимит пространства для хранения?
- удаление происходит из списка файлов или нужно открыть файл?
- файл удаляется навсегда или есть корзина для файлов, где они хранятся какое-то время? если нужна корзина, то сколько файлы в ней хранятся?
- должно ли быть пакетное удаление файлов или можно удалять только одному?
- файл удаляется с помощью отдельной иконки (как выглядит эта иконка?) или через пункт меню (как он будет называться? на каком месте в списке действий расположен?)
- и т.д.
И ведь это всего лишь один из пунктов задачи, а уже столько вопросов. И на выяснение каждого требуется время и усилия с обеих сторон.
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
Директор по продукту Гульфия Курмангалеева
Бизнес-требования — это спецификации, которые после предоставления обеспечивают ценность и описывают характеристики предлагаемой системы, с точки зрения конечного пользователя. И также называются перечислением заявок заинтересованных сторон. Продукты, программное обеспечение и процессы являются способами, как поставить и удовлетворить потребности предприятия. Следовательно, бизнес-требования часто обсуждаются в контексте разработки или приобретения программного обеспечения или других систем.
Определение
Путаница в терминологии возникает по трем основным причинам:
- Обычной практикой является обозначение целей или ожидаемых выгод как бизнес-требований.
- Люди, как правило, используют данный термин для обозначения характеристик продукта, системы, программного обеспечения, которые предполагается создать.
- Широко распространенная модель утверждает, что эти два типа заявок отличаются только уровнем детализации или абстракции — где бизнес-требования являются высокоуровневыми, часто расплывчатыми и разлагаются на подробные заявки к компоненту.
Такого недоразумения можно избежать, если признать, что данное понятие не является целями, а скорее отвечает им (то есть обеспечивает ценность) при их удовлетворении. Бизнес-требования не разлагаются в продукт, системы и программное обеспечение. Скорее, все происходит наоборот. Продукты и их заявки представляют собой ответ на бизнес-требования — предположительно, чтобы удовлетворить их. Данное понятие существует в производственной среде и должно быть обнаружено, тогда как спросы к продукту определены человеком. Требования к бизнес-плану не ограничиваются существованием высокого уровня, а должны быть сведены к деталям. Независимо от величины детализации, заявки всегда обеспечивают ценность, когда удовлетворены.
Обновление продукта
В проектах разработки систем или программного обеспечения для требований малого бизнеса обычно необходимы полномочия заинтересованных сторон. Именно они приводят к созданию или обновлению продукта. Бизнес-требования к системе и программному обеспечению обычно состоят из функциональных и нефункциональных заявок. Конечно же, обычно они определяются в сочетании с первым вариантом возможностей продукта. Второй часто фактически отражает оформления бизнес-требований, которые иногда рассматриваются как ограничения. Они могут включать необходимые аспекты производительности или безопасности, применимые на производственном уровне.
Акценты процесса
Заявки часто перечислены в официальных документах. Акцент в них делается на процессе или деятельности точного планирования и разработки бизнес-требований, а не на том, как этого достичь. Этот параметр обычно делегируется спецификацией или документом системных заявок или другому варианту. Может возникнуть путаница между ними, если не учитывать все различия. Следовательно, многие официальные документы фактически описывают требования к продукту, системе или программному обеспечению.
Обзор
Бизнес-требования в контексте разработки программного обеспечения или его жизненного цикла — это концепция выявления и документирования любых пользователей. Например, таких как клиенты, сотрудники и поставщики, на ранних этапах цикла создания системы для руководства проектированием будущего. Заявки часто фиксируются аналитиками. Именно они анализируют требования бизнес-процесса и часто изучают его «как есть» для определения целевого «будущего».
Состав заявок
Требования бизнес-процесса часто включают в себя:
- Контекст, область и фон, в том числе и причины изменений.
- Ключевые заинтересованные стороны, у которых есть требования.
- Факторы успеха для будущего или целевого состояния.
- Ограничения, налагаемые бизнесом или другими системами.
- Модели и анализ процессов, часто использующие блок-схемы для представления всего «как есть».
- Логическая модель данных и ссылки на словарь.
- Глоссарии деловых терминов и местный жаргон.
- Диаграммы потоков данных для иллюстрации того, как они проходят через информационные системы (в отличие от блок-схем, изображающих алгоритмический поток бизнес-операций).
Роли
Самый популярный формат для записи бизнес-требований — это документ. Цель их состоит в том, чтобы определить, какие результаты будут необходимы от системы, однако, она может быть в конечном итоге разработана без дополнительных условий. Следовательно, документы дополняются справочным материалом, который детализирует производительность технологии и ожидания инфраструктуры, включая любые профессиональные требования, относящиеся к качеству обслуживания.Это, например, производительность, ремонтопригодность, адаптивность, надежность, доступность, безопасность и масштабируемость.
Полнота
Прототипирование на ранней стадии тестирования позволяет оценить полноту и точность выявленных бизнес-требований. Заинтересованные стороны проходят процедуру первыми, чтобы помочь определить структуру. И результат направляется командам разработчиков бизнес-требований проекта, которые строят систему. Другие заинтересованные стороны тестируют и оценивают окончательно развернутую проекцию. Ясность требует отслеживания заявок и их решения с формальным процессом определения соответствующего шаблона.
Объем бизнес-требований не обязательно ограничен стадией дефиниции того, что должно быть построено как система. Это выходит за рамки того, чтобы предусмотреть, как управлять и поддерживать действующую стратегию. И обеспечивать ее постоянное соответствие бизнес-целям. Документ требований должен постоянно пересматриваться контролируемым образом. Наличие стандартизированного формата или шаблонов, разработанных для конкретных бизнес-функций и доменов, может обеспечить полноту запросов, помимо сохранения сфокусированности области.
Прообраз
Несмотря на то что обычно считается средством оценки требований, прототипирование обычно переключает внимание на создаваемый продукт или систему. Прототипы — это работающее программное обеспечение, что означает, что они состоят из трех этапов (заявки, инженерное или техническое проектирование и реализация), удаленных от бизнес-требований. И также это предварительные версии, которые разработчик намеревается внедрить.
Поскольку прототипы являются довольно конкретными, заинтересованные стороны, которые опробуют их, могут дать более значимые отзывы о некоторых аспектах того, что создает разработчик, что является интерпретацией способа удовлетворения. Более того, графический интерфейс пользователя подчеркивается, а внутренняя часть — это ярлыки. Они составляют основную часть программной логики, и именно там будут удовлетворены большинство бизнес-требований. Другими словами, проблемы, которые обнаруживают прототипы, вряд ли связаны с запросами.
Разработка
Важно распознавать изменения в заявках, документировать их и обновлять. Однако деловые запросы, как правило, меняются не так сильно, как осознание их. Бизнес-требование может присутствовать, но не быть признано или понято заинтересованными сторонами, аналитиками и командой проекта.
Изменения, как правило, отражают предполагаемые способы удовлетворения неадекватно определенных материалов. Большая часть трудностей, связанных с выполнением бизнес-требований, на самом деле отражает общую практику, направленную почти на все усилия, связанные с ними, на то, что на самом деле представляет собой высокоуровневый дизайн продукта, системы или программного обеспечения. Это связано с неспособностью сначала адекватно определить бизнес-требования, чтобы обеспечить ценность.
Практики разработки обычно продолжают пересматривать продукт до тех пор, пока они в конечном итоге не «вернутся» к решению, которое, кажется, выполняет то, что необходимо, то есть, по-видимому, отвечает запросам производства. Косвенные методы проб и ошибок для определения бизнес-требований являются основой для большей части «итеративной разработки», включая популярные методы, которые рекламируются как «лучшие практики».
Примеры оформления
Шаблоны помогают оперативно запрашивать конкретные темы, которые часто могут иметь отношение к запросам. Они могут создавать стандартизированную документацию, касающуюся требований бизнеса, что может облегчить понимание. Шаблоны не гарантируют точность или полноту запросов. Часто неправильно используемые примеры негативно влияют на исследования, поскольку они имеют тенденцию содействовать поверхностности и главным образом механическому определению без осмысленного анализа.
Трудности
Бизнес-требования часто преждевременно ужесточаются из-за большой базы заинтересованных сторон, участвующих в их определении, где существует вероятность конфликта интересов. Процесс управления и достижения консенсуса может быть деликатным и даже политическим по своей природе. Менее сложная, хотя и распространенная задача — это распределенные группы с заинтересованными сторонами в разных географических точках. Естественно, что торговый персонал ближе к своим клиентам, а производственный – к соответственным единицам. Финансы и управление сотрудниками, включая высшее руководство, ближе к зарегистрированной штаб-квартире.
Бизнес-требования, к примеру, нужны для системы, в которой участвуют пользователи, занимающиеся продажами и производством. Она может столкнуться с конфликтом целей — одна сторона заинтересована в предоставлении максимального количества функций, а другая сосредоточится на самой низкой стоимости производства. Такие ситуации часто заканчиваются консенсусом с максимальными возможностями для разумной, выгодной цены и распределения.
Чтобы решить эти проблемы, участие заинтересованных сторон на ранней стадии достигается путем демонстрации прототипов и совместной работы. Практические семинары как в виде организованных сессий, так и простых дискуссий, помогают достичь консенсуса, особенно в отношении деликатных требований бизнеса и там, где существует потенциальный конфликт интересов. Сложность процесса является важным фактором. Это может потребовать специальных знаний, необходимых для понимания правовых или нормативных требований, внутренних руководящих принципов, таких как брендинг или корпоративные обязательства в отношении социальной ответственности. Анализ заключается не только в том, чтобы уловить «что» из бизнес-процесса, но также «как» представить его контекст.
Введение
Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе.
В этой статье я расскажу о следующем:
- какими бывают нефункциональные требования,
- как определять нефункциональные требования,
- откуда берутся численные значения для нефункциональных требований.
Нефункциональные требования: какие они бывают
Начнем с того, что требования к программным продуктам или информационным системам можно разделить на две большие группы. Это функциональные требования (описывающие, что необходимо реализовать в продукте или системе, в т.ч. какие действия должны выполнять пользователи при взаимодействии с ними) и нефункциональные требования (описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать).
Как правило, говоря о нефункциональных требованиях, чаще всего говорят об атрибутах качества (т.е. требованиях, определяющих качественные характеристики разрабатываемого программного обеспечения или системы, такие как производительность, надежность, масштабируемость), не обращая внимания на другие виды нефункциональных требований, а именно:
- Ограничения — условия, ограничивающие выбор возможных решений по реализации отдельных требований или их наборов. Они существенно ограничивают выбор средств, инструментов и стратегий при разработке внешнего вида и структуры (в т.ч. архитектуры) продукта или системы.
Примеры ограничений: «Разработка должна вестись на платформе вендора X», «При аутентификации пользователя должны использоваться биометрические методы идентификации».
- Бизнес-правила — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса, в т.ч. правила, определяющие состав и правила выполнения определенных бизнес-процессов. К бизнес-правилам относятся корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы, которые используются при разработке продукта или системы либо непосредственно влияют на разработку.
Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым».
- Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.
Примеры внешних интерфейсов: «Обеспечить запись в журнал операционной системы следующих событий: сообщения о запуске и остановке сервиса XX»; «Обеспечить запись в журнал параметров модулей программы: сканера, ядра, антивирусных баз (информация должна заноситься в журнал при запуске программы и при обновлении модулей)»
- Предложения по реализации — предложения, оценивающие возможность использования определенных технологических и архитектурных решений.
- Предложения по тестированию разрабатываемого ПО — дополнения к требованиям, указывающие, каким образом то или иное требование должно быть протестировано.
- Юридические требования — требования к лицензированию, патентной чистоте, etc.
Все эти требования должны быть определены и зафиксированы, прежде чем вы приступите к реализации вашей системы или продукта.
Нефункциональные требования: как их определять
Теперь, когда мы познакомились с различными видами нефункциональными требований, неплохо понять, что нужно делать дальше.
Для начала необходимо составить шаблон, в котором нужно перечислить основные виды нефункциональных требований. Этот шаблон необходим главным образом для того, чтобы не забыть ни одного из указанных типов требований. Для составления этого шаблона можно воспользоваться следующими источниками:
Нефункциональные требования: работа над определением
Как для определения функциональных, так и для определения нефункциональных требований используются рабочие группы, члены которых определяют, проверяют и утверждают требования. Для групп по определению нефункциональных требований особенно важно привлечь к этой работе не только аналитиков и пользователей, но и архитекторов и ключевых разработчиков продукта или системы, а также группу тестирования. Архитектор воспринимает нефункциональные требования как входные данные для выбора и проектирования архитектуры приложения, а группа тестирования планирует те сценарии нагрузочного тестирования, которые будут использоваться для проверки выполнения нефункциональных требований (в основном это касается атрибутов качества).
Роли, которые при этом играют участники рабочей группы по определению нефункциональных требований, описаны далее.
- Пользователи — дают оценки значений параметров, которые используются для определения нефункциональных требований. Параметры, как правило, привязаны к сценариям — пользовательским сценариям, в которых должны выполняться определенные действия с определенными ограничениями за определенное время.
- Системный аналитик — собирает, анализирует и документирует и систематизирует нефункциональные требования.
- Системный архитектор, ключевые разработчики — участвуют в определении и анализе нефункциональных требований и проверяют их на реализуемость.
- Группа тестирования — участвует в определении и анализе нефункциональных требований и разрабатывает сценарии тестирования для проверки нефункциональных требований.
Пример сценария, используемого для определения требований к производительности модуля системы, рассылающего уведомления пользователям сайта по электронной почте:
1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.
Какие вопросы при этом нужно задавать заказчику? В сущности, только один: через сколько времени после возникновения события все пользователи сайта должны гарантированно получить уведомление.
Критерии качественных нефункциональных требований
Как к функциональным, так и к нефункциональным требованиям применяются критерии качества требований — т.е. описание тех качеств, которым должны удовлетворять качественные требования.
Ниже приведены основные характеристики качественных требований.
- Полнота (отдельного требования и системы требований) — требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований. Причины неполноты описания следует явно объявлять.
- Однозначность — требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
- Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
- Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
- Осуществимость — включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
- Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы
Качество нефункциональных требований непосредственно определяет качество разрабатываемого продукта или системы и достигается за счет итеративного процесса определения и анализа нефункциональных требований при слаженной работе всей группы, участвующей в их разработке.
Атрибуты качества
Этот раздел будет посвящен характеристикам качества продукта или системы.
Характеристики качества и модель качества ПО
Определение атрибутов качества тесно связано с выбранной для вашего продукта моделью качества. Разработкой модели качества занимается группа обеспечения качества (в которую входят тестировщики и которая ими, разумеется, не ограничивается).
В индустрии ПО есть несколько моделей качества, принятых в качестве стандарта. Эти модели были разработаны в 70-е-80-е годы прошлого века и продолжают совершенствоваться.
Среди них можно выделить следующие:
Также можно назвать еще два стандарта, которые могут послужить источником для определения вашей модели качества:
- 1061-1998 IEEE Standard for Software Quality Metrics Methodology
- ISO 8402:1994 Quality management and quality assurance
Характеристики качества с точки зрения влияния на архитектуру системы
Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.
Рассмотрим более подробно каждую из этих групп.
Группа runtime
К этой группе относятся следующие атрибуты качества:
- Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
- Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
- Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
- Масштабируемость — требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
- Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
- Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
- Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля. - Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
- Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи
Группа design time
К этой группе относятся следующие атрибуты качества:
- Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
- Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
- Требования к переносимости (Portability) приложения или системы на другие платформы.
- Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
- Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
- Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
- Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
- Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы
О том, как, где, когда и откуда нужно взять конкретные значения для всех этих параметров, я расскажу в продолжении этой статьи.
Скачать Шаблон документа с бизнес-требованиями.doc
Наименование департамента
[НАИМЕНОВАНИЕ ПРИЛОЖЕНИЯ ИЛИ СИСТЕМЫ]
| Документ с бизнес-требованиями |
Документ с бизнес-требованиями
Руководство по использованию шаблона требований
Для того, чтобы правильно создать документ с описанием бизнес-требований, пожалуйста, придерживайтесь следующих принципов данного руководства. После завершения написания документа, удалите данный раздел.
| Назначение | Требование — это задокументированное условие или возможность продукта, сервиса или системы, которые должны соответствовать задачам проекта. Управление требованиями представляет собой семантический подход к выявлению, организации и документированию требований продукта, сервиса или системы. Документ с описанием бизнес-требований служит базовой линией проекта, которая поясняет, в бизнес-терминах, что необходимо сделать на этапе проектирования в проекте.
Так как требования являются динамичными, то документ с бизнес-требованиями является постепенно изменяющимся документом, целью которого является записывать то, что известно на данный момент, а затем используя эти записи строить документ дальше по ходу развития проекта. Именно из этого документа появляется более конкретная проектная документация, которая формируется на основе потребностей проекта и других взаимодополняющих методологий.
|
| Владение документом | Бизнес-анализ и руководители проекта работают с бизнес-спонсором и любыми другими необходимыми бизнес или техническими лидерами на проекте в рамках формирования документа с бизнес-требованиями.
|
| Когда документ формируется | Формирование документ с описанием бизнес-требований запускается во время начальной стадии выполнения проекта, который предшествует стадии проектирования в жизненном цикле управления проектами.
Определение бизнес-требований является обязательным этапом во всех проектах.
|
| Template Completion Note: Text within < > brackets need to be replaced with project-specific information. | Сбор требований непростой процесс, как это может показаться изначально. Это достаточно сложная задача, поскольку требования: · не всегда очевидны; · могут поступать из многочисленных и разнообразных источников; · нуждаются в управлении кросс-функциональными группами людей; · могут вызывать сложности при формулировании в ходе написании документации; · могут формулироваться на разных уровнях детализации.
Для проекта, который представляет собой усовершенствование существующего продукта, сервиса или системы, команда проекта проводит обзор существующих документов; поэтому документ с бизнес-требованиями, как правило, является более кратким. Тем не менее, проект, в ходе которого должен быть разработан новый продукт, услуга или система, как правило, будет содержать более детальный документ.
1. Не включайте раздел руководства к шаблону в итоговый документ. Введите информацию о проекте в заголовке страницы, нижние колонтитулы, титульный лист, участников по разработке документа, а также заполните информацию по контролю версий. 2. Заполните документ, используя вспомогательную информацию в <скобках>. 3. Для небольших проектов можно объединить все разделы требований в одну таблицу, добавив столбец «Тип требования». 4. Если некоторые требования не применяются в вашем проекте, то не удаляйте его, а пометьте его как «Не применяется» и укажите краткое пояснение, почему в текущем проекте данное требование не актуально. 5. Если на проекте имеются дополнительные требования, то ими нужно дополнить раздел 5. Можно создать отдельную таблицу для помощи в выявлении, определении и отслеживании требований. Обратите внимание, что если новое требование идентифицируется после того, как утвержден документ с бизнес-требованиями, то новое требование необходимо внести в раздел 10.1 Дополнения (новые требования). 6. После того, как были внесены изменения в документ, и вы готовы его завершить, убедитесь, что Вы обновили оглавление документа. 7. Составьте карту рассмотрения документа и его утверждений теми лицами, которые были определены в разделе с заинтересованными сторонами. 8. Из-за того, что документ с бизнес-требованиями является динамичным, после того, как менеджер проекта получает согласованный документ, все дополнительные, измененные или отмененные требования вносятся в 10 раздел. 9. Если вносятся изменения в документ, то необходимо обновить раздел с историей обновлений документа. 10. Документ с описанием бизнес-требований будет храниться вместе с другими документами проекта и поддерживаться в соответствии с политикой хранения документов.
|
| Расширение прав и возможностей. Масштабируемость. | Данный шаблон предоставляется в качестве ориентира для сбора базовой информации, необходимой для успешного формирования документа с описанием бизнес-требований. Руководители проекта имеют право использовать этот шаблон по мере необходимости для сбора каких-либо конкретных требований предполагаемого проекта. Количество деталей, которые содержит документ, зависит от размера и сложности проекта. В зависимости от проекта или потребностей бизнеса, требования могут быть добавлены, но не могут быть удалены.
|
Информация по документу и согласование документа
| История версий | ||||
| № версии | Дата создания | Кем пересмотрена версия | Причина для изменений | |
| 1.0 | 9/17/09 | Иванов Петр | Рассмотрение проектным офисом | |
Этот документ был утвержден в качестве официального документа с бизнес-требованиями для проекта «<имя проекта>», и точно отражает текущее понимание бизнес-требований. После утверждения этого документа, изменения требований будет регулироваться через процесс управления изменениями, включая анализ последствий (impact analysis), проходя стадии рассмотрения и согласования.
| Согласование документа | ||||
| Имя утверждающего | Проектная роль | Подпись/Электронная подпись | Дата | |
Оглавление документа
- Назначение документа. 1
- Ресурсы для создания документа. 1
- Словарь терминов.. 1
- Обзор проекта. 1
4.1 Обзор проекта и предпосылки. 1
4.2 Зависимости проекта. 1
4.3 Заинтересованные стороны.. 1
- Основные допущения и ограничения. 2
5.1 Основные допущения и ограничения. 2
- Сценарии использования/Варианты использования (Use Cases) 2
6.1 Диаграмма вариантов использования. 2
6.2 Изложение фактов по варианту использования. 3
- Бизнес-требования. 5
- Приложения. 7
8.1 Приложение A – Потоки бизнес-процессов. 7
8.1.1 Диаграммы «Как Есть» (As Is) 8
8.2 Приложение B – Каталог бизнес-правил. 10
8.3 Приложение C- Модели. 10
8.4 Матрица трассировки/отслеживания требований (Traceability Matrix) 10
8.5 Инструкция описания вариантов использования. 10
- Назначение документа
Этот документ определяет высокоуровневые требования <введите имя бизнес-линии, внутренней организации, заинтересованной стороны> этого проекта. Документ будет использоваться в качестве основы для следующих видов деятельности:
- Создание дизайнов Решения;
- Разработка плана тестирования, скриптов тестирования и сценариев тестирования;
- Определение критериев завершенности проекта;
- Оценка успешности проекта.
- Ресурсы для создания документа
| Имя | Бизнес-подразделение | Роль |
| <Идентифицируйте все заинтересованные стороны и ресурсы, которые будут вовлечены в процесс сбора требований> | ||
- Словарь терминов
| Термин / Сокращение | Определение |
| <Определите термины и сокращения, которые используются в данном документе > | |
- Обзор проекта
4.1 Обзор проекта и предпосылки
<Информация для данного раздела может быть взята из Устава проекта. Данный пункт содержит краткое описание того, что из себя представляет проект. Данный пункт включает в себя описание текущей ситуации, существующих проблем и целей. Этот раздел служит основой для начала процесса выявления требований. Каждое требование должно подводить проект к описанию основной концепции>
4.2 Зависимости проекта
<Перечислите любые связанные проекты, которые затрагивают целиком или частично Ваш проект, или которые имеют зависимости от этого проекта.>
4.3 Заинтересованные стороны
Ниже перечислены внутренние и внешние заинтересованные стороны, чьи требования представлены в этом документе:
| Заинтересованные стороны | |
| 1. | |
| 2.
| |
| 3.
|
- Основные допущения и ограничения
5.1 Основные допущения (предположения) и ограничения
| # | Допущения (предположения) |
| Перечислите любые допущения, на которых основаны требования | |
| # | Ограничения |
| Перечислите любые ограничения, на которых основаны требования | |
- Сценарии использования/Варианты использования (Use Cases)
<Основная цель сценариев использования (вариантов использования) заключается в том, чтобы зафиксировать требуемое поведение системы с точки зрения конечного пользователя для достижения одной или нескольких желаемых целей. Вариант использования содержит описание потока событий, который описывает взаимодействие между акторами и системой. Вариант использования также может быть представлен визуально в UML для того, чтобы показать взаимосвязи с другими вариантами использования и акторами>.
6.1 Диаграмма вариантов использования
6.2 Изложение фактов по варианту использования
<Каждый вариант использования должен быть задокументирован с помощью этого шаблона. Смотрите инструкцию для описания вариантов использования>
| ID Варианта использования: | |||
| НаименованиеВарианта использования: | |||
| Кем создан: | Кем в последний раз изменен: | ||
| Дата создания: | Дата последнего изменения: | ||
| Акторы: | |
| Описание: | |
| Предварительные условия: | |
| Постусловие: | |
| Нормальный ход событий: | |
| Альтернативный ход событий: | |
| Исключения: | |
| Содержит: | |
| Приоритет: | |
| Частота использования: | |
| Бизнес-правила | |
| Специальные требования: | |
| Предпосылки (предположения): | |
| Примечания и вопросы: | |
| Графическое представление варианта использования | |
Пример заполненного варианта использования:
| ID Варианта использования: | 1 | ||
| НаименованиеВарианта использования: | Просмотр интерактивной карты кампуса | ||
| Кем создан: | Иванов Петр | Кем в последний раз изменен: | |
| Дата создания: | 19/04/2015 | Дата последнего изменения: | |
| Акторы: | Пользователь |
| Описание: | Этот вариант использования описывает основной способ использования интерактивной карты кампуса. Пользователь через браузер получает доступ по соответствующему URL и взаимодействует с представленной функциональностью. |
| Предварительные условия: | Веб-браузер открыт и получен доступ к интерактивной карте кампуса через URL. |
| Постусловие: | Пользователь переходит с интерактивной карты кампуса на веб-сайт. |
| Нормальный ход событий: | 1. Открывается браузер; 2. Переход по URL карты кампуса; 3. Взаимодействие с картой кампуса при помощи доступной функциональности. |
| Альтернативный ход событий: | Отсутствует |
| Исключения: | Отсутствуют |
| Содержит: | |
| Приоритет: | Высший |
| Частота использования: | Одно использование на одно посещение. |
| Бизнес-правила | TBD |
| Специальные требования: | · Доступ 24/7 · Время отклика сопоставимо с общими картографическими решениями (например, карты Google) |
| Предпосылки (предположения): | |
| Примечания и вопросы: | |
| Графическое представление варианта использования |
- Бизнес-требования
Следующие разделы документа представляют различные бизнес-требования данного проекта.
| Тип требования | ID – Префикс | ID – Номер
|
Функция – Характеристика — Требование |
Ссылка на вариант использования | ?? | ?? | ?? | ?? |
Комментарии |
| Требования бизнес-пользователей | |||||||||
| f | 01-001 | ||||||||
| f | 01-002 | ||||||||
| f | 01-003 | ||||||||
| f | 01-004 | ||||||||
| f | 01-005 | ||||||||
| f | 01-006 | ||||||||
| f | 01-007 | ||||||||
| f | 01-008 | ||||||||
| Требования к отчетности | |||||||||
| f | 02-001 | ||||||||
| f | 02-002 | ||||||||
| f | 02-003 | ||||||||
| f | 02-004 | ||||||||
| f | 02-005 | ||||||||
| f | 02-006 | ||||||||
| f | 02-007 | ||||||||
| f | 02-008 | ||||||||
| Требования к правам доступа пользователей и безопасности | |||||||||
| f | 03-001 | ||||||||
| f | 03-002 | ||||||||
| f | 03-003 | ||||||||
| f | 03-004 | ||||||||
| F | 03-005 | ||||||||
| f | 03-006 | ||||||||
| f | 03-007 | ||||||||
| f | 03-008 | ||||||||
| Требования к уровню сервиса и к производительности | |||||||||
| f | 04-001 | ||||||||
| f | 04-002 | ||||||||
| f | 04-003 | ||||||||
| f | 04-004 | ||||||||
| f | 04-005 | ||||||||
| f | 04-006 | ||||||||
| f | 04-007 | ||||||||
| f | 04-008 | ||||||||
| Требования к масштабируемости | |||||||||
| f | 05-001 | ||||||||
| f | 05-002 | ||||||||
| f | 05-003 | ||||||||
| f | 05-004 | ||||||||
| f | 05-005 | ||||||||
| f | 05-006 | ||||||||
| f | 05-007 | ||||||||
| f | 05-008 | ||||||||
| Требования к поддержке и техническому обслуживанию | |||||||||
| f | 06-001 | ||||||||
| f | 06-002 | ||||||||
| f | 06-003 | ||||||||
| f | 06-004 | ||||||||
| f | 06-005 | ||||||||
| f | 06-006 | ||||||||
| f | 06-007 | ||||||||
| f | 06-008 | ||||||||
- Приложения
8.1 Приложение A – Потоки бизнес-процессов
<Опишите текущий существующий процесс документооборота используя диаграмму потоков (Visio Flowcharts) и дайте подробное описание>
8.1.1 Диаграммы «Как Есть» (As Is)
<Вставьте сюда диаграмму «Как Есть» (если это применимо к проекту)>
8.2.2 Диаграммы «Как Будет» (To Be)
< Вставьте сюда диаграмму «Как Будет» (если это применимо к проекту)>
8.2 Приложение B – Каталог бизнес-правил
<Инструкции: используйте следующий шаблон для каждого бизнес-правила>
| Наименование бизнес-правила | <Имя должно дать вам хорошее представление о теме бизнес-правила> |
| Идентификатор | <Определите уникальный идентификатор.> Например: BR1 |
| Описание | <Опишите детали бизнес-правила.> Например: «Весь труд рабочих отслеживается, составляется отчет и выставляется счет в 30 минутных интервалах» |
| Пример | <(Необязательное поле) Пример использования бизнес-правила> |
| Источник | <Источник правила. Например, заинтересованная сторона> |
| Связанные бизнес-правила | <Список связанных правил, для обеспечения процесса трассировки> |
8.3 Приложение C- Модели
<Вставьте сюда модели>
8.4 Матрица трассировки/отслеживания требований (Traceability Matrix)
<Вставьте сюда матрицу трассировки требований>
8.5 Инструкция описания вариантов использования
<Инструкции по заполнению описаний по сценариям использования содержатся в этом разделе. По завершению документа с бизнес-требованиями удалите эти инструкции>.
| Наименование поля Варианта использования | Определение |
| ID Варианта использования | Присвойте каждому варианту использования уникальный числовой идентификатор в иерархическом формате: X.Y. Связанные варианты использования могут быть сгруппированы в иерархию. Функциональные требования могут отслеживаться по меченным Вариантам использования. |
| Наименование Варианта использования | Ориентированное на результат имя в краткой форме для Варианта использования. Оно должно отражать задачи, которые пользователь может выполнить, используя систему. Включите в наименование глагол и существительное. Вот некоторые примеры: · Просмотреть информацию по номеру заказа. · Вручную пометить гипертекст источника и установить ссылку на целевой контекст. · Заказать компакт-диск с обновленной версией ПО. |
| Кем создан | Содержит имя человека, который изначально задокументировал этот Вариант использования |
| Дата создания | Введите дату, когда был задокументирован изначально Вариант использования |
| Дата последнего изменения | Введите дату последнего обновления Варианта использования |
| Кем в последний раз изменен | Содержит имя человека, который внес последние изменения. |
| Актор | Введите лицо или другие субъекты, которые являются внешними по отношению к системе ПО, и которые взаимодействуют с системой в соответствии с вариантом использования в рамках выполнения задач. Различные акторы часто соответствуют различным классам пользователей или ролям, идентифицируя их с группой пользователей заказчика, которые будут использовать продукт. Имя акторов, которые будут выполнять этот Вариант использования. |
| Описание | Дайте краткое описание причины и результатов этого Варианта использования, или приведите высокоуровневое описание последовательности действий и результата выполнения Варианта использования. |
| Предварительные условия | Перечислите мероприятия, которые должны состояться, или любые условия, которые должны выполниться до того, как вариант использования будет запущен. Количество предварительных условий. Примеры: · Идентификатор пользователя должен пройти проверку подлинности. · Компьютер пользователя имеет достаточное количество свободной памяти для запуска задачи. |
| Постусловие | Опишите состояние системы по завершении исполнения варианта использования. Количество постусловий. Примеры: · Документ содержит только допустимые теги в SGML. · Цена товара в базе данных была обновлена с новым значением. |
| Нормальный ход событий | Предоставьте подробное описание действий пользователя и реакции системы, которые будут проходить во время выполнения варианта использования в нормальных, ожидаемых условиях. Это последовательность действий внутри диалогового окна, в ходе которой будет достигнута цель, которая указана в названии варианта использования и в его описании. Это описание может быть написано как ответ на гипотетический вопрос: «Как мне выполнить задачу, которая указана в имени Варианта использования?». Лучше всего это делать в виде нумерованного списка действий, которые выполняет актор, чередуя их с реакциями системы на производимые действия. |
| Альтернативный ход событий | Задокументируйте другие, разумные сценарии использования, которые могут иметь место в пределах данного варианта использования. Обозначьте альтернативный ход событий и опишите какие-либо различия в последовательности шагов, которые могут потребоваться. Укажите номер каждого альтернативного хода, используя ID варианта использования в качестве префикса, а затем добавьте к номеру префикс «AC», чтобы обозначить «альтернативный ход событий». Например: X.Y.AC.1 |
| Исключения | Опишите любые предполагаемые условия возникновения ошибок, которые могут возникнуть во время выполнения варианта использования, а также определите, как система должна отреагировать на эти условия. Также опишите, каким образом система должна реагиовать, если вариант использования завершится по какой-то непредвиденной причине. Номер каждого исключения формируется при помощи ID Варианта использования и специального префикса «EX». Пример: X.Y.EX.1 |
| Содержит | Перечислите любые другие варианты использования, которые вызываются этим вариантом использования. Общие функциональные возможности, которые появляются в нескольких отдельных вариантах использования могут быть включены в отдельный вариант использования. |
| Приоритет | Укажите относительный приоритет реализации функциональности, которая необходима для того, чтобы этот вариант использования был выполнен. Используемая схема приоритетов должна быть такой же как та, которая используется в спецификации требований к программному обеспечению. |
| Частота использования | Оцените частоту использования данного Use Case за единицу времени. |
| Бизнес-правила | Перечислите любые бизнес-правила, которые влияют на этот вариант использования. |
| Специальные требования | Идентифицируйте любые дополнительные требования, такие как нефункциональные требования, для варианта использования, которые необходимо будет рассмотреть в ходе проектирования и реализации решения. Они могут включать в себя требования к производительности или атрибуты качества. |
| Предпосылки (предположения) | Перечислите какие-либо допущения, которые были сделаны при анализе, что привело к принятию данного варианта использования в описании продукта и написанию подробной информации по варианту использования. |
| Примечания и вопросы | Перечислите любые дополнительные комментарии по данному варианту использования или любые нерешенные вопросы, или TBD лист (то, что будет определено позднее). Определите, кто будет заниматься каждым отдельным вопросом или проблемой и к какому сроку все пункты должны быть разрешены. |
Скачать Шаблон документа с бизнес-требованиями.doc
0 0 Голос
Article Rating
Фундамент успешного проекта — это хорошо написанный документ бизнес-требований (BRD). BRD описывает проблемы, которые проект пытается решить, и необходимые результаты, необходимые для достижения ценности.
После успешной работы документ бизнес-требований направляет проект и держит всех на одной странице. Однако документация с требованиями может легко стать неясной и дезорганизованной, что может быстро вывести проект из строя.
Он также представляет собой базовый договор между заказчиком и поставщиком, в котором изложены ожидания и ожидаемые результаты проекта. BRD устанавливает стандарты для определения того, когда проект успешно завершен.
Бизнес-требования против функциональных требований
Хотя эти термины часто используются взаимозаменяемо, бизнес-требования не совпадают с функциональными требованиями для проекта. Бизнес-требования описывают, какие результаты необходимы, но не как их выполнить.
Эта информация («как») должна быть документирована в функциональных требованиях проекта. Как правило, они изложены в документации по требованиям к программному обеспечению для проектов разработки, но некоторые организации включают раздел функциональных требований в свои BRD. Эти функциональные требования подробно описывают, как система должна работать для удовлетворения бизнес-требований.
Бизнес-требования являются средством для достижения целей организации. Они должны быть высокоуровневыми, детализированными и написанными с точки зрения клиента.
Кроме того, в зависимости от процесса документирования организации разделы для функциональных и нефункциональных требований могут также включаться в BRD, а не в отдельные документы требований.
Топ 5 советов по написанию идеального BRD
Теперь, когда у вас есть понимание того, что должен выполнить документ бизнес-требований, вы можете следовать этим рекомендациям, чтобы убедиться, что вы пишете исключительный документ.
1. Практика эффективных требований выявления.
Даже если вы напишите внушительный BRD, это не будет эффективным, если вы не определили и не задокументировали все необходимые требования.Чтобы ваш BRD был полным и единообразным, вам необходимо применить надлежащие методы сбора.
A Руководство к Своду знаний по бизнес-анализу (более известное как Руководство BABOK) перечисляет девять основных методов выявления:
- Brainstorming
- Документальный анализ
- Интерфейсный анализ
- Фокусные группы
- Prototyping
- Требования к мастерской
- Interviews
- Observation
- Surveys
Вы можете использовать все девять или несколько избранных, но вам, безусловно, нужно будет включить несколько подходов, чтобы собрать полный набор требований.
Какие бы методы вы ни использовали, примите во внимание следующие советы по улучшению процесса извлечения.
Постоянно собирать требования
Хотя сбор большинства требований происходит на ранних этапах жизненного цикла проекта, бизнес-аналитик всегда должен быть открыт для выявления и документирования новых требований по мере необходимости. Может показаться заманчивым смести новую информацию под ковер, если вы уже продвинулись дальше начальных этапов проекта. Однако конечный продукт будет лучше, если вы выполнили все необходимые требования, даже если они были добавлены позже в игре.
Знакомьтесь с заинтересованными сторонами
Создайте отношения с заинтересованными сторонами и узнайте, как они работают. Приспособьте свои методы извлечения к их стилю или предпочтительному методу. В то время как некоторые люди работают лучше всего на собеседованиях, другие могут предпочесть готовить письменные ответы. Приспосабливая свои методы к человеку, вы будете более эффективны и эффективны в сборе требований.
Всегда быть готовым
Приходите на встречи с заинтересованными сторонами, подготовленные с вопросами и даже ответами. Правильные вопросы часто достаточны для того, чтобы сдвинуться с мертвой точки, но если команда изо всех сил пытается найти ответ, предложите его самостоятельноПредлагая варианты, можно получить мозговой штурм и более стратегически продумать проблему.
2. Используйте понятный язык без jargon
Требования к документам часто бывают длинными и объемными. Чтобы избежать путаницы или неправильного толкования, используйте понятный язык без жаргона. Имейте в виду, что многие заинтересованные стороны будут использовать этот документ, и не все из них будут технически мыслящими. Сохраняя ясность вашего языка, вы можете быть уверены, что каждый может его понять.
Если вам нужно включить жаргон или другие технические термины, обязательно добавьте их в раздел словаря проекта в документе.Этот раздел может служить полезной ссылкой на все необычные термины, встречающиеся в документе, поэтому никто не понимает требования неправильно.
3. Исследования прошлых проектов
Отличный способ начать процесс документирования — исследовать аналогичные проекты, выполненные вашей организацией в прошлом.
Ознакомьтесь с документацией по этим проектам и используйте эту информацию, чтобы помочь вам определить требования и другие ключевые моменты, которые нужно включить в ваш собственный BRD. Эти проекты также могут помочь вашей команде обосновать определенные требования, основанные на успешных прошлых результатах.Разбейте стены текста с помощью визуализаций данных, таких как потоки процессов и модели областей действия.
BRD Scope Model (Нажмите на изображение, чтобы изменить онлайн) Контекстная диаграмма системы BRD (Нажмите на изображение, чтобы изменить онлайн)Одной из самых распространенных диаграмм для BRD является диаграмма бизнес-процесса. Эта диаграмма визуализирует рабочий процесс и его связь с вашими бизнес-требованиями. В зависимости от сложности вашей документации вы можете использовать диаграмму процессов для представления процессов высокого уровня или углубиться в более подробные и подробные процессы для нескольких разделов требований.
Используйте Lucidchart для создания и совместного использования визуальных элементов процесса и документации по требованиям. Наша обширная библиотека готовых форм и шаблонов позволяет быстро составить диаграмму профессионального качества за доли времени, которые обычно потребуются вам.
Lucidchart даже позволяет связывать другие документы и файлы непосредственно с вашим документом, чтобы вы обновляли информацию в одном месте. А благодаря множеству опций обмена вы можете держать заинтересованных лиц на одной странице в течение всего процесса документирования и разработки.Обоснование этого инициирования является частью бизнес-требования. Проект
A может быть небольшим проектом по усовершенствованию или разработкой нового продукта. Исходя из размера продукта, бизнес-требования могут представлять собой простое описание бизнес-потребностей или очень сложный набор бизнес-задач, охватывающих несколько доменов и вертикалей. В любом случае, для успешного осуществления проекта необходимо выявить, понять и четко определить бизнес-требования.
Так, бизнес-требования здесь будут:
«Внедрение общеорганизационной системы управления запасами, которая будет отслеживать товары, хранящиеся в запасах, сокращать потери материала и увеличивать общую прибыль Организации за счет систематического администрирования.
Обратим внимание на некоторые вещи здесь, это бизнес-требование Скотта:
- Определяет потребности организации на высоком уровне и не углубляется в детали. По сути, он отвечает: «Чего хочет организация?»
- В нем говорится о преимуществах, которые будут достигнуты, когда требование будет выполнено.г. график, объем или бюджет) в соответствии с бизнес-средой или системой
- Любые предположения, которые необходимо учитывать в отношении требований бизнеса.
- Терминологии и связанные с ними объяснения делового языка
- Любые риски, выявленные на фоне реализации предложенных требований
- Процессы обработки, модели и блок-схемы для отображения системы «как есть» или «должна быть»
Где они документированы?
Документ, в котором вся вышеперечисленная информация является четким и точным документом, представляет собой BRD (Business Requirements Document) .Основным мотивом BRD является перечисление what, которое, как ожидается, будет достигнуто решением без учета как
, которое должно быть достигнуто.После того, как BRD подготовлен, он станет основой существования проекта, и все требования должны быть приведены в соответствие с этим документом. Любое требование проекта, которое не связано с бизнес-целью, указанной в документе BRD, следует либо отбросить, либо повторно оценить на предмет его жизнеспособности для проекта.
Связанный артикул: 9 важных документов, созданных каждым бизнес-аналитиком
Преимущества:
Настроенные и точно определенные бизнес-требования имеют многократные преимущества.
Бизнес-документ (BRD) | Университет ITOverview
Проектные группы должны использовать документ бизнес-требований (BRD) рабочей группы по требованиям (RWG), который доступен в виде документа Word и документа Google; это должно подвергнуться строгому обзору. Шаблон не диктует методологию проекта, а только предписывает, как поступить с требованиями.Все требования должны отслеживаться, утверждаться и соблюдаться, отклонения от которых должны быть документированы с целью изменения.
Process
1
ElicitЭтот этап выполняется бизнес-аналитиком и заинтересованными сторонами (спонсоры, пользователи, технические специалисты) .
Inputs
- Чартер проекта
- Полный сводный контрольный список
- Интервью анкеты
- Нефиксированные дефекты
- Известные проблемы / открытые билеты
- Как-это карта процесса
- Gap analysis
Outputs
- Первоначальный список вариантов использования
- Начальный список требований
- Запуск анализа (если применимо)
2
Анализ и организацияЭтот этап выполняется бизнес-аналитиком, пользователями (или его представителями), руководителем проекта, командой разработчиков, владельцем бизнеса / владельцем системы и системой обеспечения качества.
Outputs
- Разработанный список требований
- Альтернативные представления требований, таких как таблицы / деревья решений, модели, блок-схемы и скриншоты / прототипы / макеты
- Использовать случаи / сценарии
- Контроль для испытаний
3
WriteЭтот шаг выполнен Business Analyst.
Inputs
- Объем проекта / чартер
- Требования в форме бизнес-процессов, вопросников, вариантов использования, тестов, прототипов и т. Д.
Роли и обязанности
Actors Roles Responsibilities Customer / Client финансирует проект или приобретает продукт для достижения целей своих организаций. Распределяет финансирование. Проверяет требования, чтобы убедиться, что полученный продукт будет соответствовать бизнес-целям. Обеспечить четкое видение бизнеса и области применения. Users Взаимодействовать напрямую с продуктом (программным обеспечением). Предоставьте бизнес-аналитику исходные данные, чтобы они были полностью информированы при подготовке бизнес-требований — как на этапе анализа потребностей, так и на стадии анализа документов. Business Analyst Принимает лидирующую роль в определении и организации рабочей группы, если отраслевые эксперты (МСП), проживающие в клиентской группе или отделе, которые понимают задачи и цели пользователя и их соответствие бизнес-целям. Руководит всеми сессиями и обзорами сбора требований и готовит бизнес-требования. Хорошие бизнес-требования должны быть четкими и, как правило, определены на очень высоком уровне. Они также должны предоставить достаточно информации и руководящих указаний, чтобы гарантировать, что проект удовлетворяет выявленным потребностям. В дополнение к пониманию мандата, целей или задач организации необходимо четко определить и понять конкретную деловую потребность или проблему, которые необходимо решить, прежде чем разрабатывать бизнес-требования. Потребность или проблема могут быть связаны с организацией или бизнесом в целом или фокусироваться на группе заинтересованных сторон, таких как клиенты, клиенты, поставщики, сотрудники или другая группа.
При разработке функциональных требований разрабатывается исчерпывающий список шагов, которые будут предприняты в ходе проекта. Функциональные требования очень подробны и предоставляют информацию о том, как бизнес-потребности и цели будут реализованы в рамках конкретного проекта. В то время как старшие менеджеры будут больше интересоваться бизнес-требованиями, функциональные требования — это то, на чем должны сосредоточиться сотрудники и менеджеры более низкого уровня при разработке проекта. Конечная цель каждого шага — внести свой вклад в достижение бизнес-требований или требований.Также должно быть понятно, кто будет нести ответственность за каждый шаг.
Сходства и различия
При обоих бизнес-требованиях и функциональных требованиях, связанных с одним и тем же проектом, между ними есть существенные различия. Оба набора требований способствуют достижению общей цели, хотя функциональные требования являются гораздо более конкретными и подробными. В то время как бизнес-требования касаются в основном бизнес-целей и ожиданий заинтересованных сторон, функциональные требования определяют, как именно проект будет поддерживать бизнес-требования.Бизнес-требования говорят нам о том, каково будущее состояние проекта и почему цель того стоит, в то время как функциональные требования говорят нам, как мы туда доберемся. Функциональные требования обозначают конкретные этапы и определяют способ реализации проекта. В результате они помогают обеспечить реализацию проекта и используются для измерения производительности.
Другие виды требований
В некоторых проектах может потребоваться определить дополнительные требования, помимо деловых, функциональных или нефункциональных.Например, некоторые проекты могут нуждаться в технических требованиях, в которых указано, что необходимо для поддержки проекта во время разработки, реализации и реализации. Эти технические требования могут включать, например, серверы для хранения данных и процесс постоянного обслуживания, связанного с веб-сайтом. Также может возникнуть необходимость в установлении требований к переходу для оказания помощи в реализации или реализации. Примеры переходных требований включают шаги, связанные с обучением персонала и передачей знаний пользователям после завершения проекта.
Бизнес Документ Требования | Содержание по-прежнему актуально?Документ бизнес-требований. Является ли он по-прежнему полезным и, если да, что он должен содержать? Это не совсем так. Это скорее пример понимания того, какой формат или процесс наиболее важен для вашего проекта, чтобы документировать ваши требования, а затем применять его соответствующим образом. Во многих случаях по-прежнему необходимо иметь официальный документ с деловыми требованиями, который хорошо написан, формально рассмотрен и утвержден.Даже в некоторых Agile-проектах (возможно, в гибридных сочетаниях Agile / традиционных проектов) часто бывает так, что заинтересованные стороны бизнеса согласятся с некоторыми базовыми исходными бизнес-требованиями, прежде чем приступить к доставке на основе Agile и реализации этих бизнес-требований. В некоторых случаях документ может быть громоздким зверем для разработки, но пока организация достаточно гибка, чтобы осознать свои недостатки в контексте изменений и потребности в адаптируемости, документ бизнес-требований остается чрезвычайно ценным для организаций.
Что следует включить в документ бизнес-требований?
Работая во многих организациях с множеством различных шаблонов документов бизнес-требований, было бы справедливо сказать, что существует множество вариаций по этой конкретной теме, однако большинство документов бизнес-требований будут иметь определенные общие разделы содержимого. Давайте рассмотрим эти общие разделы контента, а также важность и актуальность каждого.
Проектного контекста или фона
. В разделе «Контент проекта» или «Справочная информация» описывается общая цель проекта и дается краткая история происхождения инициативы.
Scope
Раздел Scope состоит из двух основных списков операторов области действия. Эти два списка включают элементы области действия «В области видимости» и «Вне области видимости». Утверждения области действия должны описывать каждый элемент области как дискретную и индивидуальную концепцию того, что включено и что исключено из проекта. Каждому отдельному оператору области действия также должен быть присвоен уникальный идентификатор.Опять же, это может быть представлено в виде концептуальной диаграммы, показывающей внедрение и взаимодействие новых систем или улучшений, или оно может иллюстрировать эффективность бизнес-процессов. Тип диаграммы и формат описания, который вы выбираете для использования в этом разделе, в значительной степени зависит от характера проекта, который вы принимаете.
Важно: Хорошей идеей будет согласование типа иллюстрации, используемой в диаграмме и описании текущего состояния. с тем из будущего государственного раздела.Это улучшает читаемость и понимание для читателя.
Бизнес-требования
Раздел «Бизнес-требования» документа «Бизнес-требования», безусловно, является наиболее важной частью документа и должен быть заполнен с большой детализацией и полнотой. Рекомендуется разбить этот раздел на подзаголовки, описывающие различные типы требований, которые будут рассмотрены в документе «Бизнес-требования». На этом этапе вам следует учесть, что вам не обязательно включать все типы требований, перечисленных ниже, в документы о ваших бизнес-требованиях.
A Функциональное требование — это требование, которое, по сути, описывает то, что конкретный пользователь хотел бы сделать, используя систему. Он описывает, «как» бизнес-потребности будут удовлетворены с помощью предоставленного решения. Описанные другим способом, функциональные требования описывают, какую функциональность пользователь хочет иметь с помощью системы. Функциональные требования отличаются от требований заинтересованных сторон тем, что они описывают, «как» заинтересованная сторона ожидает, что система будет вести себя, или «как» конкретное требование должно быть реализовано.
Важно: Каждое функциональное требование должно иметь хотя бы одно требование заинтересованной стороны, которое описывает требование с точки зрения «что». Как правило, требования заинтересованных сторон содержат более одного функционального требования, описывающего, «как» оно будет реализовано. Эти типы требований не всегда включаются в документ бизнес-требований просто потому, что они могут быть более ориентированы на решение и, скорее, могут быть включены в документ требований решения.Например, если вы чувствуете, что необходимо уточнить некоторые бизнес-процессы в текущем или будущем состоянии, раздел приложения является хорошим местом для добавления этой детали к
Document Review & Signss
. Также не забудьте включить его в документ бизнес-требований. некоторые сведения о том, кто должен просмотреть документ, ключевые изменения, которые вы внесли, и кто должен утвердить документ. Это просто общие аспекты ведения домашнего хозяйства, которые должен иметь каждый документ, но стоит упомянуть здесь.
Функциональные и нефункциональные требования: спецификация и типы Время чтения: 9 минутЧетко определенные требования являются важными знаками на пути, который ведет к успешному проекту. Они устанавливают официальное соглашение между клиентом и поставщиком, что они оба работают для достижения одной и той же цели. Качественные, подробные требования также помогают снизить финансовые риски и сохранить график проекта. В соответствии с определением Business Analysis Body of Knowledge, требования являются удобным представлением потребности.
Создание требований — сложная задача, поскольку она включает в себя набор процессов, таких как выявление, анализ, спецификация, проверка и управление. В этой статье мы обсудим основные типы требований к программным продуктам и дадим ряд рекомендаций по их использованию.
Классификация требований
Прежде чем обсуждать, как создаются требования, давайте различать их типы.
Высокие требования каскада к конкретным деталям
Бизнес-требования.Это включает в себя заявления высокого уровня о целях, задачах и потребностях.
Требования заинтересованных сторон. Потребности отдельных групп заинтересованных сторон также определяются для определения того, что они ожидают от конкретного решения.
Требования к решению. Требования к решению описывают характеристики, которые продукт должен иметь для удовлетворения потребностей заинтересованных сторон и самого бизнеса.
- Нефункциональные требования описывают общие характеристики системы.Они также известны как атрибутов качества. Требования
- Functional описывают, как продукт должен вести себя, каковы его особенности и функции.
Переходные требования. Дополнительная группа требований определяет, что требуется от организации для успешного перехода из ее текущего состояния в желаемое состояние с новым продуктом.
Подробнее рассмотрим функциональные и нефункциональные требования.
Функциональные требования и их технические характеристики
Функциональные требования — это функции продукта или функции, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи.
Типы требований | Основы бизнес-анализа
Типы требований в бизнес-анализе
В мире бизнес-анализа все говорят об этих требованиях и о требованиях, которые, но действительно ли они понимают ключевые определения и различия между всеми различными типами требований?
В этой статье мы опишем различных типов требований, проводя аналогию со строительством дома.Что такое требование?
Требование в контексте бизнес-анализа — это просто заявление, предоставленное заинтересованным лицом, о том, что, по его мнению, им нужно для решения конкретной бизнес-проблемы или реагирования на конкретная деловая потребность.После того как заинтересованное лицо выдвинуло это требование, роль бизнес-аналитика состоит в том, чтобы дополнительно определить, проанализировать, утвердить и расставить приоритеты в заявлении о требованиях, поскольку теперь оно включено в контекст бизнес-анализа управления требованиями. В реальной жизни заинтересованное лицо обычно заявляет о своей бизнес-проблеме или потребности, а затем предоставляет целый ряд индивидуальных требований в рамках процесса управления требованиями, управляемого бизнес-аналитиком.
Почему тип требования имеет значение?
. Существует много различных типов этих требований, которые подняты заинтересованными сторонами конкретного проекта.Хотя большинство требований предъявляются, как правило, в начале инициативы или проекта, вполне вероятно, что дальнейшие требования будут подняты на более поздних этапах проекта. В случае Agile-проекта, вполне вероятно, что требования будут повышаться на постоянной основе, хотя они также будут инициированы с учетом большинства значительных и более крупных требований, которые должны быть сформулированы в начале проекта.
. Это означает, что все разные Типы требований, которые предоставляются, должны быть классифицированы в пределах их категории, чтобы иметь возможность эффективно управлять процессом требований.Как только вы очень четко понимаете различные типы требований, становится естественной и простой задачей сначала определить, когда требование фактически является требованием, а затем определить, к какому типу требований это относится.
Какие типы требований существуют? Любой бизнес-аналитик, чтобы быстро понять эти различные типы требований, должен сравнить типовой бизнес-проект с проектом по строительству дома. Теперь мы наметим бизнес-потребности, заявленные заинтересованными сторонами в этом контексте, и проиллюстрируем примеры различных существующих типов требований:
Понимаем заявление о бизнес-потребностях / бизнес-проблемах — Перед тем, как мы доберемся до требований…
33 семейство из четырех человек потеряло их сельская собственность находится в огне и в настоящее время находится в караване на их собственности.Проведя много расчетов по семейному бюджету, учитывая полученную ими страховую выплату и другие конкретные семейные ограничения, они решили, что лучшим вариантом является восстановление семейного дома. Рассмотрев множество других вариантов жилья, они решили, что проживание в собственности, где сгорел дом, соответствует их долгосрочным планам перепродать эту недвижимость после того, как будет построена автострада, которая будет завершена через несколько лет. Таким образом, этот вариант восстановления будет, безусловно, самым выгодным вариантом для семьи в целом, и в то же время они все еще могут наслаждаться своим пышным и сельским положением в качестве молодой семьи.
Это именно те соображения, с которыми деловые заинтересованные лица должны будут работать, когда они сталкиваются с бизнес-проблемой или потребностью. Бизнес-аналитик (оперативно-ориентированный корпоративный аналитик) будет частью анализа вариантов, выполняемого, когда выполняются такие процессы, как технико-экономические обоснования, бизнес-концепции и другие этапы предпроектного анализа. Бизнес-аналитик также будет участвовать в оценке того, будет ли предложенная инициатива соответствовать бизнес-стратегии и будет ли она прибыльной, также помогая в проведении анализа затрат / выгод.Как вы можете видеть, существует множество операций бизнес-анализа, которые выполняются даже до того, как требования вступают в игру. проект, который бизнес-аналитик начинает с общего и общего описания того, что требуется сделать (часто это необходимо для бизнеса или описание проблемы), а затем начинает работу с ключевыми заинтересованными сторонами в рамках проекта и вокруг него, чтобы определить область действия (что входит и исключены из результатов проекта), бизнес-требований (высокоуровневых требований), требований заинтересованных сторон (которые становятся более конкретными при описании «что» требуется) и, наконец, углубляются в специфику реализации (с требованиями к решению и, наконец, с требованиями перехода) ,Таким образом, это путь от концептуального уровня вплоть до детального и конкретного уровня требований. границы того, что включено и исключено до начала анализа требований. (Это достигается немного более итеративно и эволюционно в Agile-проектах (в зависимости от времени, бюджета и изменений в приоритетах бизнеса), но по существу все еще работает в рамках определений границ или областей на высоком уровне).
Scope Statement Пример:
«Воссоздание семьи по их собственности в стране»
Этот пример заявления о сфере действия описывает область действия проекта в конечном итоге. Важно четко определить утверждение или утверждения о содержании проекта, чтобы убедиться, что все требования, включенные в действия по требованиям проекта, действительно соответствуют общему объему проекта. быть много требований, предъявляемых и уточняемых, когда речь идет о строительстве дома.Мы будем использовать здесь только небольшой набор примеров требований, чтобы обрисовать и описать значение различных существующих типов требований.
Бизнес-требование — это заявление высокого уровня, описывающее то, что требуется с точки зрения бизнеса. В некоторых контекстах или проектах могут существовать частичные совпадения между заявлениями о бизнес-требованиях и заявлениями об отдельных областях.Для более крупных инициатив это будут разные уровни выражения того, что требуется. дом с двумя отдельными ванными комнатами, чтобы у родителей была отдельная ванная комната, отдельная от детей » »
Это примеры — требования, которые описывают,« что »семье нужно для нового дома.«Есть много заинтересованных сторон, которые сделают именно то, что сделала маленькая девочка, и расскажут вам как бизнес-аналитику, как они хотят, чтобы решение работало, прежде чем они заявят, что именно им нужно. Маленькая девочка предполагает, что вы знаете, что ей нужна спальня, и все, что ее беспокоит, это то, как спальня будет выглядеть. Имейте это в виду, когда вы в будущем будете говорить с заинтересованными сторонами о требованиях заинтересованных сторон. девушка.