WEBURSITET.RU

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

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

09.02.2018 19:47

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


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

 

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



Автор статьи


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


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