Сегодня возникла дискуссия по поводу того, что означает понятие feature.

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

Мой оппонент понимает или хочет понимать под этим некий элемент реализации. Т.е. у него взгляд, что Feature реализует некоторое требование. Хотя явно имеет место обратная зависимость. Ну, например, в примерах RequsitePro - там Use cases реализуют Features.

Итак вопрос, что есть feature, каково его место в проекте? Как можно назвать спроектированные элементы, реализующие некие требования.

Например, требуется реализовать отчет 3НК по профессорско-преподавательскому составу по заданным разрезам группировки. Это требование заказчика.

Что может быть feature в этом случае? Некоторые артефакты проекта позволяющие это сделать? Или это системные требования? Или реализованные свойства системы? Просто функция системы?

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

• FEAT.189 Поддержка обратной связи от пользователей
  Пользователю должна быть предоставлена возможность доведения до производителя личного мнения о продукте (жалобы, предложения, отзывы и т.п)
  Фаза: 1.0  Приоритет:Medium  Статус: Proposed
  
• FEAT.15 Поддержка портретной и альбомной ориентации экрана
  В системе должна быть предусмотрена поддержка портретной и альбомной ориентации экрана, а также автоматический поворот в соответствии с положением G-сенсора
  Фаза: 1.0  Приоритет:Medium  Статус: Approved
  

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

Виталий, правильно ли считать Feature требованием? Чем конкретно тогда это требования отличается от других требований?

Я придерживаюсь определения Лиффингуэла:

Feature
a service provided by the system that fulfills one or more stakeholder needs.

Software Requirements
Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised. In turn, since the features address one or more stakeholder needs, we will have addressed those needs directly in the solution.

В Sparx EA, как мне показалось, определение фичи другое

A Feature is a small, granular function or characteristic expressed in client-valued terms as a satisfaction of a requirement; for example: 'context-sensitive Help', or 'ability to reverse-engineer VB.Net'.

Features are the primary requirements-gathering artifact of the Feature-Driven Design (FDD) methodology. They define the product feature that satisfies what a Requirement element has formalized as a contractual, testable, expected deliverable (for example: requirement - 'every element must provide context-sensitive Help'; feature - 'every element provides context-sensitive Help'). One Feature might realize one or more Requirements, and one Requirement might be realized by more than one Feature.

Features also have relationships with Use Cases. A Use Case defines the interaction a user has with the system in order to satisfy one or more Requirements. The Feature identifies the facility that provides the means for that interaction.

Feature elements are non-UML and are not related to UML-defined features, which are either BehavioralFeatures (operations, or methods) or StructuralFeatures (Ports, Parts and attributes).

Виталий, правильно ли считать Feature требованием?

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

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

Что значит, что понимается под термином "требование". Требование это и есть требование. Уровень требования определяет лишь уровень детализации на мой взгляд.


Требование: Система должна обеспечить увеличение прибыли не менее, чем на 5 % через полгода ввода ее в эксплуатацию. Нормальное требования бизнеса.

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

Возьму на себя смелость перевода

Feature  a service provided by the system that fulfills one or more stakeholder needs.

Feature - сервис, который предлагается системой, для удовлетворения (выполнения) одной или нескольких потребностей заинтересованных лиц

Software Requirements
Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised. In turn, since the features address one or more stakeholder needs, we will have addressed those needs directly in the solution.

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

В Sparx EA, как мне показалось, определение фичи другое
Цитировать
A Feature is a small, granular function or characteristic expressed in client-valued terms as a satisfaction of a requirement; for example: 'context-sensitive Help', or 'ability to reverse-engineer VB.Net'.

Feature - небольшая (гранулированная) функция или характеристика, выражаемая в терминах значимости для клиента как удовлетворение требования. Например: контестно-зависимая справка или способность реинжиниринга VB.Net

Features are the primary requirements-gathering artifact of the Feature-Driven Design (FDD) methodology. They define the product feature that satisfies what a Requirement element has formalized as a contractual, testable, expected deliverable (for example: requirement - 'every element must provide context-sensitive Help'; feature - 'every element provides context-sensitive Help'). One Feature might realize one or more Requirements, and one Requirement might be realized by more than one Feature.

Features первичный артефакт этапа сбора требований в FDD методологии. Они определяют свойства(функции, характеристики) продукта, которые удовлетворяют тому, что элемент требования формализован как договорной, тестируемый, ожидаемый, передаваемый (пример: требование - 'каждый элемент должен предоставлять контекстно-зависимую справку'; feature - 'каждый элемент обеспечивает контекстно-зависимую справку'. Одна feature может реализовать одно или несколько требований, а одно требование может быть реализовано более чем одной feature.

Features also have relationships with Use Cases. A Use Case defines the interaction a user has with the system in order to satisfy one or more Requirements. The Feature identifies the facility that provides the means for that interaction.

Feature также связана с вариантами использования. ВИ определяет взаимодействие пользователя с системой, удовлетворяющее одному или более требованиям. Feature определяет возможность, предоставить средство для такого взаимодействия

Что значит, что понимается под термином "требование".

Если под термином "требование" понимать:

FAQ - Что такое требования?
IEEE Standard Glossary of Software Engineering Terminology определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2

а под feature:

Feature  a service provided by the system that fulfills one or more stakeholder needs.

Feature - сервис, который предлагается системой, для удовлетворения (выполнения) одной или нескольких потребностей заинтересованных лиц

то таки да, на мой взгляд feature - это требование.

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

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

По-моему, сейчас, определение того что есть требование что есть фича - вопрос скорее религии, чем стандарта:)

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

По-моему, сейчас, определение того что есть требование что есть фича - вопрос скорее религии, чем стандарта:)

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

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

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

Т.е. требование - что нужно, а фича - что уже есть?

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

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

Т.е. требование - что нужно, а фича - что уже есть?

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

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

... один общепризнанный стандарт ...

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

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

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