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

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

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

Давайте для начала разберёмся с делением требований по уровням.

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

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

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

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

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

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

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

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

1. Бизнес-требования

2. Пользовательские требования

3. Функциональные требования.

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

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

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

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

1. Требования бизнес-уровня.

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

3. Требования уровня реализации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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