Форум Сообщества Аналитиков
Дисциплины => Обучение => Термины и Определения => Тема начата: Galogen от 26 Ноября 2009, 22:59:28
-
Сегодня возникла дискуссия по поводу того, что означает понятие 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 - Что такое требования? (http://www.uml2.ru/index.php?option=com_content&task=view&id=85&Itemid=50)
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. Поскольку она там как бы заранее определена, а значит это требование...
А зачем так ломать копья по этому вопросу? Почему - просто не договориться о смыле этих терминах в рамках проекта(проектов)?
Выбрать наиболее удобную и приемлимую для всех участников конкретных работ трактовку - и пользоваться ей (и занести согласованное определение в словарь проекта :) ).
Нечеткость существующих стандартов в этом вопросе будет постоянно порождать подобные споры - до тех пор, пока не появится один общепризнанный стандарт, дающий однозначную и четкую (и верифицируемую, чего сейчас нет) трактовку таким терминам, как требование, фича, брул и т.п..
-
... один общепризнанный стандарт ...
В рекомендациях к которому будет указано, что "настоящий стандарт следует адаптировать для конкретной организации, проекта или приложения". :D
-
Действительно, решать терминологические проблемы "в общем" при отсутствии обязательных к применению стандартов практически невозможно. И я не думаю, что в обозримом будущем появится стандартизированное определение для "фичи".
А вот обеспечение единства терминологии в рамках одного отдельно взятого проекта - задача крайне важная и вполне решаемая. И ее решение, полагаю, должно находиться в зоне ответственности аналитика проекта.
-
ЭЭЭЭЭЭЭЭЭЭЭЭЭЭЭЭ, народ, ну как же так ...
Фича в понимании Vision - это требование, что нам нужно на верхнем уровне (группа ф-ти, кот нужна и без нее никак), и не важно есть оно уже в продукте или нет.
Фича продукта - это то, чем облает продукт (группа ф-ти, кот уже есть и чем этот продукт лучше конкурентов)
-
Фича продукта - это то, чем облает продукт (группа ф-ти, кот уже есть и чем этот продукт лучше конкурентов)
...или чем ДОЛЖЕН обладать продукт.
Не забывайте, что мы говорим о требованиях, а не поставке готового продукта на рынок и его рекламе
Тот факт, что фича после реализации попадает в описание продукта на коробке, это следствие того, что кто-то на начальном этапе ее придумал и далее реализовал :)
-
...т. е по мере реализации продукта "фичи" из концепции системы, которые не являются определяющими для конкуренции, перестают существовать? ))
А наш технический писатель в пользовательской документации трактует термин feature как "возможность" или "особенность" в зависимости от контекста.
-
Не ребята, поскольку термин feature пришел к нам из-за бугра, то в этом проблема. Но за бугром-то наверняка под этим термином понимается что-то определенное.
Мне импонирует определение, которое дает Виталий: фича - то, что уже есть. И переход ясен - требование (что должна делать система), фича - реализация (что уже есть). Причем в описании предложения вся разница в слове ДОЛЖНО.
Может на этом и остановиться
-
Я бы не стал заостряться на слове должна. Если в Системе уже реализована какая-то функциональность, разве это не означает, что Система должна эту функциональность выполнять.:)
Все-таки на мой взгляд, фича - это то же самое "требование (http://www.uml2.ru/index.php?option=com_content&task=view&id=85&Itemid=50)". Только высокоуровневое.
Леффингуэлл (стр.46-47 в русскоязычном издании) говорит, что:
Функция (feature) - это предосталяемое системой обслуживание для удовлетворения одной или нескольких потребностей заинтересованных лиц
-
Так для справки...
В UML "feature" означает "составляющая". Например, атрибут - то фича класса.
-
В переводе SWEBOK, по KA Software Requirements на стр. 6 приведено пояснения что есть фича, и ее "дуализм".
-
В переводе SWEBOK, по KA Software Requirements на стр. 6 приведено пояснения что есть фича, и ее "дуализм".
На самом деле никакого прояснения понятия feature в SWEBOK нет. То же самое "словоблудие". Похоже действительно, имеет смысл просто не обращать на это внимание..
-
Мне импонирует определение, которое дает Виталий: фича - то, что уже есть. И переход ясен - требование (что должна делать система), фича - реализация (что уже есть). Причем в описании предложения вся разница в слове ДОЛЖНО.
Для заказной разработки на таком подходе можно и остановиться :) При моделировании пишем требования, а потом, когда публикуем статью об успешно выполненном проекте на сайте компании выписываем списочком важные фичи.
А вот для продуктовой разработки фича может содержать слово ДОЛЖНО. Например, есть отдел, который анализирует рынок, отклики покупателей, тенденции развития отрасли и выдает постановку задачи типа "Чтобы быть конкурентно-способными нам надо выпустить продукт, на коробке которого мы сможем написать: /список фич/". И с этого начинается проработка конкретных требований и прочего.
-
На самом деле никакого прояснения понятия feature в SWEBOK нет. То же самое "словоблудие". Похоже действительно, имеет смысл просто не обращать на это внимание..
а вот с этого момента поподробнее ... Эд. Там все "русским по белому" написано.
Фича инвариантна по отношению к тому, создали вы продукт или только его замыслили ... Фича - это некое важное, например, с потребительской точки зрения свойство системы. Фича, это то, за что цениться эта система ее потребителями, или что побуждает использовать продукт. Фичи могут иметь АБСОЛЮТНО РАЗНЫЙ УРОВЕНЬ, если говорить в терминах Вигерса. Это может быть и "Возможность получить отчет по <чему-то, чего раньше не было и это ценно для заказчика>" и может быть НЕФУНКЦИОНАЛЬНОЕ ТРЕБОВАНИЕ - типа "получение отчета на 1M записей за 2 сек." - т.к. ВАЖНО получить отчет очень быстро, т.е. фичи могут быть вполне "ортогональны" пользовательским и иным требованиям. Но, при условии хорошей проработки требований, каждая из фича будет связана с набором бизнес/пользовательских/функциональных или нефункциональных требований. Т.о. фичи являются отдельным артефактом, который важен как при продуктовой разработке (набор требований должен гарантировать, что фича будет реализована в системе разработчиками), так и при заказной разработке (фичи - то что в системе особенно ценно для заказчика и опять-таки, они должны быть отражены в тербованиях). Отсюда и дуализм их природы .... Другой вопрос - с какой степенью детализации должны быть проработаны фичи.
-
А вот для продуктовой разработки фича может содержать слово ДОЛЖНО. Например, есть отдел, который анализирует рынок, отклики покупателей, тенденции развития отрасли и выдает постановку задачи типа "Чтобы быть конкурентно-способными нам надо выпустить продукт, на коробке которого мы сможем написать: /список фич/". И с этого начинается проработка конкретных требований и прочего.
Мне кажется, это просто сформулированная мысль с использованием слова коробка. Так, наверное, маркетологам легче мыслить.
Может быть вы хотели сказать, что все выше перечисленные отделы формулируют список фич (исследуют, узнают, придумывают, оформляют коробку...), а до Вас доносят в виде формулировки "Должно быть на коробке...", Что нужно интерпретировать как "Продукт должен обладать следующими возможностями..."
А по сути без разницы, заказная разработка или коробочный продукт на рынок. Сначала требования, потом поставка.
В первом случае список фич пишут на сайте, как Вы сказали, а во втором - на коробке. Это лишь способ оформления информации о продукте (системе)
-
...фичи являются отдельным артефактом...
Юрий, в чем принципиальное отличие фичи от требования?
-
Юрий, в чем принципиальное отличие фичи от требования?
Встряну.
Мне думается, что фича определяет, как мы обеспечили реализацию требования. Мы конкретно. Некое требование может быть реализовано по-разному. Разными фичами. Например отправка письма - путем нажатие кнопки, пункта меню, перетаскиванием письма в папку отправить, сказать голосом "Поехали".
Т.е. требование - пользователь должен иметь возможность оправить письмо разными способами. Фича - конкретный способ отправки реализованный в НАШЕЙ системе и выгодно отличающие ее от других систем например...
-
Фича, это то, за что цениться эта система ее потребителями
Это добрые фичи. А есть еще злые фичи, те самые, которые "Это не баг, это фича" ;)
С учетом этой языковой традиции русскоязычных разработчиков, фича в русском языке - это скорее артефакт программы, а не требование. То есть это не совсем то, что feature. ИМХО.
-
Юрий, в чем принципиальное отличие фичи от требования?
В позиционировании, назначении и способе представления.
-
В позиционировании, назначении и способе представления.
Мне всегда казалось, что в позиционировании и способе представления могут различаться даже два требования между собой. Или в таком случае как минимум одно требование требованием являться не будет? Или мы таки возвращаемся в тому, что надо дать четкие определения терминам "требование" и "фича"? Или я уже просто загнался? :)
Чем отличается назначение требования от назначения фичи? Может быть ответ на этот вопрос снимет шоры с моих глаз? :)
-
Видимо пора создать словарь терминов. На него и будем опираться.
-
Чем отличается назначение требования от назначения фичи? Может быть ответ на этот вопрос снимет шоры с моих глаз? :)
Требование - условие или возможность, которому должна удовлетворять система .... Назначение требования - сформировать представление о том что должна делать полезного система для того, чтобы иметь возможность ее спроектировать и реализовать и потом протестировать и сдать заказчику. Назначение фичи - показать, чем именно система отличается от аналогов или чем именно она будет полезна заказчику (с маркетинговой точки зрения).
-
Может быть вы хотели сказать, что все выше перечисленные отделы формулируют список фич (исследуют, узнают, придумывают, оформляют коробку...), до Вас доносят в виде формулировки "Должно быть на коробке...", Что нужно интерпретировать как "Продукт должен обладать следующими возможностями..."
Я хотела сказать, что и так тоже бывает :) Сами понимаете, что "интерпретировать как..." - как раз часть работы аналитика, к которому исходная информация приходит в самом разнообразном виде, включая данный.
Видимо пора создать словарь терминов. На него и будем опираться.
Если вы надеетесь, создав словарь, прибить слово определением к бумаге, то, боюсь, ничего не выйдет. Даже данная дискуссия показала, что то, что для одного - определение, для другого - набор слов, не привязанный к реальности. Мы можем за основу взять определения, которые привел Юрий, но неизбежно и необходимо расширить их практическими случаями применения в различных контекстах, включая жаргонные... Из данной дискуссии несколько таких случаев можно выявить.
Язык все-таки живой и от этого никуда не деться. То, что возникают споры значит, что слово используется. Чем больше вариантов, тем более употребимо слово. В том же английском языке feature используют и в хвост и в гриву и не только в рамках определения SWEBOK.
-
... Назначение требования - сформировать представление о том что должна делать полезного система для того, чтобы иметь возможность ее спроектировать и реализовать и потом протестировать и сдать заказчику. Назначение фичи - показать, чем именно система отличается от аналогов или чем именно она будет полезна заказчику (с маркетинговой точки зрения).
Юрий, спасибо. Теперь Ваша точка зрения стала ясна. :)
В том же английском языке feature используют и в хвост и в гриву и не только в рамках определения SWEBOK.
oduduka, если посмотреть любой толковый словарь русского языка, то можно убедиться, что одно и тоже слово может имеет несколько смыслов. А если открыть любой англо-русский словарь - то вообще может случиться взрыв мозга. :)
Согласен, что говорить об унифицированном использовании какого-то термина можно только указав контекст его применения.
-
Вам не кажется, что в сообществе можно зафиксировать основные понятия,
чтобы между собой говорить на одном языке?
-
Вам не кажется, что в сообществе можно зафиксировать основные понятия,
чтобы между собой говорить на одном языке?
А если не "между собой", то придётся изучать ещё один язык? Или не один? :)
Кстати, тему, согласно новым Правилам (http://www.uml2.ru/forum/index.php?topic=1901.msg19111#new), следовало назвать так:
[Термин] ФИЧА
-
Кстати, тему, согласно новым Правилам (http://www.uml2.ru/forum/index.php?topic=1901.msg19111#new), следовало назвать так:
[Термин] ФИЧА
Можно комментарий - почему так?
-
Можно комментарий - почему так?
Официальный язык форума - русский. Однако допускаются сообщения, написанные транслитом и на английском языке. Использование других языков возможно при цитировании либо в других исключительных случаях.
Нет, я понимаю, что в данном случае вопрос возник о правильном переводе слова feature, чтобы понять, о чём идёт речь в англоязычных источниках.
Но результатом перевода на русский язык не может быть слово feature. :)
-
Но результатом перевода на русский язык не может быть слово feature. :)
Ну ты конечно прав, но использовать слово фича, как-то не решался
-
Вот что предлагает BABOK
Feature
A cohesive bundle of externally visible functionality that should align with business goals and objectives.
Each feature is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.
Попытался перевести :)
Совокупность видимой функциональности, которая должна соответствовать бизнес целям.
Каждая фича - это логически связанная группа функциональных или нефункциональных требований, описанных в общих чертах.