Что такое требования к программному продукту

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

Прежде чем говорить о требованиях, нам нужно определиться, что мы под ними понимаем.

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

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

Первое, что приходит в голову, когда мы хотим найти определение чему-нибудь, — поискать в Википедии. Русскоязычная страница Википедии даёт нам такое определение:

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

Мне не нравится это определение тем, что оно ставит вопросов больше, чем даёт ответов.

Что значит «совокупность утверждений»? По каким критериям отбираются утверждения в эту совокупность? Она только одна, или их может быть много?

В какой форме существуют эти утверждения? Если у меня в голове есть какие-то утверждения относительно атрибутов системы, но я их нигде не документировал, то являются ли они требованиями?

Чем различаются атрибуты, свойства и качества?

Почему «системы, подлежащей реализации»? А если у нас уже есть реализованная система, и мы её дорабатываем?

В общем, вы уже поняли, почему это определение мне не нравится. Оно очень размыто и вряд ли пригодно для практического применения.

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

Есть такая книга: «Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению». Многие аналитики начинали изучение работы с требованиями именно по этой книге. В ней даются такие определения требования:

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

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

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

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

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

Давайте теперь заглянем в англоязычную Википедию, которая переадресует нас к определению требований из стандартного глоссария терминологии программной инженерии, разработанного ассоциацией IEEE. IEEE, Institute of Electrical and Electronics Engineers — это авторитетная международная организация, разработавшая множество стандартов, с некоторыми из которых мы ещё познакомимся в этой книге.

В глоссарии IEEE даётся такое определение требования:

1. Условие или возможность, необходимая пользователю для решения проблемы или достижения цели.
2. Условие, которое должна выполнять, или возможность, которой должна обладать система или компонент системы, чтобы соответствовать договору, стандарту, спецификации или другому официально установленному документу.
3. Документированное представление условия или возможности, представленной в пунктах 1 и 2.

Как видим, это несколько изменённое и дополненное определение, которое было приведено в книге Леффингуэла и Удрига. Но эти изменения и дополнения, к сожалению, не добавляют ясности.

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

Чаще всего мы будем ссылаться на следующую книгу: «Карл Вигерс. Разработка требований к программному обеспечению». (В третьем издании у Карла Вигерса появился соавтор: Джой Битти.) Эта книга, наверное, уже на протяжении многих лет является своего рода библией для аналитиков. Это универсальный учебник по работе с требованиями, и многие концепции, описанные в этой книге, являются общепринятыми в индустрии разработки программ.

Вигерс в своей книге вообще отказывается давать однозначное определение требованиям. Вместо этого он пишет так:

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

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

Я предлагаю применить ещё такой взгляд на требования. Требования, как совокупность утверждений о создаваемом продукте, — это некоторая описательная модель этого продукта.

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

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

Что нам даёт такой взгляд?

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

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

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

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

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

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

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

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

Это, на самом деле, в нынешней ситуации не так страшно, как может показаться. При создании интернет-продуктов мы обычно используем уже существующие компоненты. Например, мы можем взять готовую CMS (Content Management System), чтобы воспользоваться уже реализованными в ней функциями администрирования сайта, и предполагая при этом, что она достаточно отлажена, чтобы обеспечить нужные нам надёжность и производительность. Поэтому нам, может быть, не нужно задумываться об описании некоторых видов требований, особенно на первых стадиях запуска продукта. Но при развитии продукта это часто приводит к проблемам.

Что ещё даёт нам взгляд на требования как на описательную модель создаваемого продукта? Он предполагает, что требования могут меняться со временем.

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

Потом, в следующей версии требований, мы добавляем ещё что-то к этому описанию, прорабатывая какие-то требования более глубоко. Например, учитывая потребности и точки зрения людей, которые будут использовать продукт в своей работе.

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

Подытожим всё сказанное в этой главе.

Что же такое требования? Это некоторая описательная модель программного продукта, которая:

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

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

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