Задачи и решения при формулировке требований

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

Должны ли высказывания заинтересованных сторон использоваться напрямую или они должны быть выделены отдельно и затем соединены с элементами, которые описывают пользовательские истории или требования?

Задачи и решения

Удовлетворить потребность – задача. Как этого добиться технически – решение. Есть один важный момент – не путать задачу и решение, то есть при формулировке требований можно настолько сильно все детализировать, что внезапно окажется, что описано техническое решение. Получается, что нам фактически не ставят задачу “Что нужно сделать”, а уже приписывают какое-то техническое решение иногда не нужное и преждевременное.

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

На рисунке приведен пример, хоть он не из IT области, но видно, что это концепция представления системы в виде “гамбургера”. Здесь одна и та же система рассматривается и как функция – то что она должна делать, и как конструкция – как она должна быть устроена.

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

Поэтому при ограничении системы, в том числе информационном, требованиями, необходимо понять на каком уровне детализации это делать. Более того это иногда зависит от квалификации исполнителя. Представьте, родители маленькому ребенку дают указание: “Сходи в магазин, купи хлеб”. Если ребенок маленький, родители ему все подробно объяснят: куда идти, как оплатить и т.д. А если ребенок повзрослее ему говорят: “Купи хлеб”. Если ребенок еще более взрослый ему можно просто сказать: “Купи какой-нибудь хлеб где-нибудь”, исполнитель сам поймет. Так и тут: очень часто непонятно, какая формулировка ставит задачу, а какая является техническим решением.

В том числе наша задача следить и за этим, потому что с одной стороны у нас максимально расплывчатые потребности: “Система должна быть быстрой, система должна быть надежной, интерфейс пользователя должен быть удобным”. Но это все мутно и не конкретно. Это должно быть облечено в проверяемое, понятное требование, но с другой стороны крайность впасть в желание описывать еще и то, как это должно быть реализовано. То есть иногда технические решения они разумные, иногда они бывают слишком преждевременные и не нужные. У нас получается: чем более мутно и расплывчато описана задача, тем больше пространства выбора решений для разработчиков, но понятно и проверяемость меньше.

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

Пример не из области IT

Рассмотрим для начала пример не из области IT (пример взят из статьи Г. Савельева) 

Формулировки потребностей как таковых звучат обычно очень тривиально. При виде формулировки потребности возникает вопрос: «Ну и что? Да, это так, это очевидно, но что с этим делать?»

Вот пример формулировки потребности: «Люди испытывают ежедневную потребность в пище»

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

Можно поразмышлять для тренировки над тем, в какие требования могла бы преобразоваться потребность в пище, если бы мы поместили её в другие контексты: школьного питания; работы на заводе или в офисе; постовой службы; пограничной службы; космических полетов. Очевидно, что требования будут совершенно разные, хотя потребность – одна и та же. Различие только в контексте.

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

Выполнить это требование можно разными способами. Можно, например:

• выбирать такие продукты, которые не портятся длительное время сами по себе (скажем, кокосы);
  
• можно применять разные формы консервации (в то время у мореплавателей пользовались большим спросом вяленые мясо и рыба);
  
• можно создавать специальную среду хранения, например, погружать продукты в вино или масло.

Способы выполнения требований называются решениями.

Пример из области IT

Теперь посмотрим пример из области IT

Потребность: Пользовательский интерфейс должен обеспечивать обратную связь.

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

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

Аспекты системы

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

Отправная точка проекта

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

Существует целый ряд таких комплексов потребностей:

• сформированные внутри бизнеса;
  
• сформированные из каждого запроса каждого клиента.
  

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

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

Примеры внутренних потребностей:

• Сократить количество видов покупных компонентов, чтобы увеличить объемы заказов и скидки на покупку.
• Сократить затраты на сопровождение программного обеспечения, стандартизировав драйверы на все продукты и отключив опции по необходимости.
• Обеспечить соответствие стандарту МЭК 12345. 

Потребности будут создаваться на основе:

• документов или электронных таблиц;
• структурированных интервью, как правило, только для уточнения.

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

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

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

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

Структура потребностей

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

Если в проект включаются потребности от нескольких групп, как, например, в Проект P12 , то у такого проекта будет несколько иерархий потребностей.

Как организовывать потребности внутри иерархии – полностью зависит от вас. Так, например, потребности можно организовать по типам:

или же по инженерным дисциплинам:

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