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

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

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

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

4. Функциональные требования, тикеты, JIRA (Курс бизнес-аналитик с нуля)

1. Единичность — требование описывает одну и только одну вещь.
2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4. Атомарность — требование нельзя разделить на более мелкие.
5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6. Актуальность — требование не стало устаревшим с течением времени.
7. Выполнимость — требование может быть реализовано в рамках проекта.
8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10. Проверяемость — реализованность требования может быть проверена.

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

1. Что ПО должно делать. Пример — Позволять клиенту оформить заказы и обеспечить их доставку;

Функциональные требования. Это документ или часть ТЗ

2. Насколько оно должно быть надежно. Пример — Работать 7 дней в неделю и 24 часа в сутки;
3. Насколько им должно быть удобно пользоваться. Пример — Покупатель должен легко находить нужный ему товар;
4. Насколько оно должно быть эффективно. Пример — Поддерживать обслуживание до 10000 запросов в секунду;
5. Насколько удобно должно быть его сопровождение. Пример — Добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;
6. Насколько оно должно быть переносимо и заменяемо. Пример — ПО должно работать на операционных системах Linux, Windows XP и Mc OS X;

Уровни требований (по К.Вигерсу)

Обычно выделяют три уровня требований:
1. На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
2. Следующий уровень – уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
3. Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

Классификация требований

1. Функциональные требования описывают, что делает система, это требования к первой составляющей качества — функциональности. Эти требования обычно ориентированы на действия (Когда пользователь нажимает кнопку «Обработать заказ», система сохраняет данные заказа в БД и определяет его статус как «В очереди на обработку»).
При определении функциональных требований следует искать золотую середину между слишком конкретизированной формулировкой требования и слишком общей и неоднозначной. Требования должны оставаться понятными заказчикам и стать более понятны разработчикам.
К функциональным требованиям относят:
1.1. Бизнес-требования. Что система должна делать с точки зрения бизнеса. Слово «бизнес» в данном контексте ближе к слову «заказчик». Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
1.2. Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования. Иначе говоря, пользовательские требования — это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
1.3. Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.
1.4. В группу функциональных требований относят и Системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.).

Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта — объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС — Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

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

2. Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2] выделяет следующие основные группы нефункциональных требований:
2.1. Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными.

Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
2.2. Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия «сайт-CRM» также относятся к нефункциональным требованиям.
2.3. Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
— легкость и простота использования (usability)
— производительность (performance)
— удобство эксплуатации и технического обслуживания (maintainability)
— надежность и устойчивость к сбоям (reliability)
— взаимодействия системы с внешним миром (interfaces)
— расширяемость (scalability)
— требования к пользовательским и программным интерфейсам (user and software interface).
2.4. Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных и т.д.). Ограничения часто основываются на бизнес-правилах.

Выявление требований

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

Стадию выявления и представления требований условно можно разделить на 4 этапа:
1. Выявление требований сбор информации.
2. Первичный анализ требований.
3. Документация требований.
4. Проверка требований.

Данные этапы будут выполняться, чередуясь и периодически повторяясь. Этот итерационный процесс и есть процедура выявления требований.

Источники требований

1. Заинтересованные лица – как правило, являются первым и основным источником требований.Заинтересованные лица – как правило, являются первым и основным источником требований;
2. Документация – все документы, присутствующие в компании или относящиеся к правовой системе страныбизнеса, являются источником требований, который чаще всего определяет те или иные ограничения проекта;
3. Сегмент рынкабизнеса – конкурентные системы будущего продукта являются незаменимым источником требований. Благодаря изучению систем-аналогов можно существенно уменьшить время на выявление требований. Также незаменимым источником являются различные маркетинговые материалы;
4. Бизнес заказчика – специфика бизнеса заказчика, наблюдение за работой будущих пользователей, бизнес-процессы организации – все так или иначе создает образ будущей системы и позволяет точнее определить потребности заказчика, а также проблемы, которая будущая система призвана решить.

Способы выявления требований

1. Опрос – подразумевает опрос существующих и потенциальных пользователей продукта (например, интервью, анкеты);
2. Наблюдение – подразумевается наблюдение за работой пользователей;
3. Изучение правил работы пользователей по существующим регламентам/законодательству, а также изучение существующих документов, описывающих бизнес клиента или существующего продукта;
4. Анализ истории использования продукта по его техническим журналам;
5. Изучение существующих продуктов конкурентов на рынке;
6. Обсуждения и мозговые штурмы с пользователями и экспертами;
7. Маркетинговые исследования;
8. Моделирование – может включать в себя как моделирование существующих бизнес-процессов, так и верхнеуровневое моделирование будущей системы.

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

Стандарты

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

Функции стандартов

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

Уровни стандартов

Стандарты имеют распространение в пределах компетенции органа который их принял. Соответственно различают следующие уровни стандартизации:

• Международная стандартизация. Органом по стандартизации является ИСО (ISO). Нормативным документом ИСО являются стандарты ИСО.
• Межгосударственная стандартизация. Охватывает ряд независимых государств (СНГ, ЕЭС и др.). Нормативным документом стран СНГ является межгосударственный стандарт.
• Национальная стандартизация — это стандартизация в пределах одного государства (к примеру стандарты ДСТУ или ГОСТы).
• Правила, нормы и рекомендации в определенной области — действуют в границах определенных сфер деятельности (к примеру IEEE)
• Стандарты организаций — сюда входят стандарты предприятий, стандарты обществ и т. п.

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

Продуктная документация (product documentation)

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

• План продукта (Product Management Plan)
• Документ бизнес-требований (Business Requirements Document)
• Маркетинговая документация (Market Requirements Document)
• Документ требований к программному продукту (Product Requirements Document) или спецификация требований (Software Requirements Specification);
• Спецификация функциональных требований (Functional Specifications Document);
• Техническое задание (Terms of Reference TOR);
• Mind Maps, Макеты, Прототипы;
• Use Cases и User Story;
• Дизайн (Graphic Design, Web Design, Game design).

Проектная документация

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

• План проекта (Project Management Plan)
• Пользовательская и сопроводительная документация (User and Accompanying Documentation)

Источник: qa-guide.ru

Как оформить функциональные и бизнес-требования к сайту электронной коммерции?

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

5367 просмотров

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

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

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

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

• Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
• Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
• Анализ конкурентов
• Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
• Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах) . Ускорить обработку заказов через автоматизацию работы менеджеров.
• Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 0,8% до 1,1%. Втрое увеличить количество вендоров. Поднять прямые онлайн-продажи без похода в магазин на 30% за полгода.
• Пользовательские требования, то есть какую задачу должен решить пользователь на сайте. Купить шампунь, если речь идет о покупателе на сайте. Организовать доставку в другую страну, если пользователь — другая компания. Увеличить заработок для вендора. Иметь доступ только к заказам для менеджера по продажам и так далее.

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

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

• Требование А. Чтобы привлечь вендоров, владелец маркетплейса может предложить продавцам продолжать работать в собственных системах, интегрировав эти системы в маркетплейс. Вендорам не придется изучать интерфейс новой для себя системы, а владелец будет иметь все необходимые данные на своей платформе. Таким образом, способом реализации продукта станет интеграция с сервисами вендора по API.
• Требование Б. По условию франшизы за определённой территорией может быть закреплен только один продавец / территориальный представитель, который будет работать с заказами покупателей из данного региона. Продажа товаров на данной территории другими представителями бренда запрещена по условиям договора. Способ реализации: определение геолокации покупателя, сортировка товаров и отображение актуальных остатков для конкретной локации, привязка покупателя к продавцу для дальнейших заказов.
• Требование В. Владелец сайта-каталога (где можно просматривать товары, но нельзя покупать их) хочет создать интернет-магазин без перехода на новую платформу. В связи с этим, требуется внедрить функционал оформления заказа из платформы CS-Cart таким образом, чтобы для покупателя это выглядело «бесшовно», как будто он и не покидал существующий сайт. Способ реализации: интеграция технологии единого входа — SSO — при которой пользователь переходит из одной системы в другую без повторной аутентификации.

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

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

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

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

• Опишите ваш продукт / услугу. Что будет являться товаром? Какие его характеристики? Как будет считаться его стоимость?
• Роли пользователей (администратор, продавец покупатель) и какие действия может выполнять каждый из них? Есть ли какие-либо зависимости / ограничения?
• CJM (путь покупателя по сайту) : какими будут действия покупателя по приобретению вашего продукта? Какие соответствующие действия должен будет выполнять продавец / администратор?
• Регистрация пользователей: какие данные должны предоставить пользователи для регистрации?
• Как будет выглядеть личный кабинет (профиль) покупателя для пользования услугой? Какие действия он сможет выполнять?
• Понадобится ли интеграция со сторонними системами? Какими?

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

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

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

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

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

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

• Дизайн, UX/UI. Добавить дополнительную кнопку на чекауте. При переходе на страницу продукта пользователь видит все вариации продукта.

• Требования к коду: cделать модификацию на JS, работа в репозитории клиента, использовать указанные заказчиком библиотеки при реализации модификации.

• Настройка процессов непрерывной доставки и улучшения кода. CI и CD процессы призваны автоматизировать проверку и доставку разработанного ПО заинтересованным лицам.

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

• Контент. На продуктовые страницы добавить ссылки на юридические документы. Такое требование часто озвучивают владельцы немецких маркетплейсов.

• Производительность сайта. Магазин должен выдерживать нагрузку в 1000 посетителей онлайн одновременно.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Примеры конкурентов и реализации желаемого функционала
• Блок-схема с описанием бизнес-процессов, функциональности
• CJM-карта
• Архитектурная диаграмма
• Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя)
• Дизайн-макеты
• План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т. п.
• Список ролей участников проекта и схема принятия решения
• User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя) .

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

• Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
• Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor) , но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart) . До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
• Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который плохо выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.

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

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

• Пример 1. Форма для регистрации интуитивно понятна.

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

• Пример 2. Магазин не должен тормозить.

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

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

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

• Просмотр истории визитов;
• Добавление еще одного визита;
• Выбор посещения зубного кабинета;
• Просмотр деталей визита (число, время, кабинет, лечащий врач) ;
• Редактирование информации о визите;
• Удаление визита.

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

• Анкетирование. Сюда можно отнести “Бриф на разработку сайта”. Это анкета со списком основных требований к сайту.
• Интервью. Такой способ используется в основном для получения уточнений по конкретному вопросу или требованию.
• Мозговой штурм. Участники генерируют множество идей и вариантов решений, развивая.
• Запустить голосование
• Привлечь эксперта

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

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

Виды требований к программному продукту

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый — это закон о персональных данных. Он накладывает требования на сайты, касающиеся хранения и обработки персональных данных клиентов.

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

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

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

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

Многие существующие методы разработки требований относятся именно к этому уровню. Сюда входят такие подходы как Use Cases (варианты использования), User Stories (пользовательские истории), метод «персон» и некоторые другие, менее распространенные методы. Эти методы наиболее глубоко проработаны и концептуально завершены, так как они относятся к уровню взаимодействия людей с продуктом и описывают его видимое поведение.

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

Также мы можем формулировать требования в виде набора пользовательских историй (user stories), например, для интернет-магазина. Если я хочу совершить покупку на сайте, мне потребуются пользовательские истории для сравнения товаров, добавления товаров в корзину, управления корзиной и оформления заказа, а также для онлайн-оплаты. Каждая пользовательская история формулируется по определенному формату, который здесь не представлен.

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

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

Атрибуты качества — это еще один вид требований, который мы рассмотрим подробнее в этом курсе.

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

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