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

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

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

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

Самый первый вид требований: бизнес-требования. Что это такое, обобщённо? Описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как я уже сказал, основная масса существующих методов разработки требований относится именно к этому уровню. Use Cases, User Stories, «персоны» и ещё некоторые методы, не так часто используемые. Лучше всего проработанные, концептуально завершенные, они как раз относятся к уровню взаимодействия людей с продуктом. Но это естественно, потому что продукты, в основном, до сих пор создаются для людей.

Здесь может быть очень много разных примеров. Я даже не стал их детализировать.

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

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

Каждая user story — это такой единичный кусок, unit при разработке требований, обладающий своими собственными характеристиками, и разработанный по определённому методу.

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

Атрибуты качества. Более детально мы атрибуты качества рассмотрим ещё сегодня на этом вебинаре.

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

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

Мы сегодня эти точки зрения рассмотрим на этом вебинаре, а пока три примера, которые разные точки зрения представляют.

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

Например, время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надёжность». Производительность — это время загрузки страницы, а надёжность — это какую нагрузку должен держать сайт.

База данных сайта должна устанавливаться на сервера mysql или MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Это, опять же, конкретное представление требования, которое отражает такой атрибут качества как «переносимость». Мы можем наш разработанный сайт устанавливать в разном окружении, и при этом должны быть реализованы эти требования, чтобы мы могли использовать разные системы баз данных.

Сайт должен быть адаптирован для мобильных устройств. Это может вам показаться спорным, но это требования тоже отражают атрибут качества. Удобство использования тоже является атрибутом качества. Сейчас он больше известен под словом «юзабилити», которое в стандарте последнем так и переведено: «удобство использования».

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

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

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

Мы лучше всего знаем, наверное, ограничения технические, которые часто отражаются в ТЗ, исходя из имеющихся возможностей заказчика или разработчика.

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

Или похожий пример: сайт должен устанавливаться на определенную версию операционной системы.

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

Внешние интерфейсы. Описание интерфейса между системой и пользователем, другой системой или оборудованием.

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

Ну например, что это может быть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предыдущий урок: Уровни требований к программному продукту

Следующий урок: Функциональная и нефункциональная стороны программного продукта