WEBURSITET.RU

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

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

09.02.2018 19:47

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

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

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

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

Мне не нравится это определение тем, что оно требует ответов на многие вопросы.

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

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

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

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

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

Но какие ещё есть варианты? Есть такая книга: «Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению». Очень хорошая книжка, но к сожалению я не нашел её нигде в электронном виде, в том числе на Амазоне, а хотелось бы почитать в оригинале. Есть только какое-то достаточно старое бумажное издание. Многие аналитики из тех, кого я знаю, начинали изучение работы с требованиями именно по этой книге.

Там даются такие определения требования:

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

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

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

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

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

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

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

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

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

Что нам даёт такой взгляд? На картинке я постралася изобразить, что продукт — это что-то такое строго определенное, а требование — это что-то в виде облаков, какой-то набор утверждений.

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

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

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

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

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

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

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

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

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

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

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

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



Автор статьи


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


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