Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.
Давайте более подробно рассмотрим виды требований, и будем при этом пользоваться классификацией Вигерса. Возможно, многие из вас уже с этой классификацией знакомы. Я для каждого вида требований приведу пример.
Вот эта картинка Вигерса, о которой я уже говорил, и на которой он перечислил различные виды требований. Эти названия уже, пожалуй, общеприняты. Большинство аналитиков их понимает, но иногда
В курсе будет эта терминология использоваться довольно активно, потому что когда мы будем говорить о методах разработки требований, мы всегда будем подразумевать
Самый первый вид требований:
Я понимаю, что эти определения несколько суконным языком написаны. Но я взял их из книги Вигерса, и мы попробуем перевести их на простой человеческий язык.
Что дает описание бизнес требований? Описывает
Например, если мы разрабатываем сайт поиска авиабилетов, мы можем описать в
Например, посетителю сайта он обеспечивает возможность подобрать оптимальный по цене маршрут, чтобы сэкономить деньги. Также позволяет сэкономить время планирования поездки, потому что поиск авиабилетов на разных сайтах разных авиакомпаний и их сравнение всегда требует большого количества времени. Поэтому многие пользуются подобными сервисами именно для того, чтобы сэкономить время.
Авиакомпаниям дает возможность использовать дополнительный канал продаж авиабилетов. Владельцу сайта дополнительно может дать возможность продавать на сайте
Вполне можно включить такой перечень возможностей в Концепцию, и эти
Тут я должен сделать оговорку, и я её сделаю ещё не раз в этом модуле, что те примеры, которые я привожу, достаточно искусственны в том смысле, что они не похожи на реальные формулировки требований в реальных документах. Но мы будем изучать собственно методы разработки
В конечном итоге при описании требований они будут выглядеть несколько иначе. Но для того, чтобы понять, что стоит за этим видом требований, я привел такой пример. В данном случае этот перечень возможностей —
Часто
За этим стоят,
Это законы. Сейчас это становится более актуальным для
Это могут быть ещё
То есть, ещё раз, это такие требования, принятые в практике бизнеса, либо в законодательстве, либо в отрасли, которые мы в любом случае должны исполнять при реализации нашей системы.
Ну вот, собственно, пример, ставший актуальным как раз в этом году, и ещё не все
И второй закон, который тоже был принят в этом году. Если
Вот простой и очевидный пример того, как
Следующий вид требований: пользовательские требования.
Это большой класс требований. Я его, наверное, достаточно подробно описал, когда говорил о втором — пользовательском — уровне требований. Описывает конкретный способ использования продукта конечным пользователем.
Как я уже сказал, основная масса существующих методов разработки требований относится именно к этому уровню. Use Cases, User Stories, «персоны» и ещё некоторые методы, не так часто используемые. Лучше всего проработанные, концептуально завершенные, они как раз относятся к уровню взаимодействия людей с продуктом. Но это естественно, потому что продукты, в основном, до сих пор создаются для людей.
Здесь может быть очень много разных примеров. Я даже не стал их детализировать.
Например, мы можем описать пошаговый сценарий покупки авиабилета на выбранный маршрут, и сам этот сценарий, собственно, и будет формой представления пользовательских требований.
Мы можем описать требования в виде набора user stories, например, для
Каждая user story — это такой единичный кусок, unit при разработке требований, обладающий своими собственными характеристиками, и разработанный по определённому методу.
Это всё примеры пользовательских требований. Их может быть ещё больше, как я говорил, но этих достаточно, я думаю, для понимания.
Атрибуты качества. Более детально мы атрибуты качества рассмотрим ещё сегодня на этом вебинаре.
Что за этим стоит? Свойство продукта, выраженное через описание характеристик, важных для пользователей или разработчиков. Тоже несколько суконное определение.
Есть понятие качества программного обеспечения или качества программного продукта. Для него есть стандарты, там есть своя теория, есть методы определения качества, его оценки, обеспечения качества. И за этим стоит множество разных точек зрения на то, как должен работать программный продукт.
Мы сегодня эти точки зрения рассмотрим на этом вебинаре, а пока три примера, которые разные точки зрения представляют.
Я снова делаю оговорку: то, что здесь написано, это не сами атрибуты качества, а то, как могут выглядеть требования, которые эти атрибуты качества представляют по отношению к создаваемому продукту.
Например, время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надёжность». Производительность — это время загрузки страницы, а надёжность — это какую нагрузку должен держать сайт.
База данных сайта должна устанавливаться на сервера mysql или MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Это, опять же, конкретное представление требования, которое отражает такой атрибут качества как «переносимость». Мы можем наш разработанный сайт устанавливать в разном окружении, и при этом должны быть реализованы эти требования, чтобы мы могли использовать разные системы баз данных.
Сайт должен быть адаптирован для мобильных устройств. Это может вам показаться спорным, но это требования тоже отражают атрибут качества. Удобство использования тоже является атрибутом качества. Сейчас он больше известен под словом «юзабилити», которое в стандарте последнем так и переведено: «удобство использования».
Эти три примера, конечно, совсем не отражают всё многообразие атрибутов качества, но мы на это многообразие сегодня ещё посмотрим. Пока для нас важно только, что стоит за этим за этим видом требований.
Я должен сказать, что книга Вигерса уже выдержала три издания, и он в каждом издании эту картинку немножко меняет. Он перемещает отдельные виды требований между разными уровнями, он иногда меняет зависимости между ними. Это нормально, и это отражает тот факт, что в
Следующий вид требований — это ограничения. Условия, которые модифицируют требование или набор требований, сужая выбор возможных решений. Обычно это внешние по отношению к системе условия или принятые ранее решения.
Мы лучше всего знаем, наверное, ограничения технические, которые часто отражаются в ТЗ, исходя из имеющихся возможностей заказчика или разработчика.
Например: сервер приложений сайта должен разрабатываться на языке Java. Почему? А потому что, например, у заказчика есть множество специалистов, которые могут эту джаву сопровождать, и все другие его сервера приложений тоже работают в этом окружении.
Или похожий пример: сайт должен устанавливаться на определенную версию операционной системы.
Это самые простые виды ограничений, бывают и более сложные. Это ограничения, которые мы должны учитывать ещё до начала разработки системы, и они сужают область возможных решений в процессе её разработки.
Внешние интерфейсы. Описание интерфейса между системой и пользователем, другой системой или оборудованием.
Этот вид требований становится все более актуальным в эпоху интернета, потому что сейчас
Ну например, что это может быть.
API социальной сети для репоста публикаций сайтов. Если вы хотите реализовать и сайт, и страничку вашей компании в Фейсбуке, но не хотите вручную переносить туда все новости, то вам нужно будет разработать специальное приложение, которое будет это делать за вас автоматически. Это, собственно, и есть пример внешнего интерфейса.
Спецификации взаимодействия с платежным агрегатором для оплаты на сайте — тоже распространённый внешний интерфейс. Если вы принимаете оплату в любом
Ещё пример: протокол взаимодействия с сервером транспортной компании для резервирования и оплаты билетов. Уже приведенный пример для авиакомпаний: единая точка для возможности сравнить и купить билеты разных авиакомпаний. Для такого сервиса очень важными тоже являются внешние интерфейсы взаимодействия с разными внешними сервисами резервирования и оплаты билетов.
Системные требования — это самый запутанный вид требований у Вигерса. Он,
В оригинале это требования к продукту, содержащему несколько подсистем. То есть это некоторые требования, которые описывают то, как эти подсистемы должны между собой взаимодействовать.
Я знаю, что во многих компаниях термин «системные требования» используется для всего третьего уровня требований. Практически все знают, что такое бизнес-требования, что такое пользовательские требования тоже все прекрасно понимают. А вот на этом (третьем) уровне я предлагаю использовать термин «требования к реализации», Вигерс предлагает использовать термин «функциональные требования», но я знаю несколько компаний, где для обозначения этого всего использовуют термин «системные требования».
Но, тем не менее, если мы придерживаемся терминологии Вигерса, то можно привести такие примеры системных требований, то есть именно требований к системе, состоящей из нескольких подсистем.
Доступ к операциям со счётом (речь идет об
Функциональные требования. Я говорил, что мне не нравится называть так целый уровень требований именно потому, что в этом случае он перемешивается вот с этим видом требований, и получается некоторая путаница.
На самом деле, в это яйцо на картинке Вигерса включается всё, что не попало в остальные виды требований. Это описание требований к системе в разнообразных форматах, которые, собственно, описывают, как она должна функционировать.
Если прочитать определение Вигерса, это «описание функциональности, которая должна быть реализована в разрабатываемой системе, чтобы пользователь мог выполнить свои задачи в рамках
Давайте пока просто на примеры посмотрим. Но эти примеры, наверное, не отражают и на пять процентов (а может быть, и на один процент) всё разнообразие методов представления этих требований, потому что они очень сильно зависят от разрабатываемой системы.
Например, на сайте должен быть реализован поиск статей по ключевым словам и по проставляемым тегам. Это дает нам требования к поиску или, собственно, к функции «поиск» — что должно быть реализовано на сайте.
Ещё пример: операции оплаты со счёта должны быть доступны только с использованием двухфакторной авторизации. Тоже функциональное требование, которая ограничивает нас в реализации разных видов операций работы со счётом в
Может быть, это не самые лучшие примеры. Я честно признаюсь, что я очень долго думал над этим слайдом, но у меня просто мысль растекается, потому что, как я уже говорил, большинство требований, которые не укладываются в другие виды требований, можно назвать функциональными. Как правило, технические задания или спецификации требований состоят из множества предложений, каждое из которых можно отнести к функциональным требованиям.
Давайте мы на этом закончим обзор видов требований. Это такой очень верхнеуровневый обзор, который даёт только, собственно, определения. Так, чтобы в рамках курса, когда мы будем говорить о
Предыдущий урок: Уровни требований к программному продукту
Следующий урок: Функциональная и нефункциональная стороны программного продукта
Автор статьи

Григорий Печёнкин
Курсы Вебурситета
Практический анализ ПО с моделированием на UML От 27 000 руб. | |
Введение в профессию аналитика (демо) Бесплатно | |
Введение в профессию аналитика 2 900 руб. | |
Вебинары Сообщества Аналитиков Бесплатно | |
SQL для непрограммистов (СЕРТИФИКАТ) 999 руб. | |
![]() | SQL для непрограммистов Бесплатно |