Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: ADIZ от 27 Июня 2008, 16:59:50
-
Здравствуйте!
Читали статью Кумара "часть 1. Использование архитектурных методов для ..." (см. http://www.interface.ru/home.asp?artId=6465) ?
1) Кумар в своей статье пишет:
- "Распространенная ошибка - формулировать бизнес-цель (например, "достичь 20% снижения издержек") как бизнес-требование."
2) Карл И. Вигерс в своей книге "Разработка требований к ПО" пишет:
- "Бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы." (см. Глава 4: Аналитик требований)
Т.е., как я понял, 1)-Кумар заявляет, что бизнес-требования (БТ) и бизнес-цели (БЦ) - разные вещи, а 2)-Вигерс пишет, что БЦ - подмножество БТ.
Я не прав? А кто прав?
-
Наверняка это особенности перевода, терминологии, восприятия, конкретного инструмента и т. п. То есть одним и тем же словом обозначены разные понятия. Что неудивительно, учитывая расплывчатость и многозначность самого понятия "цель".
-
Кажется Юрий Булуй уже где-то объяснял, что ошибкой является попытка уравнять понятия бизнес-цели и бизнес-требований.
Согласен с Григорием - понятия довольно расплывчаты + неточности переводов.
Наверное все-таки следует считать что есть некая бизнес-цель, которую стремится достичь заказчик и есть некое понимание, как его достигнуть выраженое в виде потребностей заказчика.
Наверное потребности и следует трактовать как бизнес-требования.
Еще замечу, что в Sparx Systems EA бизнес-требования выражаются как Opportunity Definition - то есть по сути описание(определение) возможностей, которым следует обладать решению.
-
Кажется Юрий Булуй уже где-то объяснял, что ошибкой является попытка уравнять понятия бизнес-цели и бизнес-требований.
Карл И. Вигерс: "Бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы"
Документ "Видение":
1. Бизнес-тербования
1.1. Исходные данные, возможности бизнеса, нужды клиентов
1.2. Бизнес-цели и критерии успеха
1.3. Факторы бизнес-рисков
2. Образ решения
2.1. Положение об образе проекта
2.2. Основные функции (характеристики)
2.3. Предположения и зависимости
3. Масштабы и ограничения
3.1. Объем первого и последующих выпусков
3.2. Ограничения и исключения
4. Бизнес-контекст
4.1. Профили заинтересованных в проекте лиц (участников)
4.2. Приоритеты проекта
Написано, что Бизнес-тербования - в разделе 1. Т.е. Бизнес-цели - это Бизнес-тербования. Это так?
И факторы бизнес-рисков - тоже Бизнес-тербования?
А функциональность системы - это же подраздел 2.2. "Основные функции". Тогда это тоже Бизнес-тербования?
Не могли бы привести примеры бизнес-требований?
-
Роман,
Цели можно описывать (декомпозировать) по разному. Можно начать с самого верха - хочу много денег, до низа - где цели уже превращаются в задачи, поэтому Вигерс и говорит, что БТ (бизнес-требования) - это цели.
Таким образом цели в нашем понимании - это увеличить\уменьшить\сократить и т.д. А БТ - это уже задачи, которые решаются для достижения этих целей.
Бизнес-требования - это по-сути БВИ в РУПе, или основные задачи, которые стоят перед бизнесом-актерами, чтобы выполнить тот или иной БП.
Примером БТ может быть: Студент должен иметь возможность зарегистрироваться на курс обучения. Теперь представим, что у нас в системе не предполагается веб-интрфейса и сам Студент не может зарегистрироваться на курс обучения, а это должен сделать помощник декана и тем самым системным требованием можем быть - Система должна иметь возможность заведения параметров нового студента. Система должна иметь возможность заведения нового курса и его параметров. Система должна иметь возможность назначения существующего в Системе Студента на имеющийся Курс.
Примером Цели в данном случае м.б. - уменьшить время требуемое на регистрацию Студента на курс.
-
Здравствуйте!
Кумара я не читала, а вот на счет Вигерса, то у него, действительно, большая путаница в терминологии. (Не смотря на всю ценность и полезность его контекста вцелом.)
Насколько я понимаю, основное отличие бизнес-цели от бизнес-требования (бизнес-задачи) заключается в том, что БЦ всегда находится за пределами рассматриваемого процесса (системы), в то время, как БТ, наоборот, всегда находится в рамках рассматриваемого процесса и служит для достижения некой цели.
Вообще, цель на бизнес-уровне – это очень выигрышный инструмент. И ее нужно четко уловить. Должна быть формализация понятия «цель», понятия «требования в контексте цели» или «проблема». К примеру, у нас есть цель – написание документа, и есть цели у Заказчика. Помимо того, у Заказчика есть цели относительно какого-то его текущего состояния и проблемы. Что-то делает его счастливым, а что-то его мучит. Поэтому, когда «совсем уже в чужую страну попадаешь», то первым делом нужно узнать, что в «этой стране» уже делается. То есть, расписать и показать бизнес-процесс «как есть».
Чем цель отличается от задачи?
Задача – полностью проверяема в рамках нашего контекста и какой-то формальной структуры. В отличие от задачи, цель – никогда полностью не проверяема.
Оценка достижения или не достижения цели учитывается с учетом помех «из вне».
Например, задача – получить документ на выходе. Цель – получит что-то больше, с этим документов достичь каких-то больших результатов, за пределами нашего понимания, знания о том, как пошел документ.
-
Бизнес-требования - это по-сути БВИ в РУПе.
Если я Вас правильно понял:
- например, берем БВИ № 18 "Выполнить операции со страховым полисом " из книги А. Коберна "Современные методы описания ФТ".
- из этого БВИ следует БТ: "Система должна выполнять операции со страховым полисом" ?
-
Здравствуйте!
Кумара я не читала, а вот на счет Вигерса, то у него, действительно, большая путаница в терминологии. (Не смотря на всю ценность и полезность его контекста вцелом.)
"С этого момента пожалуйста подробнее" (с). Можно узнать о каких терминах идет речь, в которых есть путаница?
Насколько я понимаю, основное отличие бизнес-цели от бизнес-требования (бизнес-задачи) заключается в том, что БЦ всегда находится за пределами рассматриваемого процесса (системы), в то время, как БТ, наоборот, всегда находится в рамках рассматриваемого процесса и служит для достижения некой цели.
Бизнес-целью проекта вполне может быть некое желаемое состояние бизнес-системы (!), которое может характеризоваться достижением заданных значений набором определенных параметров ИЛИ приобретение некоторых новых свойств, ценных для бизнеса. Определение того, где будет цель (за пределами системы или внутри ее) зависит от понимания того, что мы принимаем за бизнес-СИСТЕМУ. Если бизнес-система организация в целом (включая акционеров), то моей бизнес-целью может быть сокращение расходов на те же 20%. Эта цель лежит где -- снаружи или внутри?
Вообще, цель на бизнес-уровне – это очень выигрышный инструмент. И ее нужно четко уловить. Должна быть формализация понятия «цель», понятия «требования в контексте цели» или «проблема». К примеру, у нас есть цель – написание документа, и есть цели у Заказчика. Помимо того, у Заказчика есть цели относительно какого-то его текущего состояния и проблемы. Что-то делает его счастливым, а что-то его мучит. Поэтому, когда «совсем уже в чужую страну попадаешь», то первым делом нужно узнать, что в «этой стране» уже делается. То есть, расписать и показать бизнес-процесс «как есть».
Чем цель отличается от задачи?
Задача – полностью проверяема в рамках нашего контекста и какой-то формальной структуры. В отличие от задачи, цель – никогда полностью не проверяема.
Оценка достижения или не достижения цели учитывается с учетом помех «из вне».
Например, задача – получить документ на выходе. Цель – получит что-то больше, с этим документов достичь каких-то больших результатов, за пределами нашего понимания, знания о том, как пошел документ.
Написание документа не может быть целью. Это задача которая выполняется для каких-то целей. И вообще, нужно таки делать различие между целями ПРОЕКТА и целями той же операционной деятельности.
-
Если я Вас правильно понял:
- например, берем БВИ № 18 "Выполнить операции со страховым полисом " из книги А. Коберна "Современные методы описания ФТ".
- из этого БВИ следует БТ: "Система должна выполнять операции со страховым полисом" ?
Я не уверен, что "Выполнить операции со страховым полисом" - это БВИ.
Переформулирую немного свою фразу. БТ можно выражать по разному:
1. В виде иерархии целей (возможно переходящие в задачи)
2. В виде БВИ
3. В виде описания проблем и возможностей
4. В виде комбинации 3 выше перечисленных
Вам выбирать как это удобнее сделать в вашем проекте. Я обычно описываю цели и проблемы, если нужно, то дополняю еще описание БП.
Вот что пишет например Вигерс:
Business reqs = WHY we are building the product (e.g, measurable business objectives)
User reqs = WHAT the user will be able to do with the product (e.g., use cases)
Functional reqs = WHAT the developer builds (or if you prefer, WHAT behaviors the product exhibits).
Так же, когда мы выделяем цели создания ПО, то не должны путать их с целями бизнеса. Например, мы не сможем снизить убытки на 20% за счет создания ПО, т.к. это целый комплекс мер (не только ПО), но например сможем снизить кол-во ошибок при печати накладных на 90%. Видимо это и имел в виду Кумар Мани.
Но естественно, цели создания ПО должны исходить из целей бизнеса.
-
Я не уверен, что "Выполнить операции со страховым полисом" - это БВИ.
По крайней мере в книге про него сказано - БВИ
-
"С этого момента пожалуйста подробнее" (с). Можно узнать о каких терминах идет речь, в которых есть путаница?
Обязательно. Я планирую в своем блоге поместить анализ по Вигерсу, то есть,что-то вроде, "Читая Вигерса". Как будет, что показывать, обязательно ссылку дам.
-
БТ можно выражать по разному:
1. В виде иерархии целей (возможно переходящие в задачи)
-------
Business reqs = WHY we are building the product (e.g, measurable business objectives)
-------
Примером БТ может быть: Студент должен иметь возможность зарегистрироваться на курс обучения.
Примером Цели в данном случае м.б. - уменьшить время требуемое на регистрацию Студента на курс.
Перевод такой, вроде бы: "БТ = ЗАЧЕМ мы создаем систему (т.е. измеряемые цели бизнеса)"
Может тогда наоборот:
БТ = "уменьшить время требуемое на регистрацию Студента на курс" (цель, но не измеряемая - на 5 мин)
Что-то какое-то непонимание по данному вопросу
-
БТ - это некая общая формулировка. Под ней можно понимать Цели, БВИ, БП и т.д. или их комбинацию. Вигерс предлагает понимать под БТ - иерархию целей, что по моему наиболее правильно. RUP предлагает понимать под БТ - БВИ. И т.д.
-
БТ - это некая общая формулировка. Под ней можно понимать Цели, БВИ, БП и т.д. или их комбинацию.
Ок :)
-
Можно ли сделать такой вывод:
Бизнес-цель 1: бизнес-требование 1.1 (БВИ_1.1); бизнес-требование 1.2 (БВИ_1.2); ... бизнес-требование 1.n (БВИ_1.n);
Бизнес-цель 2: бизнес-требование 2.1 (БВИ_2.1); бизнес-требование 2.2 (БВИ_2.2); ... бизнес-требование 2.n (БВИ_2.n);
...
Бизнес-цель n: бизнес-требование n.1 (БВИ_n.1); бизнес-требование n.2 (БВИ_n.2); ... бизнес-требование n.n (БВИ_n.n)?
Может описано некорректно, но общая логика должна быть понятна.
-
а одно бизнес-требование может покрывать сразу несколько бизнес-целей?
-
свое собственное сообщение не могу редактировать...
поэтому уточню в этом:
Или если такая ситуация возникает, то надо дробить бизнес-требование либо укрупнять цель (сливать две)?
-
свое собственное сообщение не могу редактировать...
поэтому уточню в этом:
Или если такая ситуация возникает, то надо дробить бизнес-требование либо укрупнять цель (сливать две)?
в моем понимании сначала ставятся цели, потом - требования как их достичь. Поэтому требованиий почти всегда несколько на одну цель (если не рассматривать вырожденный случай - я такой придумать не могу сейчас).
Но одно и то же требование может соответвтсвовать нескольким целям. Например, требование аутентификации пользователя должно быть одно на все бизнес-цели, чтобы не плодить разную реализацию окошек логина (встречается и такое когда подрядчиков много и разных)
-
свое собственное сообщение не могу редактировать...
поэтому уточню в этом:
Или если такая ситуация возникает, то надо дробить бизнес-требование либо укрупнять цель (сливать две)?
Не совсем понятно как укрупнять цель. Например есть цель увеличить безопасность в компании и сделать операции в компании более прозрачными (кто за что отвечает и что делает). Для достижения обоих целей, может быть сформулировано одно БТ, например аутентификация пользователя (как в примере выше). А при укрупнении, цель превращается В Сделать компанию безопаснее и прозрачнее. Теряется весь смысл выделения целей. Цель должны быть понятной и осязаемой, а не абстрактным выражением "Хочу что-бы все было хорошо".
-
а одно бизнес-требование может покрывать сразу несколько бизнес-целей?
Требования - это средства достижения цели.
Т.е. в виде требований мы формулируем то, какой должна быть система, чтобы заявленные цели были достигнуты.
Так что в нормальном варианте требований должно быть больше, чем целей, цель обычно одна, максимум две.
Если их больше, скорее всего они причинно-следственно связаны, тогда нужно просто понять, какая основная, и переформулировать.
Лучше действовать по принципу "одна цель = один продукт", иначе получится как в басне про лебедя, рака и щуку - достичь всех сразу не получится, а получится какое-то усреднение, которое ни одной из целей не отвечает.
-
> Например есть цель увеличить безопасность в компании и сделать операции в компании более прозрачными
Во-первых это не цель, т.к. нет критериев проверки. Т.е. это некая муть, которую очень любят писать в документах, дабы не нести ответственности за плохо сделанную работу.
Во вторых, как вы это и указали, это две мути. Проверку делаем по союзу "и".
В третьих, это никак не цели, а решения, которые применяются для достижения некой цели. Вот ее и надо сформулировать. Зачем нужно "увеличить безопасность в компании"? Чему мешает текущий уровень безопасности? Чего можно будет достигнуть с новым уровнем безопасности? А можно ли достигнуть того, чего мы хотим не "увеличивая безопасность в компании", а делая что-нибудь другое? Например "уменьшая безопасность"?
Очень часто выясняется, что решение, которое формулировалось как цель на самом деле мешает достигнуть истинной цели.
> Для достижения обоих целей, может быть сформулировано одно БТ, например аутентификация пользователя (как в примере выше).
На мой взгляд, это не бизнес требование, а решение. А вот бизнес требование еще нужно сформулировать.
-
Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA). Пробовал вот в StarUML найти такую функцию, но, к сожалению, нет её.
-
А чем просто функционал рисования ДВИ не подходит?
Из FAQ
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.
-
Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA).
Cейчас в линейке Rational можно использовать 3 продкута для ДВИ, у каждого из которых есть еще свои дополнительные преимущества:
Requirements Composer - кроме ДВИ есть возможность рисовать бизнес-процессы
Software Architect - ну здесь основные преимущества скорее уже не в области анализа, а в реализации
System Architect - (бывший Тelelogic) - нотации можно модифицировать под себя - можете сделать нотацию для ДБВИ в дополнении к ДВИ ;)
конечно все 3 продукта расчитаны на совметное использование как минимум в команде с выходом на масштаб организации.
проще, наверное, начать с Requirements Composer
все можно скачать в полнофункциональном триале на сайте IBM
-
Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA).
Любой иструмент, позволяющий строить диагаммы ВИ + имеющий возможность управлять дизайном графических примитивов.
Любой графический инструмент достаточного класса, в котором можно сделать эти графические примитивы
Это если выше названных недостаточно почему-то.
Можно задать вопрос? Если Вы обращаетесь с таким запросом, то, вероятно, Вам это нужно, можно поинтересоваться какова причина?
-
Любой иструмент, позволяющий строить диагаммы ВИ + имеющий возможность управлять дизайном графических примитивов.
Любой графический инструмент достаточного класса, в котором можно сделать эти графические примитивы
Это если выше названных недостаточно почему-то.
Можно задать вопрос? Если Вы обращаетесь с таким запросом, то, вероятно, Вам это нужно, можно поинтересоваться какова причина?
Необходимо бесплатное средство для создания диаграммы БВИ. В StarUML такой возможности к сожалению нет. В Визио если нарисовать панель инструментов - вариант, но не особо приемлемый...
-
А чем просто функционал рисования ДВИ не подходит?
Из FAQ
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.
Это всё я уже читал, и не раз. Мне нужна такая нотация ДБВИ, как в Розе. Но необходимо, чтоб она была реализована в бесплатном средстве.
-
БВИ - это всего лишь стереотип от собственно ВИ. Лично я в StarUML для БВИ просто определял стереотип. Да, графический примитив не менял (честно говоря не помню даже есть ли такая возможность именно в StarUML)
-
БВИ - это всего лишь стереотип от собственно ВИ. Лично я в StarUML для БВИ просто определял стереотип. Да, графический примитив не менял (честно говоря не помню даже есть ли такая возможность именно в StarUML)
Возможности изменения графического примитива в StarUML точно нет. А вот стереотип определить новый (что-то вроде <<business actor>>, <<business use case>>) можно. Спасибо за ответ.
В StarUML привлекает то, что это средство очень похоже (в плане использования и изображения диаграмм) на Rational Rose.
-
Необходимо бесплатное средство для создания диаграммы БВИ.
То что нужно бесплатное средство- тут я не сомневался. Почему нужно средство для построения именно БВИ - не понятно. Впрочем ниже(выше) ответ дан. Есть такое чудо <<стереотип>> - один из стандартных средств расширения семантики языка UML
-
Правомерно ли утверждение, что любое требование, служащее реализации основного бизнес-процесса, является бизнес-требованием?
-
нет
-
Допустим, мы имеем дело с модулем печати документов.
Требование о том, что необходимо предоставить, по выбору пользователя, возможность напечатать комплект документов целиком или только отдельный документ - относится к бизнес-требованиям или к пользовательским?
-
Это грань неоднозначная и зависит от объёма системы и критичности этой функции для бизнес-процесса.
Для MS Word это почти наверняка будет пользовательский уровень. Для корпоративного ксерокса/принтера — бизнес.
Бизнес-требования — это то, за что готов платить заказчик/покупатель.
-
Я еще думала, что это зависит от того, какую цель реализует требование. Так, если требование печатать отдельный документ вызвано желаеним сэкономить на бумаге, и это будет значимая экономия в масштабах предприятия, то это бизнес-требование. Если не значимая, то пользовательское.
-
Если только выбор каких-то документов, то это не будет бизнес требованиями. А если состав документов меняется, то могут быть и бизнес требованиями. Т.к. для формирования документов может надо выполнить еще какие то бизнес операции.
-
Если экономия, то нефункциональные требования.
-
Если экономия, то нефункциональные требования.
Функциональные и нефункциональные требования могут быть порождены бизнес- и пользовательскими.
-
Если только выбор каких-то документов, то это не будет бизнес требованиями.
Не согласна. Согласна с Денисом, это зависит от масштабов системы и критичности требования для БП.
-
А вот, например, "необходимо предоставить программное решение, позволяющее автоматизировать процесс [..], упростить и ускорить [..]" - годная формулировка бизнес-требования? То, что пишут в ТЗ в разделе "Назначение и цели создания системы".
-
Это ожидание, а не требование. У требования есть типовые характеристики типа — атомарность, проверяемость и т.д.
-
Спасибо за ответы.
Это ожидание, а не требование. У требования есть типовые характеристики типа — атомарность, проверяемость и т.д.
А где про это можно почитать?
Вы согласны с
Я еще думала, что это зависит от того, какую цель реализует требование. Так, если требование печатать отдельный документ вызвано желаеним сэкономить на бумаге, и это будет значимая экономия в масштабах предприятия, то это бизнес-требование. Если не значимая, то пользовательское.
?
-
А где про это можно почитать?
У папы нашего Вигерса (http://www.ozon.ru/context/detail/id/1594986/) есть исчерпывающая классификация требований с перечислением их характеристик.
-
У папы нашего Вигерса (http://www.ozon.ru/context/detail/id/1594986/) есть исчерпывающая классификация требований с перечислением их характеристик.
Что-то не помню про критерии формулировок требований у Вигерса, по-моему, это из других источников.
ITIL.
-
Вы не помните - я помню :)
Глава 1. Особенности разработки требований к ПО
два последних параграфа
-
http://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%BC%D1%83_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8E#.D0.A5.D0.B0.D1.80.D0.B0.D0.BA.D1.82.D0.B5.D1.80.D0.B8.D1.81.D1.82.D0.B8.D0.BA.D0.B8_.D0.BA.D0.B0.D1.87.D0.B5.D1.81.D1.82.D0.B2.D0.B5.D0.BD.D0.BD.D1.8B.D1.85_.D1.82.D1.80.D0.B5.D0.B1.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B9
Вигерс: Страница 22 английского издания: http://books.google.com/books?ei=cEVWTqqvM4zKsgbKrM3WCg&ct=result&id=GfKbLBEjPU8C&dq=wiegers&q=Characteristics+#search_anchor
-
Глава 1. Особенности разработки требований к ПО
Та градация, которая была предложена выше, явно не из Вигерса. В частности, про атомарность у него ничего нет.
1.Единичность — требование описывает одну и только одну вещь.
2.Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3.Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4.Атомарность — требование нельзя разделить на более мелкие.
5.Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6.Актуальность — требование не стало устаревшим с течением времени.
7.Выполнимость — требование может быть реализовано в рамках проекта.
8.Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10.Проверяемость — реализованность требования может быть проверена.
Это ITIL.
-
Я еще думала, что это зависит от того, какую цель реализует требование. Так, если требование печатать отдельный документ вызвано желаеним сэкономить на бумаге, и это будет значимая экономия в масштабах предприятия, то это бизнес-требование. Если не значимая, то пользовательское.
Скорее, не какую цель, а чью. Интересы заказчика — бизнес. Пользователя — пользовательская.
-
Это ITIL.
И что из этого следует? Что у Вигерса не такая уж и «исчерпывающая» классификация? Допустим :)
-
И что из этого следует? Что у Вигерса не такая уж и «исчерпывающая» классификация? Допустим :)
Просто уточнение. :)
-
Та градация, которая была предложена выше, явно не из Вигерса. В частности, про атомарность у него ничего нет.
Это ITIL.
А с какой целью вы задали вопрос, ответ на который и так знаете? :)
-
Про ITIL я уточнила для себя по ходу участия в теме. Про Вигерса честно сказала еще на прошлой странице, что запамятовала, есть ли там критерии формулировки требований. И тоже уточнила для себя этот вопрос по ходу участия в теме.
Надеюсь, мой исчерпывающий ответ вас удовлетворил. :)
Хотя, если с этим проблемы, вы, конечно же, можете продолжать свои оффтопные в этой теме изыскания по причинах моих высказываний и прочих скрытых мотивах. Никто, кроме модераторов, помешать не может.
А я даже причинами такого поведения интересоваться не буду. :)
-
Одна из дисциплин RUP называется "Бизнес-моделирование".
-
Базука, спасибо за исчерпывающий ответ - я надеюсь, вы также вполне удовлетворены :)
-
дал ответ и разрешил продолжать оффтопные изыскания :)
-
6.Актуальность — требование не стало устаревшим с течением времени.
9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
Эти пункты я бы выкинул. Причины:
1) Это скорее "Управление требованиями". Другая дисциплина, другая классификация. Классификация методом смешения классификационных атрибутов: "Автомобили бывают легковые, зеленые и мерседесы" - меня не устраивает.
2) Обязательность — а с этим я сильно не согласен.