Что такое бизнес функциональные требования

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

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

Что такое бизнес-требования

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

Что входит в бизнес-требования

Как бизнес-требования влияют на итоговый продукт?

Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

Почему нужно конкретно и четко оформить бизнес-требования?

Четкое формулирование бизнес-требований:

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

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

Что такое функциональные требования?

Примеры функциональных требований:

Нефункциональные требования. Важные особенности

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

Нефункциональных требований очень много. Вот некоторые из них.

Кто собирает требования?

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

✔ Стороннее агентство, нанятое заказчиком

✔ Штатный аналитик заказчика

✔ Наша команда в рамках услуги “Проектирование”

Как происходит сбор требований?

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

Кто участвует в сборе требований?

В зависимости от потребностей проекта, можно и нужно привлекать следующих заинтересованных лиц:

Вспомогательные материалы, предоставляемые заказчиком

Дополнительные материалы помогают исполнителю лучше понимать процесс принятия решений в компании и организовать работу наиболее эффективным образом. К таким материалам можно отнести:

Какие ошибки допускают заказчики в ходе сбора информации?

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

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

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

Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.

Рекомендации заказчику, пишущему требования

Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:

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

Выводы

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

В этой статье расскажу, что такое функциональные и бизнес-требования и почему их нужно собрать перед постановкой ТЗ.

Что такое функциональные требования

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

Само слово «функционал» подводит к тому, что мы задаем вопрос: как работает этот сайт, какие у него будут функции. Сюда относится все, что касается логики работы.

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

Пример того, как выглядят функциональные требования в техзадании

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

Нефункциональных требований очень много. Вот основные:

• Производительность. Например, скорость загрузки страницы или время реакции на определенные действия.
• Удобство для пользователя. Насколько интуитивное меню, сколько времени уходит у пользователя на поиск нужной информации.
• Безопасность. Персональные данные должны быть защищены от взломов, хакерских атак, вирусов.
• Совместимость. Как сайт смотрится на различных браузерах и устройствах. Возможно, с экрана телефона часть картинки не видно.
• Локализация. Если компания сотрудничает с иностранными клиентами, нужно адаптировать сайт под их запросы. Например, перевести контент на английский язык, добавить другую валюту или часовые пояса.

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

Чтобы объяснить отличие функциональных требований от нефункциональных, приведу такое сравнение. Функциональные требования – это авто или телега, у которых есть 4 колеса, место, где сидеть, и тягловая сила (двигатель или лошадь). А нефункциональные – это кузов мерседеса, с красивыми лампочками и шильдиками. Большинство людей покупают этот значок мерседеса на капоте, но это не отменяет и того, что под капотом все должно хорошо работать.

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

Что такое бизнес-требования

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

Бизнес-требования включают:

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

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

Бизнес-требования от заказчика сайта

Зачем нужны функциональные и бизнес-требования

Функциональные и бизнес-требования решают такие задачи:

1. Упрощают взаимодействие между заказчиком и разработчиком. Они помогают избежать недопонимания, определяют общие термины и роли.
2. Сокращают срок реализации проекта. Благодаря четким требованиям разработка сайта займет меньше времени.
3. Экономят бюджет. Когда заказчик понимает что ему нужно, он может более точно спланировать бюджет. Размытые требования приводят к неопределенной стоимости разработки, которая впоследствии может вырасти.
4. Выявляют возможные ошибки. Выявление ошибок на начальном этапе поможет сократить время и деньги на их исправление.
5. Помогают предвидеть итоговый результат. С помощью требований разработчик понимает, что двигается в правильном направлении. Они не дают увлечься и отойти от первоначальной идеи, выступая некими границами проекта.

Выполнение функциональных и бизнес-требований – готовые критерии, по которым заказчик принимает и оценивает работу команды разработчика.

Техзадание на разработку сайта: запрещенные слова и выражения

Кто занимается сбором требований

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

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

Если компания небольшая, где нет штатных маркетологов, аналитиков, программистов, стоит привлечь стороннее агентство для проведения конкурентного анализа и разработки digital-стратегии. Как вариант, можно доверить сбор требований компании, которая будет непосредственно разрабатывать сайт.

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

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

Перед сбором требований заказчик просматривает сайты конкурентов, подробно изучает бизнес заказчика, чтобы при встрече задать ему наводящие вопросы и предложить сайт, который будет решать основные задачи.

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

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

Как проходит сбор требований

Методы сбора функциональных и бизнес-требований:

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

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

Для удобства документ обычно разбит на несколько разделов:

• Бизнес-требования. Это самые приоритетные требования, которые определяют цель создания сайта и задачи.
• Дизайнерские требования. Здесь описаны цвета, шрифты, стилистика будущего сайта. Они должны совпадать с идеей или фирменным стилем заказчика.
• Требования пользователей сайта. В данном блоке прописано, какую информацию может просматривать/добавлять/редактировать пользователи сайта. Например, менеджеру по продажам в интернет-магазине нужен только доступ к заказам, а бухгалтеру – к счетам и отчетам.
• Требования посетителей сайта. Здесь описан путь посетителя на сайте. Если проект очень крупный, составляется полноценная концепция поведения аудитории – Customer Journey Map.

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

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

Мы скидываем бриф на заполнение, где заказчик своими словами рассказывает, что у него должно быть на сайте и как это все будет работать, а также пожелания по внешнему виду. Если этого недостаточно, подключаются наши сотрудники: маркетологи и программисты.

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

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

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

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

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

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

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

Ошибки при сборе функциональных и бизнес-требований

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

Не подойдет	Подойдет
Форма регистрации должна быть удобной и простой.	Форма регистрации должна содержать три поля: имя и электронную почту. Кроме это, пользователь может зарегистрироваться через соцсети.
Страница должна быстро загружаться.	Время загрузки сайта – 3 секунды. Сохранение работоспособности при посещаемости 100 тысяч человек в сутки.
Сайт не должен содержать уязвимостей. Копии ПО хранятся на внешнем носителе.	Обеспечение защиты от межсайтового скриптинга (XSS), SQL-инъекций, CSRF-уязвимостей. Хранение копии ПО и файла базы данных на внешнем носителе.

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

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

Какие ошибки чаще всего допускают при сборе ФТ и БТ?

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

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

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

Макет будущего сайта на основе функциональных и бизнес-требований заказчика

Выводы

• Собрать функциональные и бизнес-требования нужно перед постановкой техзадания на разработку сайта. Это сэкономит бюджет заказчика, сократит время создания и исключит недопонимание сторон.
• Чем конкретнее поставлены требования в ТЗ, тем больше вероятность создания сайта, который будет решать все поставленные задачи.
• Принимать участие в сборе требований должен непосредственно заказчик, так как именно он понимает всю специфику бизнеса. Но если компания небольшая, стоит привлечь к проекту специалистов на аутсорсе или доверить сбор требований команде разработчика.

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

Шаблон или уникальный дизайн: что выбрать для сайта

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

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

Источник материала: https://systems.education/biz-req и https://systems.education/biz-req-dev

Роль Бизнес-требований (БТ)

1. Бизнес-требования определяют смысл проекта и обосновывают его необходимость
2. Бизнес-требования – это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам
3. Из бизнес-требований вытекают критерии приемки проекта
4. Бизнес-требования используются для определения рамок проекта
5. Бизнес-требования помогают принимать решения о приоритетах
6. В Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами

Требования в бизнес-анализе

Версия 3 BABOK Guide определяет требования таким образом:

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

Для формулирования требования потребность нужно поместить в какой-то контекст. Например потребность «Люди испытывают ежедневную потребность в пище» слишком общая. Если ее поместить в контекст морского путешествия, то требование становится уже более осмысленным: «Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30оС и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».

Способы выполнения требования могут быть разными и они называются решениями.

Потребности, требования, решения, контекст

• Голубой блок обозначает контекст проекта и его элементы.
• Красный блок в левой части — потребности бизнеса и стейкхолдеров.
• Желтый блок в центре — бизнес-требования, требования стейкхолдеров и требования к решению.
• Зеленый блок справа — решения, удовлетворяющие требования (бизнес-процессы и информационные системы).

Потребности бизнеса, подлежащие удовлетворению в конкретном контексте, отражаются в бизнес-требованиях.

Решением для бизнес-требования обычно является бизнес-процесс или организация, выполняющая множество бизнес-процессов.

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

Полное решение состоит из бизнес-процессов и [информационных] систем, поддерживающих и обеспечивающих эти процессы. Системы реализуют требования к решению.

Пример определения бизнес-требования на основе анализа потребности

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

Если бизнес-модель компании предполагает поддержание товарных запасов на складе, то бизнес-требование можно сформулировать так:

Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.

Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»

В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса.

Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.

Артефакты бизнес-анализа, сопровождающие бизнес-требования

По мере определения бизнес-требований появляются:

1. Доменные модели — высокоуровневые информационные модели предметной области.
2. Глоссарий предметной области.
3. Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
4. Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
5. Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.

 Немного слов про бизнес-правила

Как правильно описывать бизнес-правила?

1. Бизнес-правило должно быть сформулировано на языке бизнеса. В описании бизнес-правил не должны использоваться технические термины. Язык написания бизнес-правил должен быть понятным представителю бизнеса, не являющимся IT-специалистом. После описания бизнес-правил, постарайтесь абстрагироваться от своих технических знаний, поставьте себя на место представителя бизнеса, руководителя компании, для который вы разрабатываете продукт. Понятен ли вам написанный документ? Не содержит ли документ технических терминов, указания систем и языков программирования?
2. Бизнес-правило должно описывать правило бизнеса, а не работу системы. Описание бизнес-правил должно содержать те требования бизнеса, которые должна решить система, но без описания работы системы. Например, у бизнеса есть правило: «Отслеживать время прихода и ухода сотрудников на рабочее место». Бизнес-правило не должно содержать описания, как достичь соблюдения данного правила: будет ли сотрудник записываться в журнал прихода и ухода, или на входе будет стоять автоматическая пропускная система, которая будет фиксировать время.
3. Бизнес-правило должно описывать ограничения: какие операции не могут быть выполнены. Ограничительные бизнес-правила могут определять ограничения пользователей. Например: “В полис ОСАГО страховщик может вписать не более 5-ти водителей”; «Оформить заказ-онлайн может только клиент компании».
4. Бизнес-правило подчиняется бизнесу: принять, изменить, отменить. Представители бизнеса могут изменять бизнес-правила, вносить поправки или отменять.

Рассмотрим несколько примеров бизнес-правил и требований к системе

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

Требования стейкхолдеров

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

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

Как специалисту, отвечающему за поддержание запасов, мне нужно иметь возможность:

1. Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
2. По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
3. Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
4. Смотреть для проверки не на все 3000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.

Примерно так будет рассказывать нам живой человек. «Пользовательская история» (User Story) — естественная форма представления требований стейкхолдеров, имеющая формат <роль> <задача> <нужная возможность>.

Например:

Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:

1. Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
2. по любой позиции заказа иметь возможность посмотреть детали расчета и
3. вручную изменить заказываемое количество,
4. видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)

Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:

• Карты стейкхолдеров (показывают, кто участвует в процессах)
• Модели и другие описания процессов
• Варианты использования (Use Cases)
• Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)

Функциональные и нефункциональные требования

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

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

В наглядном виде модель выявления требований представлена на схеме:

Почему бизнес-требования так важны

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

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Какие бывают бизнес-требования?

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

Исходя из определения Six Sigma, классификация требований будет опираться на критичные активности, т. е. бизнес-требования могут быть связаны с:

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

Ниже приведены примеры бизнес-требований по видам критичных активностей.

Вид БТ: Значимые характеристики продуктов или услуг

Примеры БТ:

• Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
• Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
• Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.

Вид БТ: Распознавание и обработка событий

Примеры БТ:

• Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
• К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
• Сотрудники должны быть своевременно проинформированы о назначенных им задачах.

Вид БТ: Принятие решений

Примеры БТ:

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

Вид БТ: Сбор, обработка, хранение и предоставление информации

Примеры БТ:

• С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
• Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
• Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.

Вид БТ: Обеспечение возможности выполнения действий

Примеры БТ:

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

Вид БТ: Предотвращение возможности выполнения действий

Пример БТ:

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

 Проблемы в бизнес-требованиях

Можно выделить несколько типичных признаков проблем с бизнес-требованиями.

• Неконкретность (слишком абстрактная формулировка)
• Невозможность проверки (нет понимания, что является индикатором выполнения требования)
• «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
• Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
• Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
• Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
• Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
• Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
• Привязка к конкретному решению, в том числе — конкретный бизнес-процесс

Примеры некорректных бизнес-требований

Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?

1. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
2. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
3. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
4. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

Типовые ловушки аналитика

Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:

• Формальность — «пишу, потому что надо здесь что-то написать».
• Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
• Превращение в аудит — выясняем все обо всем «на всякий случай».
• Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.

Что можно сделать с каждой из этих ловушек?

Ловушка	Описание	Решение
Формальность	«Пишу, потому что надо здесь что-то написать»	Ставить себя на место читателя (необходимо понимать, что и для кого мы пишем).
Узкие рамки анализа	Фокусировка только на том, что относится к проекту, т.е. не рассматриваем ничего, что выходит за рамки проекта	Анализировать область шире, чем те рамки, которые хотим установить для проекта.
Превращение в аудит	«На всякий случай» выясняем все обо всем	Постоянно спрашивать себя: «как это связано с проектом?»
Превращение метода в цель	Строгое следование определенному шаблону с превращением средств (канва бизнеса, бизнес-процессы, стейкхолдеры) в цель и потерей основной цели проекта	Задать себе вопрос: «можно ли обойтись без э

Документирование бизнес-требований

В практике бизнес-аналитика присутствует два основных подхода документирования требований:
1. Монолитно

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

2. Дробно

• Каждое требование описывается отдельно.
• Каждому требованию присваивается уникальный идентификатор.
• Возможна трассировка к конкретному бизнес-требованию.

Шаблон монолитного описания БТ

Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

• Контекст.
• Описание возможности.
• Бизнес-цели.
• Метрики успешности.
• Образ результата (Vision).
• Деловые риски.
• Предположения и зависимости бизнеса.

Советы Вигерса по описанию БТ

• Сокращайте шаблон в соответствии с потребностями.
• Заполняйте не сверху вниз, а по мере поступления информации.
• Пустой раздел — признак его ненужности или необходимости дополнительного изучения.
• Не повторяйте то, что уже описано в другом месте — сошлитесь на имеющееся описание.
• Исходите из возможности повторного использования БТ в других проектах.
• Выявляйте конфликты, противоречия и выносите на обсуждение.
• Проводите повторное рассмотрение БТ при каждой смене лиц, принимающих решения, чтобы убедиться, что понимание БТ не изменилось

Шаблон дробного описания БТ

Ниже представлен авторский шаблон дробного описания бизнес-требований. Он состоит из нескольких ключевых элементов:
1. Заголовок, который включает в себя:

• Уникальный идентификатор.
• Краткое описание.

2. Определение, развернутое объяснение, что из себя представляет БТ.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

Что такое функциональные требования: примеры, определение, полное руководство

Что такое функциональные требования? Этот вопрос часто ставит в тупик как владельцев бизнеса, так и разработчиков. Функциональное требование можно рассматривать как особенность продукта, которую обнаруживает пользователь. Это может быть очевидная функция, например, большая кнопка «Добавить в корзину». Но это также может быть и менее очевидная функция, например, правильный расчет налога с продаж для онлайн-покупки пользователя. В этом полном руководстве мы разобьем функциональные требования на их простейшие формы и приведем примеры каждого типа. Мы также определим, что каждый тип требований означает для вашего бизнеса и как их создать.

Что такое функциональные требования?

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

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

Типы функциональных требований

Вот наиболее распространенные типы функциональных требований:

• Деловые правила
• Сертификационные требования
• Требования к отчетности
• Административные функции
• Уровни авторизации
• Отслеживание аудита
• Внешние интерфейсы
• Управление данными
• Правовые и нормативные требования

Создание функциональных требований:

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

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

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

Примеры:

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

Пример # 1

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

В этом примере функция — «вход», а поведение — «Система должна позволять пользователю входить в систему, используя свое имя пользователя и пароль».

Пример # 2

: Система рассчитывает налог с продаж для покупки пользователя.

В этом примере функция — «рассчитать налог с продаж», а поведение — «Система должна рассчитать налог с продаж путем умножения покупной цены на налоговую ставку».

Пример # 3

: система отправляет пользователю электронное письмо с подтверждением после того, как он успешно разместил заказ.

В этом примере функция — «отправить электронное письмо с подтверждением», а поведение — «система должна отправить электронное письмо с подтверждением пользователю после того, как он успешно разместил заказ».

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

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

Чем функциональные требования отличаются от нефункциональных требований?

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

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

• Пользовательский интерфейс
• Надежность 
• Охранник
• Производительность
• Обслуживание
• Стандартный 

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

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

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

Вывод:

Функциональные требования являются ключом к успеху любого проекта по разработке программного обеспечения. Создавая функциональные требования, вы гарантируете, что каждый в вашей команде понимает, что нужно создать, и может соответствующим образом расставить приоритеты в своей работе. В следующем посте мы обсудим, как создавать функциональные требования с помощью Платформа ALM для требований Visure. Если вы хотите узнать больше о функциональных требованиях или приступить к их самостоятельному созданию, запросите бесплатную 30-дневную пробную версию на платформе Visure Requirements ALM уже сегодня.

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

Сбор требований

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

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

Выжимка по процессу формирования требований

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, 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) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.

Схема процесса разработки с уровнями требований

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

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

1. Описание контекста и списка ключевых заинтересованных лиц
2. Описание целей создания системы и критериев достижения
3. Ключевые бизнес-требования к решению и их приоритеты
4. Существующие и возможные ограничения на решение

Контекст — это то, что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать.

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

• Бизнес-назначение
• Бизнес-рамки
• Обзор бизнеса
• Заинтересованные лица
• Организационная среда
• Цели и результаты
• Бизнес-модель
• Информационная среда
• Бизнес-процессы
• Политики и правила
• Ограничения деятельности
• Организационная структура
• Концепция использования системы
• Сценарии эксплуатации
• Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик

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

Проблемы при формировании пользовательских требований

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

Системные требования

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

Функциональные требования

Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

Стандартные формы для специфицирования функциональных требований:

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

Функциональные требования (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).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

Документ по управлению требованиями