Коллеги, друзья.

При формулировке и анализе требований в литературе часто приводят пирамиду: потребности (need) - возможности (feature) - требования (system requirement). Потребностям часто предшествуют интересы (concern) и проблемы (problem).

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

Очевидно, что в последнем случае можно потребовать формулы <система должна>.

Для случая потребностей, вероятно, можно начинать фразы с "желательно, нужно, хотелось бы"

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

Наверное есть и более приемлемые критерии и способы формулировок и различий?

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

Заинтересованные лица <имеют> потребности, которые <реализуются> через возможности, которые <детализируются, специфицируются> через системные требования ... ?

Эдуард, приветствую!

Для случая потребностей, вероятно, можно начинать фразы с "желательно, нужно, хотелось бы"

Потребности заинтересованных лиц я формулирую примерно так: "[Заинтересованному лицу 1] нужно...". А далее описание полезного бизнес-результата, который поможет решить проблему из Problem statement или воспользоваться бизнес-возможностью.
А слова "желательно, хотелось бы" лучше не использовать, потому что приоритет может меняться. Лучше использовать приоритеты типа MoSCoW.

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

Я бы сказал что возможность это не высокоуровневое требование, а удобный для обсуждения и планирования способ группировки системных требований. Их часто пишут на коробках ПО в виде списка возможностей. Также они перечисляются в списках "улучшений" в Release notes. К примеру для EA: http://www.sparxsystems.com/products/ea/history.html

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

Я понимаю так:
Проект существует ради решения БИЗНЕС-ПРОБЛЕМ(Ы) или для того чтобы воспользоваться БИЗНЕС-ВОЗМОЖНОСТЬЮ(ЯМИ). Заинтересованные лица как часть бизнес-системы участвуют в решении БИЗНЕС-ПРОБЛЕМ и использовании БИЗНЕС-ВОЗМОЖНОСТЕЙ (не фичи). Решение БИЗНЕС-ПРОБЛЕМ и использование БИЗНЕС-ВОЗМОЖНОСТЕЙ невозможно без удовлетворения возникающих ПОТРЕБНОСТЕЙ заинтересованных лиц. ВОЗМОЖНОСТИ (фичи) удовлетворяют ПОТРЕБНОСТИ заинтересованных лиц и специфицируются системными требованиями.

Сергей, спасибо за ответ и интерес к теме.

Можно тогда дать определения бизнес-проблемы и бизнес-возможности? И нарисовать вашу модель трассировки?

Если вы работаете по такой технологии

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

Для случая потребностей, вероятно, можно начинать фразы с "желательно, нужно, хотелось бы"

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

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

"Фичи" это не требования. Это именно "возможности" (т.е. прямо противоположный посыл). То, чем система (продукт) может привлечь потенциального потребителя. Согласен с Сергем Евтуховичем. Примеры формулирования фич можно смотреть на "коробках". Причем не обязательно ПО. Хоть лампочки: "На 80% экономичнее лампы накаливания!", "Дает теплый, мягкий свет", "Срок гарантии - 15 лет" и т.п.

Сергей, спасибо за ответ и интерес к теме.

Можно тогда дать определения бизнес-проблемы и бизнес-возможности? И нарисовать вашу модель трассировки?

Я думаю что будет лучше привести шаблоны для формулировки:
Бизнес-проблема может быть сформулирована примерно как Problem statement из RUP:

• Проблема [описание проблемы]
• оказывает влияние на [заинтересованные лица, на которых влияет проблема и её решение]
• результатом чего является [какое бизнес-воздействие оказывается проблемой]
• Проблема будет решена успешно, если [список ключевых измеряемых бизнес-преимуществ успешного решения]

Бизнес-возможность по аналогии примерно так:

• Банк имеет возможность [краткое описание возможности]
• для [целевой пользователь/клиент]
• ощущающего необходимость в   [краткая формулировка потребностей]
• В результате, [какие бизнес-цели могут быть достигнуты если удастся воспользоваться предоставляемой возможностью]

Диаграмма будет позже.

Сергей, Леонид, спасибо.

Возможно вы и правы, считая возможности нетребованиями, но однако у Битнера и Спенсера в книге Use case modeling читаем:
"Возможность (Feature) – это высокоуровневая способность (услуги или качества) системы, необходимая для обеспечения нужного эффекта и помощи в реализации потребности заинтересованного лица и/или пользователя. Набор возможностей обеспечивает суммарное представление об объявленных свойствах продукта, который будет создан.

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

Впрочем мне скорее важно донести разницу до студентов, что бывает сложно. Ибо:

Директор (заинтересованное лицо) имеет потребность в своевременном получении значений финансовых показателей деятельности компании. - Это потребность, правильно? В ней мы пытаемся сформулировать бизнессмысл ну или некий первосмысл этой самой потребности. Верно.
Возможность может быть сформулирована как: Система должна предоставлять возможность пользователю (директору) получать значения финансовых показателей деятельности компании на указанную дату? Так?

Возможно вы и правы, считая возможности нетребованиями, но однако у Битнера и Спенсера в книге Use case modeling читаем:
"Возможность (Feature) – это высокоуровневая способность (услуги или качества) системы, необходимая для обеспечения нужного эффекта и помощи в реализации потребности заинтересованного лица и/или пользователя. Набор возможностей обеспечивает суммарное представление об объявленных свойствах продукта, который будет создан.

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

Предлагаю свериться с первоисточником. В определении терминологии:

"Types of Requirements

Needs. Things that the stakeholders believe that the system needs to do; problems that they need to have solved. Needs, while important to understand, are so informal that we need other ways to express the requirements of the system."

Вот те раз. По мне, между "Things that the stakeholders believe that the system needs to do" и "problems that they need to have solved" пропасть размером в их Гранд-каньон. И вообще, что с этими потребностями церемониться? "Хоть потребности и важно понимать, но они настолько неформальны, что выражать требования к системе понадобиться как-то иначе". То есть это такой вид требований, который в требованиях к системе лучше не применять. Причем "лучше" не в смысле "рекомендуется" а в смысле "требуется".

Продолжим (чуть дальше по тексту):

"We’ll define a stakeholder need as a reflection of the business, personal or operational problem (or opportunity) that must be addressed to justify consideration, purchase, or use of a new system."

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


Назад в определения.

"Types of Requirements
...
Features. Informal statements of capabilities of the system used often for marketing and product-positioning purposes, as shorthand for a set of behaviors of the system."

Нет, у меня все-таки от заявления в духе "возможности системы - это такие требования" в организме происходит когнитивный диссонанс. Ну, примерно как от выражения "права - это такие обязанности". А у авторов не происходит. Видимо, в силу другого устройства мировосприятия.

Подробнее (дальше по тексту) тот самый кусок, который Вы процитировали:

Features are the high-level capabilities (services or qualities) of the system that are necessary to deliver benefits to the users and that help to fulfill the stakeholder and user needs. The feature set provides a summary of the advertised benefits of the product to be built. They can functional and nonfunctional. The level of detail must be general enough for everyone to understand.

"Возможность (Feature) – это высокоуровневая способность (услуги или качества) системы, необходимая для обеспечения нужного эффекта и помощи в реализации потребности заинтересованного лица и/или пользователя. Набор возможностей обеспечивает суммарное представление об объявленных свойствах продукта, который будет создан.

Предлагаю такой перевод:

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

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

Впрочем мне скорее важно донести разницу до студентов, что бывает сложно. Ибо:

Директор (заинтересованное лицо) имеет потребность в своевременном получении значений финансовых показателей деятельности компании. - Это потребность, правильно? В ней мы пытаемся сформулировать бизнессмысл ну или некий первосмысл этой самой потребности. Верно.
Возможность может быть сформулирована как: Система должна предоставлять возможность пользователю (директору) получать значения финансовых показателей деятельности компании на указанную дату? Так?

Примерно. Но лучше сформулировать фичу как "Система держит Вас в курсе финансового состояния". Или ".. позволит иметь показатели под рукой в любой момент". Маркетологи придумают и получше.

Можно попробовать объяснить так: "Потребности - то, что желает потребитель. Фичи - то, что может система. Так выпьем же за то..."

И нарисовать вашу модель трассировки?

Как то так. Эдуард, Леонид, прошу высказать Ваше мнение.

Примерно. Но лучше сформулировать фичу как "Система держит Вас в курсе финансового состояния". Или ".. позволит иметь показатели под рукой в любой момент". Маркетологи придумают и получше.

Можно попробовать объяснить так: "Потребности - то, что желает потребитель. Фичи - то, что может система. Так выпьем же за то..."

Есть ещё такой пример:
http://www.samsung.com/ru/consumer/mobile-devices/smart-phones/samsung-galaxy/SM-G900FZKASER-features
Закладка с говорящим названием "Возможности". У потребителя есть потребность использовать смартфон в сырую погоду, а также в пыльных местах, и не бояться поломки. В этом ему поможет фича "защита от пыли и влаги".

Спасибо, интересное и похожее прочтение. Правда, что такое Opportunity

Моя (черновая диаграмма) во вложении (:

Спасибо, интересное и похожее прочтение. Правда, что такое Opportunity

Opportunity - возможность, предоставляемая бизнесу рынком, новыми технологиями, законодательством и т.п. К примеру технологии бесконтактных банковских карт типа PayPass позволяют организациям повысить скорость оплаты товаров и услуг, снизив издержки. Также, к примеру, общественный транспорт может отказаться от биллинга собственных транспортных карт и соответствующей инфраструктуры, потому что стоимость проезда будет списываться напрямую с банковских карт. Это возможность, предоставляемая новыми технологиями. Она по аналогии с problem statement должна быть описана в коцепции/Vision.

Моя (черновая диаграмма) во вложении (:

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

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

На самом деле это модель, выведенная из консультаций с Борисом Леонидовичем Новиковым - экспертом и, возможно, евангелистом RUP.
Заинтересованное лицо - лицо, имеющее определенный интерес в существовании системы.
Интерес - хотя и есть в модели, реально мною не используется. Concern - многозначное понятие. Чем оно отличается от проблемы, мне сказать, честно сложно.
Проблема - совпадает с Вашим пониманием.
Потребность (need) - высказанное или невысказанное пожелание то, что решает (по мнению ЗЛ) его проблемы.
Требование возможности (feature) - хотя Леонида передергивает, но RUP почему-то считает это требованиями. В практике RUP, в частности в ReqPro есть такой тип требования.
Требование прецедента - это не сам прецедент, но функциональное требование. Требование  - это условие, а прецедент - это договоренность об взаимодействии
Дополнительные требования - все что FURPS+
Функциональная область - уже часть решения - часть логической структуры или архитектуры

У меня какое-то душераздирающее дежавю - неужели за последние 5 лет тема ни разу не поднималась?...

Для случая потребностей, вероятно, можно начинать фразы с "желательно, нужно, хотелось бы"

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

Наверное есть и более приемлемые критерии и способы формулировок и различий?

Покопалась в своих ТЗ. "Необходимо" и "должен" хватает на все случаи жизни ))

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

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

Формулировки потребностей и возможностей (need и feature) довольно близки. При изучении этой темы (на практике), часто возникают разногласия . Хотя и поясняется, что потребность - это пожелание, которое может остаться мечтанием или превратится в требование, фича - уже требование, то чему должна соответствовать система (иметь свойства). Возможно я дую на воду, но предполагал, что есть какие-то маркеры позволяющие
а/ различать потребности и фичи
б/ корректно их формулировать чтобы не путать в последствие, ну хотя бы в рамках одной группы

Формулировки потребностей и возможностей (need и feature) довольно близки. При изучении этой темы (на практике), часто возникают разногласия .

Эдуард, а можно пример-другой из числа частых разногласий?