Какие виды требований важнее остальных?

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

Так какие же требования важнее остальных?

Мы рассмотрели разные виды требований и рассмотрели разные виды качества.

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

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

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

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

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

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

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

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

Атрибуты качества (usability). Я уже говорил, что сейчас это очень важное конкурентное преимущество. Когда все сайты реализуют одни и те же функции, все похожи друг на друга, все интегрируются с одними и теми же сервисами и агрегаторами, то при таких равных условиях наиболее важным становится удобство использования. Уникальный интерфейс, дизайн, то есть то, что никак не завязано на функции сайта, а только на впечатление, который сайт производит. Поэтому тут и возникла отдельная индустрия анализа пользовательского взаимодействия (UX) и разработки пользовательских интерфейсов. И поэтому usability или удобство использования может быть тем самым золотым яйцом, которое станет основным источником функциональных требований.

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

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

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

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

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

Следующий урок: Виды программных и интернет-продуктов