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