ЭЭЭЭЭЭЭЭЭЭЭЭЭЭЭЭ, народ, ну как же так ...

Фича в понимании Vision - это требование, что нам нужно на верхнем уровне (группа ф-ти, кот нужна и без нее никак), и не важно есть оно уже в продукте или нет.
Фича продукта - это то, чем облает продукт (группа ф-ти, кот уже есть и чем этот продукт лучше конкурентов)

Фича продукта - это то, чем облает продукт (группа ф-ти, кот уже есть и чем этот продукт лучше конкурентов)

...или чем ДОЛЖЕН обладать продукт.
Не забывайте, что мы говорим о требованиях, а не поставке готового продукта на рынок и его рекламе
Тот факт, что фича после реализации попадает в описание продукта на коробке, это следствие того, что кто-то на начальном этапе ее придумал и далее реализовал

...т. е по мере реализации продукта "фичи" из концепции системы, которые не являются определяющими для конкуренции, перестают существовать? ))

А наш технический писатель в пользовательской документации трактует термин feature как "возможность" или "особенность" в зависимости от контекста.

Не ребята, поскольку термин feature пришел к нам из-за бугра, то в этом проблема. Но за бугром-то наверняка под этим термином понимается что-то определенное.

Мне импонирует определение, которое дает Виталий: фича - то, что уже есть. И переход ясен - требование (что должна делать система), фича - реализация (что уже есть). Причем в описании предложения вся разница в слове ДОЛЖНО.

Может на этом и остановиться

Я бы не стал заостряться на слове должна. Если в Системе уже реализована какая-то функциональность, разве это не означает, что Система должна эту функциональность выполнять.

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

Леффингуэлл (стр.46-47 в русскоязычном издании) говорит, что:

Функция (feature) - это предосталяемое системой обслуживание для удовлетворения одной или нескольких потребностей заинтересованных лиц

Так для справки...
В UML "feature" означает "составляющая". Например, атрибут - то фича класса.

В переводе SWEBOK, по KA Software Requirements на стр. 6 приведено пояснения что есть фича, и ее "дуализм".

В переводе SWEBOK, по KA Software Requirements на стр. 6 приведено пояснения что есть фича, и ее "дуализм".

На самом деле никакого прояснения понятия feature в SWEBOK нет. То же самое "словоблудие". Похоже действительно, имеет смысл просто не обращать на это внимание..

Мне импонирует определение, которое дает Виталий: фича - то, что уже есть. И переход ясен - требование (что должна делать система), фича - реализация (что уже есть). Причем в описании предложения вся разница в слове ДОЛЖНО.

Для заказной разработки на таком подходе можно и остановиться При моделировании пишем требования, а потом, когда публикуем статью об успешно выполненном проекте на сайте компании выписываем списочком важные фичи.
А вот для продуктовой разработки фича может содержать слово ДОЛЖНО. Например, есть отдел, который анализирует рынок, отклики покупателей, тенденции развития отрасли и выдает постановку задачи типа "Чтобы быть конкурентно-способными нам надо выпустить продукт, на коробке которого мы сможем написать: /список фич/". И с этого начинается проработка конкретных требований и прочего.

На самом деле никакого прояснения понятия feature в SWEBOK нет. То же самое "словоблудие". Похоже действительно, имеет смысл просто не обращать на это внимание..

а вот с этого момента поподробнее ... Эд. Там все "русским по белому" написано.
Фича инвариантна по отношению к тому, создали вы продукт или только его замыслили ... Фича - это некое важное, например, с потребительской точки зрения свойство системы. Фича, это то, за что цениться эта система ее потребителями, или что побуждает использовать продукт. Фичи могут иметь АБСОЛЮТНО РАЗНЫЙ УРОВЕНЬ, если говорить в терминах Вигерса. Это может быть и "Возможность получить отчет по <чему-то, чего раньше не было и это ценно для заказчика>" и может быть НЕФУНКЦИОНАЛЬНОЕ ТРЕБОВАНИЕ - типа "получение отчета на 1M записей за 2 сек." - т.к. ВАЖНО получить отчет очень быстро, т.е. фичи могут быть вполне "ортогональны" пользовательским и иным требованиям. Но, при условии хорошей проработки требований, каждая из фича будет связана с набором бизнес/пользовательских/функциональных или нефункциональных требований. Т.о. фичи являются отдельным артефактом, который важен как при продуктовой разработке (набор требований должен гарантировать, что фича будет реализована в системе разработчиками), так и при заказной разработке (фичи - то что в системе особенно ценно для заказчика и опять-таки, они должны быть отражены в тербованиях). Отсюда и дуализм их природы ....  Другой вопрос - с какой степенью детализации должны быть проработаны фичи.

А вот для продуктовой разработки фича может содержать слово ДОЛЖНО. Например, есть отдел, который анализирует рынок, отклики покупателей, тенденции развития отрасли и выдает постановку задачи типа "Чтобы быть конкурентно-способными нам надо выпустить продукт, на коробке которого мы сможем написать: /список фич/". И с этого начинается проработка конкретных требований и прочего.

Мне кажется, это просто сформулированная мысль с использованием слова коробка. Так, наверное, маркетологам легче мыслить.
Может быть вы хотели сказать, что все выше перечисленные отделы формулируют список фич (исследуют, узнают, придумывают, оформляют коробку...), а до Вас доносят в виде формулировки "Должно быть на коробке...", Что нужно интерпретировать как "Продукт должен обладать следующими возможностями..."

А по сути без разницы, заказная разработка или коробочный продукт на рынок. Сначала требования, потом поставка.
В первом случае список фич пишут на сайте, как Вы сказали, а во втором - на коробке. Это лишь способ оформления информации о продукте (системе)

...фичи являются отдельным артефактом...

Юрий, в чем принципиальное отличие фичи от требования?

Юрий, в чем принципиальное отличие фичи от требования?

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

Т.е. требование - пользователь должен иметь возможность оправить письмо разными способами. Фича - конкретный способ отправки реализованный в НАШЕЙ системе и выгодно отличающие ее от других систем например...

Фича, это то, за что цениться эта система ее потребителями

Это добрые фичи. А есть еще злые фичи, те самые, которые "Это не баг, это фича"
С учетом этой языковой традиции русскоязычных разработчиков, фича в русском языке - это скорее артефакт программы, а не требование. То есть это не совсем то, что feature. ИМХО.

Юрий, в чем принципиальное отличие фичи от требования?

В позиционировании, назначении и способе представления.