Взгляд на функциональные требования к интеграционной системе
Наверное, всем разработчикам приходилось сталкиваться как с замечательными, так и с отвратительными требованиями к системе. В каждой отрасли своя специфика и определить универсальные стандарты можно только на бумаге. А когда по этим стандартами пишутся реальные требования, мы получаем стостраничные документы «ни-о-чем», которые в лучшем случае не мешают разработке, а зачастую – вводят в заблуждение относительно реальных потребностей пользователя и заказчика.
Поэтому, в этом посте я постараюсь кратко выразить свою мысль относительно определения требований именно к интеграционным системам. Прошу в ином контексте идею не рассматривать, иначе пост покажется бредом, а я – идиотом.
Основной целью любой интеграционной системы является предоставление информации конечным системам и пользователям. Эта информация должна быть полной и достоверной. Она должна быть представлена в нужном для пользователя или системы формате. Она должна поступать вовремя. Она должна быть ясной и достаточной для работы. Поэтому, прежде чем написать первую строку кода или установить первое приложение нужно ответить на ряд вопросов.
Что?
Какая информация нужна пользователям и системам? Бухгалтер не сможет работать, если ему не сообщать обо всех денежных операциях. Клиент не сможет сделать покупку в интернет-магазине, если не будет знать стоимость и характеристики покупаемого товара. Служба доставки никуда ничего не привезет, если им не сообщить адреса покупателей. А генеральный директор вряд ли примет хоть одно адекватное решение, если не будет видеть ясную картину всей деятельности предприятия. Поэтому, первое, что необходимо сделать – узнать, кому какая информация нужна для работы. Тщательно выяснить, а потом еще раз уточнить.
Где?
Где брать нужную информацию и куда ее предоставлять? Бухгалтер работает с ERPи именно в ней хочет видеть все детали. Директор предпочитает просматривать отчеты в Excel файлах, а покупатель пользуется только интернет-магазином. Ни один из них не хочет перебирать разные источники информации, делать уточняющие звонки и выяснять дополнительные детали по электронной почте. Они хотят получить все, что им необходимо в привычном для них интерфейсе.
Когда?
Мы должны не просто собрать все данные и предоставить их конечным пользователям или системам. Мы должны сделать это вовремя. Если данные, необходимые для построения квартального отчета, задержатся на пару дней, они буду уже совершенно не нужны. Если клиенту придется ждать пару минут, прежде чем он увидит цену товара и количество в наличии – он, скорее всего, уйдет к более расторопному конкуренту.
К вопросу «когда?» применимо правило пунктуальности, которое работает в обе стороны. Т.е. данные не должны запаздывать, но нельзя их передавать заранее, если в этом нет необходимости. Нет, ничего страшного не произойдет, если мы узнаем сегодня то, что нужно нам будет только завтра. Но ясное понимание того, как часто нам нужно передавать информацию, каков ее реальный объем, насколько критична оперативность и т.п. – это ключ к выбору правильной технологии интеграции. А неправильно выбранная технология – это перерасход бюджета, «сорванные» сроки проекта, притянутая за уши архитектура и вездесущие «костыли».
Ответив на три этих основных вопроса, и (главное!) зафиксировав все в документации, можно начинать думать над архитектурой и применяемыми технологиями.
По правилам, на эти вопросы должны отвечать «Функциональные требования к системе». Оно же «ФТ», или «Спецификация требований». В разных компаниях этот замечательный документ может называться по-разному, но суть одна – он определяет, а что собственно должна делать система, и зачем она нам вообще нужна? Так вот, если ФТ не отвечает на эти три волшебных вопроса – можно его смело выбрасывать. Разрабатывать архитектуру по такому документу нельзя. Не важно, насколько детально описан процесс заказа товаров, или насколько красиво нарисовали кнопочки административной панели – документ должен соответствовать своему назначению. И отвечать, на поставленные перед ним вопросы.
P.S.
И, да, когда кто-нибудь будет писать ФТ, не забывайте – каждый раз, когда программист получает бесполезный документ, он мучительно убивает маленького белого кролика!
Автор: VlaZ
