Описание бизнес требований к системе

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

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

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

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

Вот несколько преимуществ, с которыми пользователи и разработчики программного обеспечения могут столкнуться при использовании функциональных требований:

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

Какие детали включают функциональные требования?

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

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

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

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

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

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

Читайте также: Рам это в бизнесе

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

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

Веб-сайт

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

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

Мобильное приложение

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

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

Система управления клиентами

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

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

Программное обеспечение для продаж

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

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

Программное обеспечение для видеоигр

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

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

Источник: buom.ru

Классификация требований. Часть 2. Бизнес требования.

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

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

По моему мнению, к бизнес требованиям (БТр) необходимо относить артефакты требований, отвечающие на вопрос – зачем? Таким образом, к БТр я бы отнес следующее:

• Бизнес-процессы

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

• Заинтересованные лица (ЗЛ) и их потребностей

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

• Проблемы, которые будет решать Система

Тут нужно сказать, что необходимо выявить корневые проблемы (а не симптомы), которые будут решены, когда Система будет работать.
Шаблон для описания проблем можно использовать следующий:
o Проблема: Описание проблемы
o Затрагивает: ЗЛ, которых затрагивает проблема
o Влияет на: На что влияет (что затрагивает выше) эта проблема
o Решение позволит: Ключевые преимущества, которые получат ЗЛ при решении этой проблемы
Проблемы я бы отнес к ФТ.

• Цели создания Системы

Это наверное главное, что должно быть в БТр – цель, т.е. зачем или для чего мы создаемвнедряеммодифицируем нашу Систему. Почему цели так важны? Как минимум:
o Договориться с заказчиком – куда бежим и что ключевое решаем, это очень поможет на этапе разработки. Заказчик зачастую сам до конца не знает – зачем мы разрабатываем Систему, а после открытия глаз, может скорректировать движение или даже отказаться от проекта.
o При поступлении заявок на доработки понять – в рамках проекта эта заявка (соответствует цели) или нет.
Нужно стараться, чтобы цель была описана по SMART критерию. Много про цели писал Сергей Нужненко.
Как и проблемы, Цели я бы отнес к ФТ.

• Основные функции Системы (фичи)

Ну а как же не обозначить основные функции предлагаемого решения?! Описание 10-15 таких основных функций (или задач, которые решает Система) должны быть определены в БТр.
Естественно Основные функции Системы относятся к типу ФТ.

• Бизнес ограничения

Безусловно Заказчик должен высказать основные бизнес ограничения, которые должны быть зафиксированы в БТр.
Как, пример, можно привести следующие бизнес ограничения:
o Соблюдение требований ФЗ-152 о персональных данных
o Система должна быть сделана на платформе 1С (если это важно для бизнеса)
o Обмен данными с другими Системами должен соответствовать стандарту EDI.
o И т.д.
Бизнес ограничения относятся к типу НФТ.

• Диаграммы

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

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

Вроде бы ничего я не забыл, постарался подробно рассказать про БТр, до встречи в следующих частях.

Источник: www.uml2.ru

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

Как описать бизнес-правила. Отличия бизнес-правил от требований к системе

Работа над каким-либо IT-продуктом/системой всегда начинается со сбора требований.

В идеальной вселенной, со стороны представителя бизнеса работает бизнес-аналитик, который собирает пожелания, требования заказчиков и формирует их в бизнес-правила. Далее уже над бизнес-правилами работает системный аналитик, формируя требования к системе. Но, зачастую, позицию “бизнес-аналитик” опускают: в бизнесе данная позиция отсутствует, в IT- команде данную роль совмещает в себе системный аналитик. У многих встает вопрос, как же правильно выделить бизнес-правила, чем они отличаются от требований к системе и зачем вообще их выделять, разве нельзя сразу приступить к формированию требований к системе?

Для начала, давайте определимся с понятиями “Бизнес-правила” и “Системные требования”.

В группе Business Rules Group (2012) дали определение бизнес-правил с точки зрения как бизнеса, так и информационных систем.

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

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

Выделять бизнес-правила необходимо на первом этапе работы над продуктом:

Выявить правила бизнеса;
Задокументировать;
Согласовать с бизнесом.

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

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

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

Бизнес-правило

Требование к системе

Постоянный посетитель библиотеки может отложить для себя до 10 книг.

Посетитель, имеющий карточку в библиотеке; посещающий библиотеку не менее 1 раза в месяц является постоянным.

Постоянный посетитель должен иметь возможность отложить для себя 10 книг.

Клиент компании может оформить заказ с оплатой курьеру.

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

Пользователь, должен иметь возможность оформить заказ.

Заказ может быть оформлен:

с доставкой по указанному адресу;

с оплатой наличными при получении;

с оплатой банковской картой при получении.

Бизнес-правила существуют для четкого определения целей бизнеса.
Бизнесу понятен язык бизнес-правил. Язык описания требований к системе бизнесу непонятен. На этапе согласования БП бизнес сможет понять, правильно ли зафиксировали их пожелания и требования.
Бизнес-правила являются основой для написания требований к системе. Одно бизнес-правило может являться источником для нескольких требований к системе.
Правильно зафиксированные бизнес-правила сокращают риски на разработку. Не забываем золотое правило: “Чем раньше выявлены неточности в зафиксированных требованиях- тем дешевле стоит их исправить!”

Собирайте бизнес-правила, создавайте продукты, отвечающие требованиям заказчика!

Материал для данной статьи подготовлен с помощью книги К. Вигерса «Разработка требований к ПО», 3-е издание, 2021 г.

Источник: temofeev.ru