Бизнес-требования хороши сами по себе, но давайте поговорим и о их друзьях, которые делают бизнес-требования еще лучше!:) #бизнесанализ #бизнесаналитик #заказнаяразработка #аналитик
По сути, речь о составе артефактов, которые практически во всех подходах составляют разделы верхнеуровневых документов с требованиями к решению. Так то глоссарий - это не только про уровень бизнес-требований, а необходимый артефакт/раздел любых документов с требованиями (что по Вигерсу, что по BABOK, что по RE, что SRS). Определение цели через метрики (показатели цели и их значения, суть - критерии достижения цели) - странно, если в документе уровня бизнес-требований его не будет. В этом аспекте неожиданно, что отсутствуют перспектива состава работ, их этапности, ограничения по бюджету и срокам. Дополнительно можно предложить перечень процессов деятельности, охватываемых решением. Понятно, что детально смоделированы они будут позже, но общие рамки работ порой стоит обозначать. Возможные кандидаты в такие "друзья бизнес-требований": - перечень категорий стейхолдеров, - порядок/регламент изменения самих бизнес-требований, - состав и этапность работ, в т.ч. требований по подготовке к вводу в действие) - перечень реализуемых процессов деятельности предметной области, - перспективы развития решения (частичный ответ, чего точно не делаем в ходе текущих работ + помощь проектировщикам в выборе подходящих технологий для решения). Иногда с неискушенными заказчиками может пригодиться раздел, явно ограничивающий область работ - "чего точно не делаем". Название - по усмотрению, например "ограничения работ".
Почитать ничего, т.к. не знаю ничего написанного конкретно про доменную модель. А что касается инструментов, всё что угодно, способное рисовать квадратики и стрелочки подойдет для этого.
@@Аналитикнагалере присоединюсь к просьбе -- было бы интересно посмотреть ролик про построение доменной модели, например с привязкой к какой-то нотации. Как раз получится убить двух зайцев -- изучить тему доменной модели, и тему использования нотаций. П.С. использовать метрики на заказной разработке тоже вполне возможно, и некоторые бизнесы охотно на это соглашаются. Не всегда и не у всех есть строгая СБ, поэтому условная Яндекс.Метрика очень даже приемлема. А если облачные решения нельзя использовать по каким-то соображениям, то можно использовать те, которые будут крутиться локально на вашем сервере. Мы, например, используем Matomo на одном из проектов -- у них есть версия on-premise с достаточно широким бесплатным функционалом. П.П. С. - спасибо за ролик, не устану хвалить ваши материалы)
Ну бизнес ограничения тоже могут со временем измениться. Вопрос в том закладываете ли вы при проектировании возможность изменять какие-то правила или ограничения. Имхо и то, и то может измениться
@@ivanskurtul2675 ну, так то и метеорит может с неба упасть и всех убить:) На бизнес-правила мы можем осознанно влиять, а на бизнес-ограничения нет. По этому разница очень большая.
@@Аналитикнагалере Вигерс (Software Requirements, 3rd edition, Chapter 9, What is a business rule) даёт следующие определения бизнес-правилам: A business rule is guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere (это с точки зрения business perspective) A business rule is a statement that defines or constrains some aspect of the business. (Это с точки зрения information system perspective) И бизнес-ограничения, и бизнес-правила в вашей интерпретации ложатся на определения бизнес-правил из Вигерса Более того одна из категорий бизнес-правил по Вигерсу - это ограничения. Бизнес-ограничения - это и есть бизнес-правила В той же главе Вигерс приводит шаблон документирования бизнес-правил. Это таблица, один из её столбцов называется Static or dynamic. Это позволяет пометить бизнес-правило: оно скорее всего не поменяется со временем (static) или вполне возможно поменяется со временем (dynamic) Я поддерживаю позицию Вигерса, не поддерживаю вашу и считаю, что не стоит отделять бизнес-правила от бизнес-ограничений
обычно компанию бизнес-требованиям составляют бизнес-разборки
😁
Обожаю вашу подачу и насыщенный материал за 5-6 минут!
Благодарю!:)
По сути, речь о составе артефактов, которые практически во всех подходах составляют разделы верхнеуровневых документов с требованиями к решению.
Так то глоссарий - это не только про уровень бизнес-требований, а необходимый артефакт/раздел любых документов с требованиями (что по Вигерсу, что по BABOK, что по RE, что SRS).
Определение цели через метрики (показатели цели и их значения, суть - критерии достижения цели) - странно, если в документе уровня бизнес-требований его не будет.
В этом аспекте неожиданно, что отсутствуют перспектива состава работ, их этапности, ограничения по бюджету и срокам.
Дополнительно можно предложить перечень процессов деятельности, охватываемых решением. Понятно, что детально смоделированы они будут позже, но общие рамки работ порой стоит обозначать.
Возможные кандидаты в такие "друзья бизнес-требований":
- перечень категорий стейхолдеров,
- порядок/регламент изменения самих бизнес-требований,
- состав и этапность работ, в т.ч. требований по подготовке к вводу в действие)
- перечень реализуемых процессов деятельности предметной области,
- перспективы развития решения (частичный ответ, чего точно не делаем в ходе текущих работ + помощь проектировщикам в выборе подходящих технологий для решения).
Иногда с неискушенными заказчиками может пригодиться раздел, явно ограничивающий область работ - "чего точно не делаем". Название - по усмотрению, например "ограничения работ".
Спасибо большое за хорошее видео.
Было бы интересно узнать про доменную модель подробнее (как ее составить, какие инструменты)? Что порекомендуете почитать на эту тему?
Почитать ничего, т.к. не знаю ничего написанного конкретно про доменную модель. А что касается инструментов, всё что угодно, способное рисовать квадратики и стрелочки подойдет для этого.
@@Аналитикнагалере присоединюсь к просьбе -- было бы интересно посмотреть ролик про построение доменной модели, например с привязкой к какой-то нотации. Как раз получится убить двух зайцев -- изучить тему доменной модели, и тему использования нотаций.
П.С. использовать метрики на заказной разработке тоже вполне возможно, и некоторые бизнесы охотно на это соглашаются. Не всегда и не у всех есть строгая СБ, поэтому условная Яндекс.Метрика очень даже приемлема. А если облачные решения нельзя использовать по каким-то соображениям, то можно использовать те, которые будут крутиться локально на вашем сервере. Мы, например, используем Matomo на одном из проектов -- у них есть версия on-premise с достаточно широким бесплатным функционалом.
П.П. С. - спасибо за ролик, не устану хвалить ваши материалы)
@@justglitchman Спасибо! если у людей есть возможность собирать и смотреть метрики - это прекрасно:)
В чём практический смысл разделять business rules и business constraints?
Бизнес-правила можно изменить, а бизнес-ограничения нет.
Ну бизнес ограничения тоже могут со временем измениться. Вопрос в том закладываете ли вы при проектировании возможность изменять какие-то правила или ограничения. Имхо и то, и то может измениться
@@ivanskurtul2675 ну, так то и метеорит может с неба упасть и всех убить:)
На бизнес-правила мы можем осознанно влиять, а на бизнес-ограничения нет. По этому разница очень большая.
@@Аналитикнагалере Вигерс (Software Requirements, 3rd edition, Chapter 9, What is a business rule) даёт следующие определения бизнес-правилам:
A business rule is guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere
(это с точки зрения business perspective)
A business rule is a statement that defines or constrains some aspect of the business.
(Это с точки зрения information system perspective)
И бизнес-ограничения, и бизнес-правила в вашей интерпретации ложатся на определения бизнес-правил из Вигерса
Более того одна из категорий бизнес-правил по Вигерсу - это ограничения. Бизнес-ограничения - это и есть бизнес-правила
В той же главе Вигерс приводит шаблон документирования бизнес-правил. Это таблица, один из её столбцов называется Static or dynamic. Это позволяет пометить бизнес-правило: оно скорее всего не поменяется со временем (static) или вполне возможно поменяется со временем (dynamic)
Я поддерживаю позицию Вигерса, не поддерживаю вашу и считаю, что не стоит отделять бизнес-правила от бизнес-ограничений
@@alexg4927 ради бога!