Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: Pavel_T от 04 Августа 2010, 11:46:49
-
Скажите пожалуйста, как будут выглядеть верхнеуровневые требования на автоматизацию в бизнес-моделировании?
Скажем для примера, документ "читательский билет в библиотеке".
Спасибо.
-
Каждый читатель должен иметь читательский билет
-
Скажите пожалуйста, как будут выглядеть верхнеуровневые требования на автоматизацию в бизнес-моделировании?
Скажем для примера, документ "читательский билет в библиотеке".
Спасибо.
Вот честно говоря не понял что есть "верхнеуровневые требования на автоматизацию в бизнес-моделировании"????
-
Вот честно говоря не понял что есть "верхнеуровневые требования на автоматизацию в бизнес-моделировании"????
"верхнеуровневые требования на автоматизацию документа "Читательский билет""
-
Наверно, выражение все-таки не корректное.
Но мне видится , так как приведено уточнение про библиотеку, что имелось ввиду верхнеуровневое требование на систему или задачу.
Например, "внедрить электронное обслуживание в библиотеке".
Для этого сделать то.. + еще чего-нибудь, + выдать посетителям "электронный читательский билет".
-
"верхнеуровневые требования на автоматизацию документа "Читательский билет""
Поясните пожалуйста , как можно автоматизировать документ?
-
Маленький ликбез, простите за нотацию.
Классификация требований может быть различна. Своя классификация есть в ТЗ по ГОСТ 34, своя классификация в стандартах от IEEE, Вигерс тоже предложил свою классификацию, RUP тоже предлагает свою классификацию и т.д.
На самом деле многие классификации подобны. Можно выделить (спасибо Денису Иванову и Ф.А. Новикову) два типа ортогональных классификаций:
классификация по источнику (то, что предложил Вигерс: бизнес-требования или требования заказчика, пользовательские требования, системные требования)
классификация по назначению (например, функциональные, к качеству, параметрические, к модели, специальные)
Поэтому высокоуровневые (верхнеуровневые) требования или требования-заказчика могут быть преломлены по классификации назначения.
Или Вы под высокоуровневыми понимаете некие цели, который планирует достичь заказчик? Тогда уровень читательского билета - слишком, простите, мелко
Если следовать моим представлением, тогда:
Ф.Т. = книги выдаются только при наличии читательского билета
Т. к К. - затрудняюсь, но может быть возможность использования электронного и простого читательского билета
П.Т. = номер читательского билета должен содержать ровно 10 символов
Т. к М. = ???
С.Т. = читательский билет действителен в течение одного года. требуется перерегистрация
-
Коллеги, чтобы ответить на вопрос, нужно чтобы он был внятно сформулирован. Честно говоря, у меня нет желания играть в игру "угадай мелодию" ... посему, предлагаю топикстартеру таки внятно сформулировать вопрос, после чего можно попытаться дать на него ответ.
-
Вопрос по теме требований и их классификацию.
Задача: есть довольно много разнородных требований. Необходимо их классифицировать по функциональным группам. Каждая функциональная группа по сути будет этапом разработки. Проблема в том, как определить эти группы требований в данной предметной области?
-
Вопрос по теме требований и их классификацию.
Задача: есть довольно много разнородных требований. Необходимо их классифицировать по функциональным группам. Каждая функциональная группа по сути будет этапом разработки. Проблема в том, как определить эти группы требований в данной предметной области?
Вопрос конечно не очень specific ... Не вполне понятно что понимается под функциональной группой. Второй вопрос, что понимается под классификацией требований - мы например знаем что у Вигерса есть деление на функциональные и нефункциональные требования, на бизнес- пользовательские и собственно функциональные. Если речь идет о выделении высокоуровневых функций, в рамках которых они будут детализированы еще иерархией требований, то тут правила группировки могут быть самыми разнообразными - например по юзкейсам, по фичам, или по сущностям предметной области - зависит от принятого подхода ...
-
Если речь идет о выделении высокоуровневых функций
Да, Вы правильно поняли, речь именно об этом. Проблема увидеть среди списка из более чем 200 требований некую структурированность и выделить группы. Функциональные/не функциональные - как вариант. Но после снова встанет вопрос о группировке например функциональных. Вообще есть какие-либо методики выделения групп в определенной предметной области?
-
Да, Вы правильно поняли, речь именно об этом. Проблема увидеть среди списка из более чем 200 требований некую структурированность и выделить группы. Функциональные/не функциональные - как вариант. Но после снова встанет вопрос о группировке например функциональных. Вообще есть какие-либо методики выделения групп в определенной предметной области?
Про готовые методики в конкретных предметных областях я не слышал. Можно предположить, что такую методику (!) нет смысла разрабатывать - овчинка выделки не стоит. Т.к. просто зная предметную область и понимая что должна делать система, достаточно просто выделить юзкейсы, фичи или объекты предметной области (бизнес-сущности) и группировать по ним требования. Если говорить о функциях, и группировке по ним, то нужно просто представить себе, какие сервисы может оказывать система конечному пользователю и по ним группировать. Или иначе - попытаться разделить систему по высокоурованевым возможностям и особенностям системы (фичам) - собственно описать те возможности, которые будут представлять ценность для потребителя данной системы и группировать требования по ним. Но я бы постарался подойти со стороны юзкейсов (хотя бы выделил и поименовал основные юзкейсы, без написания сценариев) и потом по ним группировал имеющиеся требования.
-
нужно просто представить себе, какие сервисы может оказывать система конечному пользователю и по ним группировать. ..
описать те возможности, которые будут представлять ценность для потребителя данной системы и группировать требования по ним.
Собственно пришлось так и делать.