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

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

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

1. функциональное требование
2. нефункциональные требование
3. количественная оценка и прослеживаемость Требования

автор: Somnath Muluk

функциональные требования-это те, которые связаны с технической функциональностью системы.

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

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

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

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

автор: Maruthi Srinivas

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ действия, которые должна выполнять система

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

автор: ABDUL

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

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

Бриф, функциональное и техническое задание на разработку интернет-магазина: зачем составлять и как это правильно делать

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

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

Содержание

Бриф, функциональное и техническое задание для интернет-магазина — в чем разница?

Разработка интернет-магазина должна начинаться с последовательности шагов:

1. Заполнение брифа
2. Составление функционального задания
3. Составление технического задания для интернет-магазина

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

Составление этих документов — не пустая трата времени. Только так можно получить адекватную смету, которая не увеличится в 2-3 раза в итоге написания ТЗ на разработку. Ответственный подход к составлению брифа и ФЗ застрахует вас от сюрпризов не только в плане стоимости, но и в плане сроков. Вы сэкономите время и деньги впоследствии, сразу получив нужный результат.

Как составить бриф на интернет-магазин

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

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

Основные блоки брифа

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

Важные разделы интернет-магазина

Как составить функциональное задание

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

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

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

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

Два подхода к составлению функционального задания:

1. Описание функциональных ролей

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

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

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

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

Пример из функционального задания

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

Пользователь может:

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

2. Описание функционала и интеграций

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

К сожалению, многим клиентам кажется, что они готовят полноценное техническое задание на разработку интернет-магазина. И когда у клиента во время знакомства со сметой возникает вопрос: «У нас же есть ТЗ, почему в смете вы закладываете на него время?», нам приходится объяснять разницу между функциональным и техническим заданиями.

Конечно, если техническое задание на разработку интернет-магазина в редакции заказчика достаточно детализированное, мы учитываем это и уменьшаем трудозатраты на написание ТЗ разработчиками, но такая детализация и соответствие общепринятым стандартам — большая редкость. Например, в ТЗ на создание интернет-магазина, составленных клиентами, точно не встретишь описания интеграций с 1С.

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

Пример функционального технического задания

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

Стоимость создания интернет-магазина по брифу составляла 1 800 000 рублей, а после создания ФЗ увеличилась практически в 1,5 раза — до 3 000 000 рублей.

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

Как составляется техническое задание для интернет-магазина

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

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

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

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

Разработка архитектуры программного обеспечения. Аналитический синтез информации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сначала мы рассмотрим функциональные требования .

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

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

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

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

• Цели разрабатываемого функционала;
• Задачи, которые должны быть выполнены для достижения поставленной цели;
• Сервисы, поддерживающие выполнение задач;
• … (и многое другое, касающееся непосредственно функциональных возможностей и особенностей программного продукта);

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

• Классический подход

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

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

• Use cases (Варианты использования);

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

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

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

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

Они регламентируют внутренние и внешние условия функционирования программного продукта. Выделяют следующие основные группы нефункциональных требований:

• Атрибуты качества;

• Безопасность;
• Надежность;
• Производительность;

• Скорость и время отклика приложения;
• Пропускная способность workflow;
• Количество необходимой оперативной памяти;

• Платформа реализации архитектуры и программного продукта;
• Тип используемого сервера приложений;

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

Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии со стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с после того, как поступила соответствующая команда «

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

Прочие виды требований

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

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

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

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

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

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

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

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

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

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