cyxВ вакансиях аналитиков часто пробегает следующая строчка:
Проведение работ по анализу требований:as is/to be
Вопрос: в какой форме принято представлять заказчику результаты подобных работ, имеют ли они для заказчика (предприятия) самостоятельную ценность, какие инстр. средства используются? Может быть есть более содержательные синонимы?

asis/tobe ... по отношению к требованиям, несколько непонятно что имеется ввиду ... ну если только есть старое ТЗ, есть поток изменений и нужно сделать обновленное ТЗ :-).

UrriВсе просто.
As is - это результат исследования бизнес процесса в том виде, как он реализован сейчас.
To be - это то, как он должен быть реализован в результате внедрения некоего изменения.
К программному обеспечению, следовательно и к ТЗ, и то, и другое имеет весьма условное отношение. В конце концов, есть бизнес процессы, которые никак не автоматизированы. Это не значит, что они не могут изменяться.
Инструмент часто - Visio, где изображаются диаграммы workflow.

Какое отношение модели БИЗНЕС-ПРОЦЕССОВ имеют к ТРЕБОВАНИЯМ к ПО (в вопросе фигурировал термин "требования")? ... это разные области знаний. В SWEBOK в частности определено что относится к области знаний "Программные требования" (см. перевод SWEBOK в блоге Сергея Орлика). "Радует" меня микс в головах ... "все смешалось ... люди, кони" :-)

UrriНу привет! Что автоматизируем-то? Бизнес автоматизируем.
Впрочем, может быть, я не прав, и кому-то приходится анализировать требования к ПО в отрыве от автоматизируемых процессов. Дело в том, что я сам - бизнес аналитик и имею дело с бизнес ПО, поэтому для меня любой автоматизируемый процесс - это бизнес процесс.

Вопрос на засыпку :) Чем бизнес-аналитик отличается от системного аналитика и постановщика задач? :-) .... Право, мне интересно будет услышать ответ.

Очевидно, если речь идет об автоматизации деятельности организации в части каких-нибудь бизнес-процессов, то чтобы понять как устроен бизнес возможно имеет смысл описать БП в каком-либо виде. Так же очевидно, что не всегда автоматизируется бизнес-процесс целиком, а ряд операций может выполняться вручную. Требования к ПО будут описывать именно требования, эти требования вполне могут быть оттрассированы на определенные бизнес-процессы. И речь не идет об формировании требований к ПО вне контекста автоматизируемых БП, если вы об этом. Сами по себе описания бизнес-процессов не всегда достаточны для разработки ПО, сильно зависит от того:
а) что именно вы называете бизнес-процессом (иногда процессы которые происходят "внутри системы" -- как то сохранение записи в БД, изменение "флагов" бизнес-сущностей и т.п., что в том же AIM отсносится к "фунцкиональной архитектуре")
б) с какой степенью детализации вы описываете БП
в) включаете ли вы в понятие БП собственно информационную систему (как это ненавязчиво делают консультанты по ERP).
Кроме этого, существует вполне формальное определение что есть требования к ПО и это увы не бизнес-процессы, у которых, в свою очередь так же есть определение -- что есть БП .... так что отличие, как говорится, по-определению.

Кроме этого собственно вопрос по автоматизации бизнес-процессов и моделям AS-IS и ТO-BE. Представим себе ситуацию - вы копали большой котлован силами 30 человек используя лопаты. Потом решили автоматизировать свой процесс копания котлована -- стали использовать экскаватор. Ваш бизнес-процесс и его конечный результат изменился? Или просто вы стали копать котлованы быстрее и (возможно) дешевле? И как будут выглядеть модели asis-tobe при этом?

shelsoft iv250973
1) Любой аналитик при слове классик вспоминает основоположника тов. Карла Вигерса
2) Любая методика родившаяся вне определенного территориального пространства должна быть адаптирована к условиям сформировавшим на нашей почве определенные национальные правила для описания текущих бизнес-процессов. Потому как явный перенос приводит к трансформации условно говоря эллиптических моделей к явно ортогональным.
3) Батенька не шаманьте ), в противном случае вы можете оказаться в положении конферансье Театра Варьете Жоржа Бенгальского


^{______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным}


Трава видать забористая .... :-).

shelsoft byur
Не кажется ли Вам что что-то оторвалось в Вашем деле от реального мира и перешло на уровень метафор и заклинаний (меня заставила об этом подумать тематика, содержание докладов и реакция публики на SWEBOK & etc. Для себя я извлек конечно практический результат, но тема подается с таким же пафосом как Макдональдс торгует своими явно не котлетами)


Ваши предположения, остаются лишь вашими предположениями и ничем больше. Даже вы признаете, что извлекли для себя пользу из этих перевода SWEBOK, уже значит не зря старались :-). SWEBOK (точнее его перевод с дополнениями) ценен как минимум тем, что определяет содержание программной инженерии как дисциплины и дает определения многим терминам. В частности определяет что такое требования. Если терминологическая определенность для вас не несет в себе ценности, то скорее всего "что-то в консерватории нужно подправить" (c).
Ваша аллергическая реакция на "подачу темы", которая по вашему мнению подается с пафосом, думаю в большей степени определена особенностями вашего восприятия окружающей действительности при нахождении в определенном психо-эмоциональном состоянии, и корни ее скорее всего лежат не в профессиональной плоскости :-). На сим честь имею кланяться.