В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта. Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
Пример функционального требования:
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
В случае с системой баннерной рекламы, мы выделим такой сценарий как создание рекламного места пользователем в роли Администратор.
Название сценария: Создание рекламного места
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест). После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Каждое созданное рекламное место получает универсальный идентификатор, который используется системой управления сайтом в запросе на показ баннеров. Для этого требуется внести соответствующие изменения в код страницы сайта».
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий, разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Источник: poisk-ru.ru
Виды требований к программному продукту
Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.
Давайте более подробно рассмотрим, какие бывают виды требований. Мы воспользуемся классификацией, которую предложил Карл Вигерс. Вероятно, вы уже знакомы с этой классификацией. Мы не просто повторим данные Вигерсом определения, а для каждого вида требований я приведу примеры.
Есть такая схема от Вигерса, где он раскладывает все виды требований. Эти названия уже стали своего рода классикой, многие аналитики их применяют в работе. Но иногда всё равно бывает путаница. Поэтому давайте разберем каждый из них по отдельности.
В курсе эти названия видов требований будут использоваться довольно активно. Когда мы будем говорить о методах разработки требований, мы всегда будем подразумевать какой-то определенный вид требований в соответствии с этой классификацией.
Первыми на очереди идут бизнес-требования. Они представляют высокоуровневые цели организации или заказчика системы, которых они хотят достичь посредством разрабатываемой системы.
Я знаю, что эти определения могут звучать сложно и немного запутанно. Они взяты дословно из книги Вигерса, но давайте попробуем перевести их на простой язык, чтобы все стало яснее.
Так в чем же смысл бизнес-требований? Они описывают бизнес-идею, без реализации которой создаваемый продукт не будет нужен потребителю. В бизнес-требованиях мы находим описание всех тех проблем, которые создаваемый продукт должен решать, и возможностей, которые он должен реализовать.
Возьмем для примера разработку сайта поиска авиабилетов. В бизнес-требованиях к такому сайту мы опишем его основные функции и возможности.
Для посетителей сайта это возможность быстро и легко найти самый выгодный по цене маршрут и таким образом сэкономить деньги. Кроме того, сайт помогает сэкономить время на планирование поездки, так как вам не нужно просматривать разные сайты разных авиакомпаний и сравнивать цены. Именно это и делает такие сервисы популярными — они помогают людям экономить время.
Авиакомпании благодаря сайту получают дополнительный канал продажи своих билетов. А владелец сайта может использовать его для продажи других услуг, например, бронирования автомобилей, бронирования отелей или заказа такси.
Все эти возможности вполне можно включить в Концепцию нашего продукта в качестве бизнес-требований, и эти бизнес-требования будут определять образ нашего продукта в целом и влиять на способ его разработки.
Здесь нужно сделать оговорку, что приведенные примеры несколько искусственны и не вполне похожи на формулировки требований в реальных документах. В процессе изучения методов разработки бизнес-требований мы увидим, что за этими формулировками скрывается список заинтересованных лиц (в нашем примере это посетители сайта, авиакомпании и владелец сайта), список предлагаемых продуктом возможностей, а также проблемы, которые он решает.
Часто бизнес-требования путают с бизнес-правилами из-за общего префикса «бизнес» в названии. Что такое бизнес-правило? Это положение, которое определяет или ограничивает определенные аспекты бизнеса. Вместо того чтобы просто перечитать определение Вигерса, давайте сразу перейдем к примерам, чтобы прояснить, что это означает.
Во-первых, под бизнес-правилами подразумеваются документы, которые регулируют на уровне законов или отраслевых стандартов работу нашего продукта. Если мы, например, разрабатываем банковскую систему, то существует множество правил, установленных центральными банками. В России это Центральный Банк, который издает различные инструкции, которым банковская система обязана следовать.
Это также относится к законам. Сейчас для интернет-проектов в России это становится все более актуальным, поскольку издаётся все больше законов, регулирующих эту сферу.
Бизнес-правила также могут быть общепринятыми или стандартными функциями и алгоритмами, которые должны быть реализованы в системе. Простой пример — алгоритм расчета НДС, который также является бизнес-правилом.
Таким образом, бизнес-правила — это требования, установленные в бизнес-практике, законодательстве или отрасли, которым мы обязаны следовать при реализации нашей системы.
Недавно стали актуальны два федеральных закона, касающихся практически всех сайтов, осуществляющих продажи в интернете.
Первый — это закон о персональных данных. Он накладывает требования на сайты, касающиеся хранения и обработки персональных данных клиентов.
Второй закон затрагивает все сайты, на которых что-либо продается с использованием электронных денег или банковских карт. Согласно этому закону, к таким сайтам должна быть подключена онлайн-касса.
Это очевидный пример того, как бизнес-правила влияют на требования к веб-сайту. Для реализации этих правил потребуется разработка более детализированных требований, включая определенные интерфейсы, функции и специфическое поведение сайта в различных ситуациях.
Следующий вид требований: пользовательские требования.
Пользовательские требования представляют собой обширную категорию, которую я уже достаточно подробно разбирал, обсуждая второй — пользовательский — уровень требований. Эти требования описывают конкретный способ использования продукта его конечными пользователями.
Многие существующие методы разработки требований относятся именно к этому уровню. Сюда входят такие подходы как Use Cases (варианты использования), User Stories (пользовательские истории), метод «персон» и некоторые другие, менее распространенные методы. Эти методы наиболее глубоко проработаны и концептуально завершены, так как они относятся к уровню взаимодействия людей с продуктом и описывают его видимое поведение.
Например, мы можем разработать детальный сценарий покупки авиабилета по заданному маршруту. Этот сценарий, в свою очередь, станет формой представления пользовательских требований.
Также мы можем формулировать требования в виде набора пользовательских историй (user stories), например, для интернет-магазина. Если я хочу совершить покупку на сайте, мне потребуются пользовательские истории для сравнения товаров, добавления товаров в корзину, управления корзиной и оформления заказа, а также для онлайн-оплаты. Каждая пользовательская история формулируется по определенному формату, который здесь не представлен.
Каждая пользовательская история — это своего рода атомарный блок в процессе разработки требований, обладающий своими уникальными характеристиками и создаваемый по определенной методике.
Все эти примеры относятся к пользовательским требованиям. Их может быть гораздо больше, но, я думаю, уже приведенных примеров достаточно для общего понимания.
Атрибуты качества — это еще один вид требований, который мы рассмотрим подробнее в этом курсе.
Что же это такое? Это свойства продукта, которые определяются через описание характеристик, важных как для пользователей, так и для разработчиков. Это определение может показаться несколько непонятным, но давайте расшифруем его.
Существует понятие «качества программного обеспечения» или «качества программного продукта». Для этого понятия существуют стандарты, своя теория, методы оценки и обеспечения качества. И в основе этого всего лежит множество разных точек зрения на то, как должен работать программный продукт.
Мы обсудим эти точки зрения позже в этом курсе, а пока давайте рассмотрим примеры, которые представляют различные подходы к пониманию качества.
Стоит подчеркнуть, что приведенные здесь примеры — это не атрибуты качества в чистом виде, а требования, которые представляют эти атрибуты качества в контексте создаваемого продукта.
Рассмотрим некоторые из них. Время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества, такие как «производительность» (время загрузки страницы) и «надежность» (способность сайта справляться с определенной нагрузкой). Эти характеристики, очевидно, важны для пользователя продукта.
Другое требование: база данных сайта должна устанавливаться на серверах MySQL, MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Здесь проявляется атрибут качества «переносимость», который подразумевает возможность установки сайта в различные среды без дополнительных модификаций. Этот атрибут качества важен для разработчиков системы, а не для конечных пользователей, которые обычно даже не знают, как СУБД используется в продукте.
И последний пример: сайт должен быть адаптирован для мобильных устройств. Это требование отражает атрибут качества «удобство использования» или «юзабилити», который подчеркивает важность комфорта пользователя при работе с продуктом.
Это лишь некоторые примеры, и они не отражают все возможные атрибуты качества. Мы подробнее рассмотрим их разнообразие позже, но сейчас важно понять, что они являются ключевым элементом в структуре требований.
Хотел бы отметить, что книга Вигерса, которая была упомянута ранее, пережила уже три издания, и в каждом из них он немного изменял эту схему. Он перемещал отдельные виды требований между разными уровнями и менял их взаимосвязи. Это нормально и отражает тот факт, что все требования тесно связаны друг с другом. Например, раньше бизнес-правила были размещены на втором уровне, а сейчас они были перемещены на уровень бизнес-требований.
Далее мы переходим к ограничениям — это еще один вид требований. Они представляют собой условия, которые модифицируют требование или набор требований, сужая тем самым выбор возможных решений. Как правило, это внешние по отношению к системе условия или решения, принятые ранее.
Наиболее известными нам являются, вероятно, технические ограничения, которые часто фиксируются в техническом задании, исходя из возможностей, которыми обладают заказчик или разработчик.
Возьмем в качестве примера следующее ограничение: сервер приложений сайта должен разрабатываться на языке Java. Почему такое требование может быть предъявлено? Возможно, потому что у заказчика имеется большое количество специалистов, способных сопровождать работу системы, написанной на этом языке, а все остальные серверы приложений заказчика также функционируют в этой среде.
Другой похожий пример: сайт должен устанавливаться на определенную версию операционной системы.
Приведенные случаи представляют собой наиболее простые виды ограничений. Однако встречаются и более сложные. Эти ограничения мы должны учитывать еще до начала разработки системы, поскольку они сужают область возможных решений в процессе ее создания.
Следующий вид требований: внешние интерфейсы. Это описание интерфейса между системой и пользователем, другой системой или оборудованием.
Сегодня внешние интерфейсы играют все более важную роль в разработке систем. В эпоху интернета, когда приложения все чаще взаимодействуют друг с другом и создают единую среду, внешние интерфейсы начинают замещать и даже вытеснять пользовательские требования. Хотя большинство систем по-прежнему разрабатывается для людей, все больше систем создается с целью обеспечения взаимодействия между машинами.
Обычно внешние интерфейсы с другими системами уже описаны в виде спецификаций, которым нужно следовать при разработке продукта.
Вот несколько примеров внешних интерфейсов:
1. API социальных сетей для автоматического репоста публикаций с сайта на страничку компании в Facebook. Таким образом, нет необходимости вручную копировать новости, специальное приложение сделает это автоматически.
2. Спецификация взаимодействия с платежным агрегатором для обработки онлайн-платежей на сайте интернет-магазина. Это описание внешнего интерфейса представляет собой определенную спецификацию передачи данных.
3. Протоколы взаимодействия с серверами транспортных компаний для резервирования и оплаты билетов. Например, единый сервис для сравнения и покупки авиабилетов разных авиакомпаний требует наличия внешних интерфейсов для взаимодействия с различными сервисами резервирования и оплаты билетов.
Системные требования — это, пожалуй, один из самых непонятных видов требований, описанных Вигерсом. В книге он касается этой темы лишь косвенно, и в результате под системными требованиями люди могут понимать абсолютно разные вещи.
В оригинальном понимании Вигерса, системные требования — это требования к продукту, который включает в себя несколько подсистем. Иными словами, это требования, описывающие взаимодействие этих подсистем.
Однако, в практике многих компаний термин «системные требования» часто применяется для обозначения требований третьего уровня. Большинство специалистов понимают, что такое бизнес-требования и пользовательские требования. Но когда речь идет о третьем уровне, мнения расходятся. Я предпочитаю использовать термин «требования к реализации», Вигерс же предлагает «функциональные требования». В то же время, некоторые компании используют для этого уровня термин «системные требования».
В контексте терминологии Вигерса, системные требования можно проиллюстрировать на следующем примере. Допустим, у нас есть интернет-банк, и требуется, чтобы доступ к операциям со счетом осуществлялся через единый сервер приложений. С этим сервером могут взаимодействовать различные клиентские приложения: интернет-банк в браузере пользователя, мобильное приложение или отдельное Java-приложение на компьютере пользователя. Это требование описывает систему в целом, и дает нам понимание, что есть несколько вариантов клиентской части приложения, но все они должны работать с единым сервером.
Функциональные требования — это еще один вид требований, определенных Вигерсом. Именно из-за их общности и всесторонности этот термин может вызывать путаницу. В сущности, функциональные требования включают все требования, которые не относятся к другим категориям. Они описывают, как система должна функционировать, и могут быть представлены в самых разнообразных форматах.
Вигерс определяет функциональные требования как «описание функциональности, которую следует реализовать в разрабатываемой системе, чтобы пользователь мог выполнить свои задачи в рамках бизнес-требований». Такое определение помогает лучше понять, почему в данном контексте используется слово «функциональные».
Вот примеры функциональных требований.
1. На сайте должен быть реализован поиск статей по ключевым словам и по проставляемым тегам. Это требование описывает необходимую функцию «поиск» на сайте.
2. Операции оплаты со счета должны быть доступны только с использованием двухфакторной авторизации. Это функциональное требование ограничивает возможные методы работы с счетом в интернет-банке.
Эти примеры, конечно, отражают лишь малую часть возможных функциональных требований. Они могут быть очень разнообразными и сильно зависят от конкретной разрабатываемой системы. Как правило, техническое задание или спецификации требований состоят из множества утверждений, каждое из которых можно отнести к функциональным требованиям.
Таким образом, мы завершаем обзор видов требований. Это был лишь краткий обзор, предназначенный для введения базовой терминологии. В дальнейшем, при детальном изучении каждого вида требований, это понимание поможет нам избежать путаницы и недопонимания.
Источник: www.webursitet.ru
