Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.
Напомним, что нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.
Культурные образцы — это те требования, которые можно получить на основе стороннего опыта. То есть, изучая какой-то аналогичный готовый продукт на рынке, мы можем сформировать требования к своему продукту (даже если эти требования никто из стейкхолдеров не озвучивал напрямую).
Все виды требований возникают в конкретном контексте, то есть следуют из Операционного контекста, к которому относятся активы, спрос, технологии и так далее. Подробнее про влияние контекста на бизнес-требования смотрите в статье Бизнес-требования. Назначение.
Зачем нужны бизнес требования?
В наглядном виде модель выявления требований представлена на схеме:
Источник: systems.education
Бизнес-требования
Вдобавок каждая система имеет свои нефункциональные требования.
Бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью.
Бизнес-требования определяют и набор бизнес-задач (вариантов использования), которые позволяет выполнять приложение (ширина приложения], и глубину уровня, до которого реализуется каждый вариант использования. Бизнес-требования позволяют понять, для каких вариантов использования необходима надежная и полная функциональность, а для каких достаточно поверхностной реализации, по крайней мере на первое время.
Бизнес-требования влияют на приоритеты реализации вариантов использования и связанные с ними функциональные требования, также существенно влияют на способ реализации требований.
Бизнес-требования описывают основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Для различных типов продуктов — информационных систем, коммерческих пакетов ПО и систем контроля, работающих в режиме реального времени, — выделяются различные преимущества.
Анализ требований 6. Бизнес-объекты. Бизнес требования. Функциональные требования.
Возможности бизнеса. Для коммерческого продукта описывают существующие рыночные возможности и рынок, на котором продукту придется конкурировать с другими продуктами. Для корпоративной информационной системы описывают бизнес-проблему, которая разрешается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт, а также среду, в которой система будет использоваться.
Бизнес-цели и критерии успеха. Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде.
Потребности клиентов или рынка. потребности типичных покупателей или целевых сегментом рынка, включая потребности, которые не удовлетворяют настоящие продукты или информационные системы.
Бизнес-риски. Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта. В категории рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы, влияющие на бизнес.
Требования пользователей
Требования к ПО состоят из трех уровней:
- бизнес требования;
- требования пользователей;
- функциональные требования.
Вдобавок каждая система имеет свои нефункциональные требования.
Бизнес-требования формируют каркас всего проекта. Любые другие функции и требования к продукту должны удовлетворять бизнес-требования. Тем не менее бизнес-требования не предоставляют разработчикам достаточно информации для создания продукта.
Следующий уровень требований — требования пользователей: их определяют те, кто прямо или косвенно взаимодействуют с продуктом, то есть конечные пользователи. Они способны описать требуемую функциональность, а также ожидаемые качественные характеристики продукта.
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
Требования пользователей — user requirement — цели и задачи, которые пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы ≪событие — отклик≫. Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Источник: studfile.net
Бизнес требования к программе
Документирование бизнес-требований подразумевает формирование документа, который должен быть согласован с заказчиками и, возможно, оценен специалистами в области реализации.
Из чего этот документ будет состоять?
Большую часть его элементов мы с вами уже рассматривали.
-
Формулировка задачи. В отдельных случаях постановка задачи доступна нам сразу, однако в рамках бизнес-анализа мы, как правило, ее уточняем.
Итак, вопросы которые требуют небольшого пояснения:
Ресурсы:
Что имеется в наличии, чтобы помочь реализовать проект?
Существуют программные, аппаратные средства, материалы, шаблоны.
Очень часто команда, которая будет заниматься реализацией, не имеет представления о том, какие еще проекты были реализованы в этой области или, к примеру, реализуются параллельно.
И, соответственно, со стороны заказчика должны быть представители, которые обладают информацией о предметной области и могут сформулировать, какие еще существуют ресурсы, которые можно использовать для того, чтобы достичь целей проекта. Как правило, это — результаты каких-то смежных проектов или техническая документация.
Ограничения:
Каковы ограничивающие факторы для проекта?
Почти всегда есть 3 ограничения: время, бюджет, навыки пользователей. Как правило, ограничений больше, но эти 3 являются хорошей отправной точкой.
Ограничения — это те нюансы, аспекты, которыми бизнес ограничивает пространство решений для того, чтобы была возможность воспользоваться бизнес-результатами проекта.
И, как правило, туда входит время, бюджет …
Обязательно необходимо принять во внимание навыки пользователей, которые будут пользоваться нашей системой.
И другие ограничения. Например, в одном из проектов была ситуация, когда заказчик, создавая большое и сложное решение, ограничил перечень возможных использованных СУБД в связи с наличием определенных контрактов. Как бы проектировщикам не хотелось использовать другие решения, с учетом наличия этих ограничений, приходилось принимать их во внимание.
Список предположений:
Что мы предположили, когда готовили этот документ?
Предположения также должны быть проверены, так как любое предположение — это риск.
Раздел предположений, наверное, один из самых важных с точки зрения влияния, которое он имеет на дальнейшую работу в проекте. Список предположений — это наши гипотезы, в которых мы не были уверены, и исходя из которых мы сформировали документ.
Далеко не все вопросы могут быть разрешены с помощью целенаправленного исследования, или их разрешение стоит достаточно дорого.
В этой ситуации приходится делать некоторые предположения. Мы можем предположить, что какое-то оборудование будет доставлено к какому-то сроку. Или мы можем предположить, что какой-то проект, реализующий часть большой системы, с которой мы взаимодействуем, также будет реализован. Или, к примеру, мы можем предположить, что к моменту, когда будет сформировано какое-то подразделение, у него появятся какие-то конкретные требования.
Вся неопределенность, которую мы раскрываем не с помощью достоверной информации, а сделав некоторое предположение — это риски проекта. Если не реализуется какое-то предположение, то, скорее всего, и целостность наших требований, возможность достижения бизнес-результатов, окажется под угрозой. Поэтому это очень важный раздел, который часто забывают — перечень предположений, на которых мы основываемся для того, чтобы выдвигать и формулировать требования.
Итак, бизнес-требования — документ, который фиксирует решения уровня бизнес-среды, бизнес-системы с точки зрения того, какие задачи мы собираемся решить для того, чтобы достичь бизнес-целей. В этом документе не принято формулировать большое количество функциональных или детальных архитектурных решений, только те требования, которые определены бизнес-средой или контекстом системы, в которой она будет использована.
Источник: requirements.ru