Основные форматы представления требований

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

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

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

Я вам сначала покажу примеры концепций, а потом мы сформулируем выводы. Rational Unified Process, о котором я говорил, — это фактически большая база знаний о том, как создавать разные продукты. Мы ему должны быть благодарны, во-первых, за явное выделение роли аналитиков и их специализаций. Именно в RUP были детально впервые описаны разные роли аналитиков — в частности, бизнес-аналитика, системного аналитика и ещё некоторые дополнительные роли.

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

Здесь у меня два примера концепций.

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

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

Этот модуль называется «форматы представления требований». И применительно к бизнес-требованиям я хотел показать, что нет каких-то однозначных форм для их описания, но есть достаточно хорошо проработанное представление о том, что же является бизнес-требованиями, и что надо учесть, когда мы их разрабатываем.

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

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

На самом деле, разрабатывать требования в таком формате — это самоубийство.

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

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

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

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

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

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

Есть известная книга Алистера Коберна «Современные методы разработки функциональных требований к системам». Мы ещё будем в курсе на неё ссылаться. Это плохой и устаревший перевод названия книги «Writing Effective Use Cases», но он отражал именно тот факт, что на момент написания этой книги это был лучше всего проработанный и всеми признаваемый метод разработки требований к системам. Он описывает, как люди взаимодействуют с системой в виде пошаговых сценариев.

User Stories — это другой формат описания пользовательских требований, который мы тоже будем в этом курсе рассматривать. У него есть существенные отличия от вариантов использования. Это не такой глубокий формат. Если варианты использования предполагают, что сценарий прописывается детально до начала реализации, то User Story обозначает только цель пользователя и контекст, зачем это ему нужно. Этот формат предназначен, в первую очередь, для обсуждения внутри команды. У User Story есть начальный вариант, который предлагается для обсуждения, а в результате обсуждения к ней добавляются комментарии, атрибуты и определённые формы требований. Этот формат предназначен для того, чтобы быстро собирать требования, быстро их описывать, быстро обсуждать, анализировать, и тут же запускать в работу.

Есть ещё один метод, которого мы коснёмся в курсе. Это сценарии, основанные на персонажах. Метод разработан Аланом Купером. Он написал книгу «Об интерфейсе», где этот метод описан. Основная идея его состоит в том, что, когда вы разрабатываете продукт для массового пользователя, нельзя для разных классов пользователей использовать одни и те же сценарии работы с вашим продуктом. Он предлагает выделять для пользователей определённые классы, или сегменты пользователей, различающиеся своим поведением, своим опытом, отношением к продукту и целями. И для каждого из этих классов разрабатывать свой сценарий взаимодействия с вашим продуктом, а потом продукт делать так, чтобы он удовлетворил потребности всех этих пользователей. Почему я говорю вам об этом методе? Сейчас всё больше ожидается, что аналитики должны этим методом владеть. Хотя у него есть определённые ограничения, и не все могут его использовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующий урок: Критерии качества требований к программным продуктам