Доброго времени суток!

Просьба посоветовать литературу, поделиться мыслями и идеями и опытом по вопросу детализации бизнес и юзер требований в случае одновременного изменения нескольких систем:
Описание:
У заказчика есть старая и морально устаревшая информационная система А (вендор В1). Он хочет постепенно заменить ее на систему Б (вендор В2). На текущей фазе проекта планируется перенести часть бизнес процессов  Б1 в систему Б и соответственно перенести часть данных Д1 из системы А (Т.е. система Б будет первичной для этих данных). В системе А есть функционал для поддержки бизнес процессов Б2, который не планируется целиком переносить, но которому также нужны данные Д1. Для этой цели между системами А и Б поднимается двухсторонний интерфейс И. От бизнеса получены высокоуровневые требования для интерфейса, как работают/должны работать Б1 и Б2. При этом по большому счету бизнесу почти всегда все равно, в какой из систем что будет выполняться.
Задача:
Необходимо детализировать требования для И, подготовить соответствующий документ. Т.е. что в какой момент в Б2 система А должна запрашивать  Б и что получать взамен и наоборот. При этом изменения в А и Б будут делать разные команды.
Проблема:
При попытке понять, как можно детализировать требования, неизбежно приходится опускаться до деталей реализации, что не хорошо.
Какой парадигмы можно придерживаться, чтобы
а) Составить непротиворечивые, согласованные и полные  детальные требования для систем А и Б и интерфейса между ними
б) Не включать в требования детали реализации.


Спасибо.

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

Поскольку одна из систем уже есть и для понимания ее работы, вы будете описывать ее как прозрачный ящик. Потому элементы реализации тут необходимы. Иное дело новая система.

К тому же формирование интерфейсов обмена - это уже сама по себе реализации, ну или проектное решение.

При этом я не совсем понял противопоставления двух парадигм, да и слово парадигма тут не походит. Скорее уже стратегия

См. обратная разработка (обратный инжиниринг, реверс-инжиниринг; англ. reverse engineering), начиная отсюда http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0.

Если коротко и упрощённо, то следует
1) тщательно описать бизнес-процессы, в которых задействована старая система
2) абстрагировать функциональность старой системы из деталей её реализации (да-да, больше неоткуда; придётся основательно изучить эту систему, в т.ч., возможно, "с изнанаки"; хорошо, если экстрактор ресурсов и дизассемблер в руки брать не придётся)
3) написать требования для новой системы на основе функциональности старой
4) разбить требования на этапы, спректировать точки интеграции
5) найти (вплоть до грязных хаков с чтением и записью ОЗУ старой системы во время её работы ) места, в которых со старой системой можно было бы интегрироваться при переносе.

Делать (2) нужно, если на старую систему нет актуальной документации (что чаще всего так и бывает).

Делать (5) нужно, т.к. разработчики очень редко думают о том, что будет с их системой, когда от неё будут отказываться, а иногда даже сознательно искусственно усложняют будущую интеграцию и миграцию, чтобы обеспечить себя работой и зарплатой навсегда.

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

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

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

пункт четыре дополню планом реализации и ввода в эксплуатацию новой системы плюс план постепенного прекращения существования старой системы по мере ввода новой в эксплуатацию.

а вообще-то постановка вопроса непонятна? вас интересует как должен выглядеть этот документ с требованиям, чтоли?

<...>

Всё понятно, согласен, но как бы так сформулировать...

Когда описывают процессы "как есть" - их всё равно почти всегда описывают их "идеализированными". В них редко учитывают человеческий фактор и устранение вызванных этим фактором проблем. В частности - исправление и подпись документов "задним числом", отмена и повтроное выполнение проводок, "списывание" со cклада.

Про процессы, связанные с ведением двойной-тройной бухгалтерии, вообще говорить не приходится - если их описание попадёт в руки компетентных органов, это добром не кончится, но ведь такая бухгалтерия, к сожалению, реальность для значительной части компаний. Обычно также не учитывают существующую "кривизну" рабочего процесса, т.к. на процессы (даже "как есть") может посмотреть какой-нибудь большой начальник, ужаснуться и воздать всем по заслугам.

Если реализовать систему по таким "идеализированным" процессам, придётся потом (ещё раз) в авральном режиме делать для неё все мелкие "доработки" и "примочки", которые есть у старой системы.

Т.е. старая система - один из важнейших источников информации о бизнес-процессе и требованиях к новой системе. А из GUI не всегда можно понять алгоритм работы (в частности, способы расчёта, бизнес-правила) - старая система часто становится чёрным ящиком.

<...>

<...>

<...>

Сергей, Саша, Вадим слабо написать статью "Как подготовить детальные требования в случае нескольких систем?"

к сожалению, такие вещи на слабо не делаются :о))
это продажа квалификации либо за деньги, либо за признание (но всё равно продажа)

к сожалению, такие вещи на слабо не делаются :о))
это продажа квалификации либо за деньги, либо за признание (но всё равно продажа)

а как же амбиции? или просто альтруизм?

IMHO профессионал отличается от просто специалиста тем, что не делает лишних движений и соразмеряет масштаб своей деятельности со своими возможностями.

Альтруизм? А где тут вызов? Или есть сомнения, что тусующиеся здесь люди способны сделать это? У меня нет. Просто оно не коррелирует с их целями.

Признаться, мне на работе хватает масштабных задач, чтобы еще и в нерабочее время работать :о))

to Boatman: с удовольствием почитала бы статью по интеграции

to bubamar:
а) Правильно ли я поняла, что задача состоит в том, что есть система Б в которую ввели массив данных Д, есть система А в которую надо передать массив данных Д?

Как это выглядит:
Делим массив данных Д на массивы данных Д1 ...Дn, которые соответствуют бизнес-процессам системы А. После этого интеграционный процесс для бизнес процесса из массива Б2 выглядит как: система А запросила у системы Б массив данных Д1, система Б отдала запрашиваемые данные системе И, которая передает их системе А.

Из документации:
для системы А: спецификация запроса к системе И, спецификация ответа от системы И (умножить на число Б2), описание бизнес процессов системы А с указанием шага "интеграционный процесс"
для системы Б: спецификация сервиса системы Б (хранимой процедуры, метода и т.д.)
для системы И: описание интеграционного процесса системы И, системная модель (оно же ТЗ)

б) А вот не включать детали реализации для систем А,Б и И не получится. Метод "magic" не позволит создать качественную документацию.

Можно и подробнее.

Если bubamar выступает в роли заказчика и система И создается сторонними разработчиками, то в ТЗ (по ГОСТ 34 / 19 или вообще без ГОСТа ) при детализации требований можно ограничиться фразой: При выполнении бизнес-процесса Б2-1 в системе А из системы Б в систему А должен быть передан массив данных Д1, полученный в результате выполнения бизнес-процесса Б1-1. Такая формулировка действительно не содержит деталей реализации.

Если же bubamar выступает в роли аналитика при создании системы И, то ему в процессе создания документации приходится учитывать ответы на вопросы:
Какая из систем инициирует интеграционный процесс? (далее рассматривается случай, если активная система А, пассивная Б)
Какой запрос приходит из системы А?
Как преобразовать формат данных запроса?
Что нужно вызвать в системе Б, чтобы по параметрам переданным из системы А получить из нее необходимые данные?
Как преобразовать формат полученных данных?
Какой ответ нужно сформировать для системы А?
Какие могут быть исключительные ситуации и что делать в каждом конкретном случае?
Требуется ли логирование интеграционных процессов, если требуется, то в каких точках, какой уровень логирования?
и т.д. и т.п.

это не детали реализации?

как-то у Вас идеализированно всё получается вроде того, что:
 - системы интегрируются напрямую, т.е. только между собой
 - возможности выгрузки или загрузки данных этих систем позволяют выгрузить нужные данные
 - и все эти нужные данные есть в системе Б и они без проблем и изменений ложатся в систему А после соответствующей операции

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

P.S. хотя это всё, действительно, довольно умозрительно, т.к. о системах нам сейчас ничего неизвестно, кроме кодовых названий (А и Б).

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

периодически приходится.

вот так принципиально, чтобы была "методология", такого нет. всегда существует конкретный частный случай. иногда (но довольно редко) такие случаи похожи друг на друга. даже в случае одинакового набора систем ситуации могут сильно отличаться. кстати, AlexTheRaven вполне понятно всё описал.

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

далее нужно четко представлять, что при переходе от состояния AS IS к состоянию TO BE:
 - сложившаяся конфигурация бизнес-процессов будет меняться, и это потребует изменения рабочих процедур
 - набор данных будет меняться как в сторону расширения, так и в сторону сокращения (и это потребует определенных телодвижений на уровне бизнеса)
 - будут добавляться (как впрочем и убираться) какие-то технологические операции для поддержки работоспособности конфигурации TO BE
 - необходим контроль целостности и полноты информации в системе TO BE

поэтому нужно:
 - иметь схему информационного потока в вариантах AS IS и TO BE (обязательно), это контрольные требования, которые позволят проверить, что нужная цель достигнута
 - схему бизнес-процесса (по числу бизнес-процессов) (обязательно), это позволит разработать рабочие и работающие регламенты как для бизнеса, так и для технологического обеспечения
 - маппинг системы AS IS на систему TO BE (обязательно), это позволит определить подцели уровня реализации и план работ
остальное у Вас вроде было перечислено, если не вдаваться в чрезмерное критиканство.

а вообще есть целый класс систем, они так и называются интеграционные платформы. навскидку можно сказать, что все (?) необходимые механизмы у них есть, так что иногда даже не стоит браться за доморощенную систему интеграции или хотя бы познакомиться с их возможностями. это может пригодиться.

основная проблема тем не менее как раз в самих системах А и Б - могут ли они быть интегрированы с минимумом затрат или нет. В случае "нет" ответ на мой взгляд очевиден - старую систему нужно выбрасывать, а то ТСО будет зашкаливать.
Вопрос: как это сделать при заданных критериях оптимальности, имеющихся ресурсах и сжатых сроках?

Добрый день!

Огромное спасибо всем откликнувшимся за советы! Честно говоря, был приятно удивлен активностью и желанием поучаствовать в обсуждении.
Попробую ответить на возникшие вопросы, резюмировать и добавить побольше деталей.
Отдельная просьба - частично ответ я на него получил, получить ответ на главный вопрос:

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



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


Я выступаю аналитиком со стороны команды Б, моя задача составить часть проектного артефакта на И и Б и помочь команде А составить артефакт на систему А.
Дальше активность с нашей стороны Б перейдет к инженеру - программисту,у которого не будет интерфейса с заказчиком а только с разработчиком со стороны А.
Соответственно нужно включить все, что нужно для построения дизайна и написания кода.

В мой проектный артефакт планирую включить (помимо описания, AS IS, TO BE,ссылки на бизнес и юзер требования)

1)Описать требования к (изменению) существующей модели данных А (система разрабатывается не с нуля) На уровне

"В системе Б для сущности C должен храниться признак , при его обнавлении через интерфейс Б,
 сообщение 'Обновление сущности С'должно передать новое значение.Предположение: В системе А признак должен быть недоступен для редактирования"
2)По бизнес процессам To Be определить все сценарии использования СИ. Если процесс начинается в системе Б, указать,
что его порождает. (поможет )
3)Для каждого СИ определить основной поток сообщений (например, сиквенс диаграмма) и передаваемые параметры
Там где возможно разветвление (откат процесса), нарисовать дополнительные сообщения. Указать степень логирования.
4)Описать отдельно сообщения на уровне передаваемой информации + характеристики сообщений (кто инициирует, тип вызова, и т.п.)
5)Для каждого СИ описать какая процедура в системе А должна вызываться и что должна возвращать.


Ответы:

----------------
AlextheRaven

1)~ Описано, но не тщательно. К тому же мы (Б) не можем оценить, насколько полно :-(.
2)~ Тоже вроде есть, хотя с этим сложнее.
3)+ Да, это большая задача, так как входы для нас это требования Т1-Тn + описания AS IS, TO Be.
В целом требования ограничены потоком сообщений + процедурами обработки сообщений.
4)? не понял, что значит разбить на этапы? С точки зрения разработки? В общем это нужно, но это уже вопрос к разработчикам.
Мы в общем можем определить приоритеты.
5)- В общем не моя проблема, надежда на людей с А, что они смогут переписать свой функционал. (Ресурсы у них есть и немаленькие)


reverse engineering - хорошо, проблема, что толкового доступа к А нет.
-----------------
Водолей

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

4 + да, план нужен (правда включен он будет в другой артефакт, но не суть). Планируется переносить по кускам данных в течении года (объемы порядка 100 млн. объектов)

----------------------

AlextheRaven

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

------------------

Boatman


Подход с точки зрения пользовательских выводов интересен.
Можно считать, что первый этап пройден + зафиксированы (высокоуровневого) что в какой системе должно происходить.
Мысли интересные, еще подумаю на досуге

----------------------
...

----------------

mouse
a) Да, примерно так, т.е система Б будет на время передавать А данные Д, потом обновлять их по запросу А.
Бизнес процессы не получается разделить на А и Б, они в общем существуют независимо от систем.
Нас в общем интересуют только те, которые проходят через Б и А вместе.Спецификации запроса определять рано,
нужно понять, ЧТО нужно передавать.
С учетом различных моделей данных вопрос гадкий..Возможно есть смысл оперировать терминами А и Б одновременно, дублируя их.
Вопрос не в magic, вопрос в том, как абстрагироваться.
----------
Почему хочется избежать деталей реализации - явных ограничений нет, какое то внутренне ощущение
т.е. допускается гибкость, важно ее осознавать

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

*Отметил для себя, что будет где -
Какая из систем инициирует интеграционный процесс? (далее рассматривается случай, если активная система А, пассивная Б)
( + СИ, сиквенс диаграмма)
Какой запрос приходит из системы А?
(+ СИ, на стрелочках описание параметров + описание сообщений)
Как преобразовать формат данных запроса?
( -Не будет в документе, будет  в деталях реализации, задача процедур, описание входа)
Что нужно вызвать в системе Б, чтобы по параметрам переданным из системы А получить из нее необходимые данные?
(- Не будет в документе, будет  в деталях реализации, задача процедур)
Как преобразовать формат полученных данных?
(- Не будет в документе, будет  в деталях реализации, задача процедур, описание выхода)
Какой ответ нужно сформировать для системы А?
(+ Описание сообщений)
Какие могут быть исключительные ситуации и что делать в каждом конкретном случае?
(+ Описание аварийных сообщений, например, будут называться также как нормальные, но возвращать детали ошибок,
Отдельно описать, что будет, если что-то пойдет не так.)
Требуется ли логирование интеграционных процессов, если требуется, то в каких точках, какой уровень логирования?
(~Хороший вопрос, думаю нужно, возможно описанием СИ )