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

Спасибо.

Каждый читатель должен иметь читательский билет

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

Спасибо.

Вот честно говоря не понял что есть "верхнеуровневые требования на автоматизацию в бизнес-моделировании"?

Вот честно говоря не понял что есть "верхнеуровневые требования на автоматизацию в бизнес-моделировании"?

"верхнеуровневые требования на автоматизацию документа "Читательский билет""

Наверно, выражение все-таки не корректное.
Но мне видится , так как приведено уточнение про библиотеку, что имелось ввиду верхнеуровневое требование на систему или задачу.

Например, "внедрить электронное обслуживание в библиотеке".
Для этого сделать то.. + еще чего-нибудь, + выдать посетителям "электронный читательский билет".

"верхнеуровневые требования на автоматизацию документа "Читательский билет""

Поясните пожалуйста , как можно автоматизировать документ?

Маленький ликбез, простите за нотацию.

Классификация требований может быть различна. Своя классификация есть в ТЗ по ГОСТ 34, своя классификация в стандартах от IEEE, Вигерс тоже предложил свою классификацию, RUP тоже предлагает свою классификацию и т.д.

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

Поэтому высокоуровневые (верхнеуровневые) требования или требования-заказчика могут быть преломлены по классификации назначения.

Или Вы под высокоуровневыми понимаете некие цели, который планирует достичь заказчик? Тогда уровень читательского билета - слишком, простите, мелко

Если следовать моим представлением, тогда:
Ф.Т. = книги выдаются только при наличии читательского билета
Т. к К. - затрудняюсь, но может быть возможность использования электронного и простого читательского билета
П.Т. = номер читательского билета должен содержать ровно 10 символов
Т. к М. =
С.Т. = читательский билет действителен в течение одного года. требуется перерегистрация

Коллеги, чтобы ответить на вопрос, нужно чтобы он был внятно сформулирован. Честно говоря, у меня нет желания играть в игру "угадай мелодию" ... посему, предлагаю топикстартеру таки внятно сформулировать вопрос, после чего можно попытаться дать на него ответ.

Вопрос по теме требований и их классификацию.

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

Вопрос по теме требований и их классификацию.

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

Вопрос конечно не очень  specific  ... Не вполне понятно что понимается под функциональной группой. Второй вопрос, что понимается под классификацией требований - мы например знаем что у Вигерса есть деление на функциональные и нефункциональные  требования, на бизнес- пользовательские и собственно функциональные. Если речь идет о выделении высокоуровневых функций, в рамках которых они будут детализированы еще иерархией требований, то тут правила группировки могут быть самыми разнообразными - например по юзкейсам, по фичам, или по сущностям предметной области - зависит от принятого подхода ...

Если речь идет о выделении высокоуровневых функций

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

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

Про готовые методики в конкретных предметных областях я не слышал. Можно предположить, что такую методику (!) нет смысла разрабатывать - овчинка выделки не стоит. Т.к. просто зная предметную область и понимая что должна делать система, достаточно просто выделить юзкейсы, фичи или объекты предметной области (бизнес-сущности) и группировать по ним требования. Если говорить о функциях, и группировке по ним, то нужно просто представить себе, какие сервисы может оказывать система конечному пользователю и по ним группировать. Или иначе - попытаться разделить систему по высокоурованевым возможностям и особенностям системы (фичам) - собственно описать те возможности, которые будут представлять ценность для потребителя данной системы и группировать требования по ним. Но я бы постарался подойти со стороны юзкейсов  (хотя бы выделил и поименовал основные юзкейсы, без написания сценариев) и потом по ним группировал имеющиеся требования.

нужно просто представить себе, какие сервисы может оказывать система конечному пользователю и по ним группировать. ..

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

Собственно пришлось так  и делать.