Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Galogen от 15 Мая 2014, 22:21:12
-
Коллеги, друзья.
При формулировке и анализе требований в литературе часто приводят пирамиду: потребности (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://s1.hostingkartinok.com/uploads/images/2014/05/21e717c049ce827ec0208a67e306720d.png)
Примерно. Но лучше сформулировать фичу как "Система держит Вас в курсе финансового состояния". Или ".. позволит иметь показатели под рукой в любой момент". Маркетологи придумают и получше.
Можно попробовать объяснить так: "Потребности - то, что желает потребитель. Фичи - то, что может система. Так выпьем же за то..."
Есть ещё такой пример:
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) довольно близки. При изучении этой темы (на практике), часто возникают разногласия .
Эдуард, а можно пример-другой из числа частых разногласий?
-
Эдуард, а можно пример-другой из числа частых разногласий?
Ну, сложно это сделать. Но попробую.
вот есть такое определение
Информирование читателей о наличии изданий
Полезно, чтобы при выборе издания для включения в заказ, читатель получал информацию о наличии доступного экземпляра этого издания.
Информирование о новых изданиях
Читателям библиотеки предоставляется возможность получать информацию о новых изданиях, появившихся в библиотеке. Читатели уведомляются об этом посредством электронной почты, причем только в том случае, если они согласились на рассылку таких уведомлений при регистрации. Уведомления приходят на электронный адрес, который читатель указал при регистрации.
Ясно ли где тут что?
-
Информирование читателей о наличии изданий
Функция системы. Вполне достойна выноса в перечень фич.
Полезно, чтобы при выборе издания для включения в заказ, читатель получал информацию о наличии доступного экземпляра этого издания.
Кому полезно? Ребус. Кроссворд. Если читателю - то наверное не просто полезно, а необходимо. Чтобы в пункте выдачи поменьше удивляться. Но это-то авторы постановки наверняка понимают. Значит, имеется ввиду какое-то другое заинтересованное лицо.
Я бы рассматривал так:
а) Если это фраза из ТЗ, то это необязательное пожелание, исполнение которого оставляется на усмотрение разработчика. Опасное дополнение.
б) Если это фраза из руководства пользователя (или его аналогов) - то просто рекомендация по наиболее эффективному применению системы.
Информирование о новых изданиях
Тоже функция системы. И тоже сойдет для фичлиста.
Читателям библиотеки предоставляется возможность получать информацию о новых изданиях, появившихся в библиотеке. Читатели уведомляются об этом посредством электронной почты, причем только в том случае, если они согласились на рассылку таких уведомлений при регистрации. Уведомления приходят на электронный адрес, который читатель указал при регистрации.
Избыточно лирическое человеко-ориентированное (в отличии от "системо-ориентированного") описание функции системы. Вполне достойно для включения в руководство или детализированное описание фичлиста. Для фичи слишком многословно.
(В качестве не менее лирического отступления.
Постановка с точки зрения удобства функции - жуть. Что значит "только если согласился при регистрации"? Потом - никак? Программисты ведь так и накодят.
И эта... Или библиотека очень маленькая, или недалеких соглашенцев завалит спамом обо всех поступлениях в книжный фонд, включая периодику, обновления редакций имеющихся книг и просто замены износившегося фонда).
Ясно ли где тут что?
Вполне, за исключением невнятного "полезно". Вот его бы и стоило переформулировать. Остальное пригодно для применения в документах различного характера.
-
Формулировки потребностей и возможностей (need и feature) довольно близки. При изучении этой темы (на практике), часто возникают разногласия . Хотя и поясняется, что потребность - это пожелание, которое может остаться мечтанием или превратится в требование, фича - уже требование, то чему должна соответствовать система (иметь свойства). Возможно я дую на воду, но предполагал, что есть какие-то маркеры позволяющие
а/ различать потребности и фичи
б/ корректно их формулировать чтобы не путать в последствие, ну хотя бы в рамках одной группы
Для того чтобы ощутить различия я обычно рассматриваю следующие свойства NEED и FEATURE:
- Удовлетворение NEED способствует решению проблемы (PROBLEM) или реализации возможности (OPPORTUNITY) при помощи набора FEATURE и прочих решений (вне АС).
- FEATURE обязана быть направлена на решение проблемы (PROBLEM) или реализацию возможности (OPPORTUNITY).
- Одна NEED может быть удовлетворена за счёт одной или нескольких FEATURE.
- Одна FEATURE может удовлетворять несколько NEED.
- Иногда NEED может быть удовлетворена без автоматизации и для неё не будет существовать ни одной FEATURE.
- Иногда NEED может быть вообще проигнорирована, если её удовлетворение не критично. Тогда соответствующая ей FEATURE будет иметь низкий приоритет, может быть исключена из текущего скоупа, оставлена с пометкой COULD (MoSCoW) или запланирована на будущие релизы.
- Иногда NEED не может быть удовлетворена за счёт автоматизации (или это дорого) и требуются другие решения (вне АС).
Коллеги, прошу дополнить/поправить если вы считаете что упущено что-то важное или что-то категорически не соответствует вашим представлениям.
-
Леонид, спасибо за анализ. Твердая 5-ка.
Однако авторы формулировок считали, что первая формулировка это потребность (need) - у нее есть конечно заинтересованное лицо: работник абонемента и работник книжного фонда ( через проблему Отсутствие оперативного обновления информации о наличии)
Вторая формулировка - это требование возможности (feature)
Есть краткое наименование элемента и его развернутое описание. По мне так отличить эти элементы сложно, потому полагал, может помимо указания типа элемента стоит подумать над формулировкой?
-
Для того чтобы ощутить различия я обычно рассматриваю следующие свойства NEED и FEATURE:
- Иногда NEED не может быть удовлетворена за счёт автоматизации (или это дорого) и требуются другие решения (вне АС).
Да потребность - это не требование к системе, она может и не найти решения в системе
-
Однако авторы формулировок считали, что первая формулировка это потребность (need) - у нее есть конечно заинтересованное лицо: работник абонемента и работник книжного фонда ( через проблему Отсутствие оперативного обновления информации о наличии)
Тогда, полагаю, там либо до процитированного момента было написано что-то поясняющее, либо после. Поскольку в таком виде - нечто невнятное.
Нет у работника абонемента потребности в том, чтобы читатель информировался о чем-либо. Это происходит далеко за пределами его полномочий. У него есть потребность, чтобы читатель не устраивал ему скандалы (в т.ч., по поводу отсутствия заказанного). Это совсем другая потребность и решаться она может массой методов (большинство из которых - за пределами АИС).
А работнику книжного фонда вообще без разницы, что там заказал, знает или не знает читатель. Он читателя никогда в глаза не видел и не увидит.
Выходит, что проблема "Отсутствие оперативного обновления информации о наличии" весьма отдаленное связана с потребностями упомянутых. И что более вероятно - надумана и есть ничто иное, как попытка манипулировать Заказчиком. Ну, порешать за его счет проблемы, которых у него нет.
Не очень удачный подход.
Есть краткое наименование элемента и его развернутое описание. По мне так отличить эти элементы сложно, потому полагал, может помимо указания типа элемента стоит подумать над формулировкой?
Отличить эти элементы достаточно просто, когда тот, кто их описывает, делает это внятно и последовательно. Не всегда в непонимании виноват тот, кто читает.
Сомневаюсь, что стоит как-то формализовать подобные описания. Они "про людей" или "для людей" и описываться должны естественным языком.