WEBURSITET.RU

Онлайн-курсы профессиональной разработки ПО

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

12.02.2018 18:30

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

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

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

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

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

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

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

То есть вот эти три уровня которые предлагает Леффингуэл:

1. уровень потребностей,

2. уровень функций и

3. уровень программных требований.

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

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

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

Бизнес-требования в общем-то соответствуют уровню потребностей, который описан у Леффингуэлла.

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

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

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

Если очень приближённо говорить, очень примитивно, то работа бизнес-аналитика лежит преимущественно между первым и вторым уровнем, а работа системного аналитика больше приближена к работе между вторым и третьим уровнем.

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

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

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

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

Требования пользовательского уровня — кто и как взаимодействует с продуктом.

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

Для первого уровня есть свои методы разработки требований, их можно обобщённо назвать разработкой Концепции (разработка бизнес-требований).

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

Не менее известный сейчас и распространенный метод описания требований с помощью User Stories (пользовательских историй) тоже, на самом деле, был разработан для описания требований в первую очередь пользовательского уровня. Хотя в Agile их, конечно, масштабировали сейчас на все уровни.

Ещё есть метод персонажей, может быть, не так хорошо известный аналитикам. Но в последней версии BABOK (Business Analysis Body of Knowledge, есть такой свод знаний по бизнес-анализу) этот метод уже упоминается как метод, которым аналитикам тоже нужно владеть. Мы о нём немного поговорим в курсе.

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

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

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

Партнёры и друзья



Автор статьи


Григорий Печёнкин


Продолжая использовать этот сайт, вы даете согласие на обработку файлов cookie, пользовательских данных (включая сведения о местоположении, тип и версия ОС, тип и версия браузера, тип устройства и разрешение его экрана, источник откуда пришел на сайт пользователь, с какого сайта или по какой рекламе, язык ОС и Браузера, какие страницы открывает и на какие кнопки нажимает пользователь, IP-адрес). Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте сайт. Вы можете узнать, как используются эти данные, ознакомившись с Политикой конфиденциальности.
Ясно, больше не показывать это сообщение