Баланс бизнес-документации ERP-платформы
В первой части статьи мы рассматривали общий подход к документации платформенного проекта компании NAUKA. А сейчас давайте погрузимся в детали и «начинку» конкретных документов.
Если собрать статистику по бизнес-документации нашего проекта за последние несколько лет, то соотношение будет приблизительно следующим (оценка, произведена, так сказать, «по массе» - текстовому объему этих документов по отношению друг к другу):
Возникают вопросы, не правда ли? Например, почему так много ТП (технический проект) и так мало SRS? Тут нужно дать некоторые пояснения.
Во-первых, у нас нет жестко закрепленного маршрута артефактов. Например, на основе Vision не всегда оформляется ТП, а SRS может напрямую отдаваться в разработку без ТП – зависит от задачи.
Во-вторых, у каждого нашего артефакта есть своя и довольно четкая область:
ADR – применяется, как правило, для фиксации межкомандных решений и мы часто используем его не только для фиксации архитектуры как таковой, а шире – как протокол о разделении ответственности. Это – основной документ стратегических сессий и производственных совещаний.
Vision – второй документ, который обычно формирует общую картинку на проектное решение и – классически – описывает видение и границы. Как правило, Vision оформляется на основе ADR, но часто ADR бывает самодостаточен для начала «a la НИОКР» - тут мы следуем правилу – если про задачу не понятно вообще ничего, то нечего и документы плодить, сначала поэкспериментируем.
ТП или SRS. Вот тут проявляется специфика нашего проекта: напомню, что мы находимся в ERP-доменной области, а – значит – новизна тут практически отсутствует. Собственно говоря, наши аналитики располагают просто гигантским опытом внедрений признанных лидеров: SAP, 1C, Галактика, Парус и т. д. Плюс – почти всегда есть «унаследованное ПО». Нам всегда есть на что опереться, откуда взять best practice и т.д. По сути, у нас не идет речи о хождении неизведанными дорожками – а потому, мы можем сместить фокус с исследования требований и опроса пользователей (user stories, SRS) в пользу экспертного проектирования (ТП). Отсюда и такая явная диспропорция между SRS и ТП – в ERP очень многое сводится к стандартизированному интерфейсу и понятной бизнес-логике – можно сразу писать ТП. Не хотелось бы употреблять термин «крудошлепство» (но, почему бы и нет, если все понятно и стандартизировано?) Заметьте, между SRS и ТП стоит «или» - и неспроста – если задача требует широкого сбора и фиксации требований, то обычно это не упомянутое и уже, простите, осточертевшее «крудошлепство», а какая-никакая интеллектуальная, даже инновационная задача – и тогда мы пишем SRS, которое сразу отдаем в НИОКР-разработку (без последующего оформления ТП).
Намеренно вынесем отсюда методологические стандарты: да, у нас есть концептуальные документы, такие как «Общая концепция интерфейса», ранее упомянутый «Гайд по оформлению» и т. д. – но это документы штучные, постоянно дописываемые, подвергаемые ревизиям и пересмотру, в некотором смысле выпадающие из «оперативного» контура бизнес-документации.
Что еще мы пробовали и от чего отказались:
От user stories. И не только из-за некоторой личной предвзятости аналитиков нашей команды к этому инструменту (как минимум, видится несколько неприличным использование словосочетания «я…хочу» в технической документации, да – и вообще – формат документа несколько инфантилен и серьезному стейкхолдеру даже не покажешь). Cлишком его начинка для нас очевидна. И слишком она неконкретна. В нашем проекте мы можем сразу «перескочить» через User Story и писать «серьезный» ТП
От Use Case. Сам по себе Use Case – это просто отличный инструмент самопроверки: глубина проработки повышается очень существенно, поскольку мы проходим не только по основному, но и по альтернативным вариантам, подсвечивая все поле бизнес-функций, ликвидируем ошибки – решение обретает полноту. И мы даже пытались, но, как выяснилось, мы просто не можем органично встроить Use Case в наш поток артефактов. Мы пробовали писать их сразу на этапе Vision (как дополнение к нему) – это замедляло его в 2 раза, и мы от них отказались, да, пожертвовав глубиной проработки, но ускорив рассмотрение концепции решения по Vision. А поскольку на этом этапе (Vision) возможны очень существенные правки, то «углубление» проработки мы перенесли в SRS/ТП, но уже после одобрения и уточнения концепции. Но на этапе SRS/ТП у нас Use Cases тоже как-то не прижились, начинался какой-то дубляж информации, этот артефакт оказался лишним.
По итогу на проекте сложился некий «баланс» – аналитик интуитивно понимает какой артефакт нужно оформить в каждой конкретной ситуации.
ADR
Рассмотрим наши артефакты более подробно и начнем с ADR.
За основу мы взяли два шаблона Decision record template by Jeff Tyree and Art Akerman и Decision record template using Planguage – и собрали на их основе свой.
Практика сложилась такая: на 95% ADR – это протокол совещания, на котором мы фиксируем постановку проблем:
Разграничения ответственности между командами с определением этих самых границ и поручений на проработку (например, признать какой-то справочник НСИ общесистемным и передать нашей команде в разработку или сопровождение)
Определения новых или развитие старых сервисов (как правило, в результате стратегической сессии) также с поручениями на проработку вопроса (например, разработка нового сервиса аудита, статусного движка BPM и т. д.)
Крупных интеграций между системами (как правило, с системами заказчиков – новые шины, адаптеры и т. д.)
Внутренних процессов, подлежащих автоматизации (например, описания процесса и программного сервиса лицензирования продуктов компании)
В этом случае в результате последующей проработки по ADR мы оформляем дочерние артефакты: Vision, собираем SRS или сразу пишем ТП (если все ясно).
А на 5% ADR – это самодостаточный документ с некоторой постановкой для инновационной разработки (она описывается прямо в разделе «Решение») - его сразу берут в работу и «кодят». Так было, к примеру, при разработке внутреннего процесса сведения документации в единый репозиторий – алгоритмы и настройки, описанные в самом ADR, сразу отдали девопсам в работу.
Приведем в качестве примера достаточно типовой ADR
## Название (Title)
ADR-2025-30. Реализация справочника тэгов в General Data
## Проблематика (Issue)
В настоящее время в Платформе для целей использования в проектах производственного
направления в составе General Data отсутствует единый, унифицированный и используемый
всеми потребителями единообразно справочник тэгов (приборов учета с точками).
Это приводит к необходимости реализовывать все интеграционные механизмы по получения
сведений о тэгах в каждом из заинтересованных в решении проектов:
список проектов.
## Решение (Decision)
1. Признать необходимость включения справочника "Тэги" в состав GD
2. Реализовать в составе разработки:
- модуля ведения тэгов в GD
- интеграцию по забору данных о всех существующих тэгах из АСУТП (проработать
механизм загрузки, использующийся в модуле "Анализ показателей").
Предполагается, что справочник "Тэги" в составе GD будет обращаться в АСУТП
регулярно и напрямую и загружать в себя данные обо всех существующих тэгах.
- интеграцию по забору данных о всех используемых тэгах из АСУТП
(проработать возможность интеграции через Clich по загрузке данных из
модуля "Импортированные показатели").
Предполагается, что Clich будет регулярно дозаполнять и обогащать
справочник "Тэги" в составе GD данными (и атрибутами)
по ранее загруженным из АСУТП тэгам.
3. До момента вывода указанных модулей из эксплуатации считать
справочник "Тэги" в составе GD ведомым по отношению к АСУТП и прочим системам.
4. Разрешить редактирование и обогащение в справочнике "Тэги" в составе GD только
тех показателей и атрибутов, которые не поступают из ведущих систем.
5. Обозначить, что в справочнике "Тэги" в составе GD ведутся исключительно НСИ по
тэгам (собственно, сами тэги со всей атрибутикой - например - единицами измерения), но
ведение значений тэгов реализуется функциональностью ЦСД (прикладные решения для получения
значений тэгов обращаются за ними к ЦСД).
## Статус (Status)
Концептуальное согласование: РП Платформы (ФИО), РП проектов производственного направления
(список ФИО) для определения целесообразности реализации,
согласования планов, выделения ресурсов.
## Группа (Group)
Разграничение зон ответственности по Регламенту
## Предположения (Assumptions)
Предполагается, что модуль ведения тэгов будет со временем играть все большую роль в
функционале новых прикладных приложений и постепенно замещать мастер-систему в этой части.
## Ограничения (Constraints)
Отсутствуют
## Альтернативы (Positions)
Обсуждена и отклонена альтернатива по децентрализованному ведению справочника в каждом
прикладном решении: причина - противоречие целям Платформы, как средства экономии на
идентичной в прикладных проектах разработке.
## Аргументация (Agrument)
Решения приняты исходя из объективной необходимости в заявленном функционале со стороны
прикладных решений.
## Связанные решения (Related Decisions)
отсутствуют
## Связанные артефакты (Related Artifacts)
отсутствуют
## Приоритет и сроки (Priority)
Приоритет и сроки реализации могут быть установлены Заказчиком после принципиального рассмотрения настоящего ADR РП.
## Выгодоприобретатели (Stakeholders)
- Платформенные решения производственного направления
- Общество (в части повышения качества продуктов платформенных решений)
## Владелец ADR (Owner)
(ФИО владельца)
## Основание (Base)
Производственное совещание 14.01.2025:
(ФИО списка участников)
## Дата оформления (Date)
17.01.2025
## Ревизия (Revision)
отсутствует
## Риски (Risks)
отсутствуют
## TechInfo
##### Tags
[#VendorUseOnly](#empty)
Что нам показалось методически важным при работе с ADR? Наверное, следующее:
Шаблонов ADR много, а «в лоб» применять любой из них сложно. Какие-то (как Michael Nygard) очень уж «простецкие», другие – слишком сконцентрированы на бизнес-составляющей. Мы, как видно, адаптировались и сделали акцент на формальной части (разделы: Основание, Приоритет и сроки, Владелец, Ревизия) — это не во всех «типовых» шаблонах есть, а нам важно, кто и когда это решение инициировал, принимал и когда его нужно исполнить.
Мы не пытаемся подвергать ADR очень уж долгим ревизиям– в лучшем случае 1–2, начиная с первой редакции – важно актуализировать ADR до стадии, когда решение доведено до исполнения (ушло в более подробную аналитику или сразу в разработку). Если ADR породил что-то «живое», то на его основе будут сделаны какие-то более подробные артефакты, а если нет – это повод, вернувшись, понять, на чем мы остановились в прошлом.
Отсюда и основное назначение ADR – это «память» команды. Далеко не все ADR сразу берутся в работу (на практике – процентов 30%), но вот возврат к ним происходит почти всегда – и часто при изыскании ресурсов. И вот тут очень удобно вспомнить, что же мы решили, к примеру, полгода назад?
Не нужно оформлять ADR «на каждый чих» - выделяйте только достойные этого документа проблемы.
Одновременно старайтесь не перегружать сам ADR, не уходите в проектирование – просто фиксируйте само решение, а его описание выполните в последующих артефактах.
Платформенный архитектор или аналитик оформляет ADR и включает их в реестр (ADL - Architecture decision log, простой файл README.md – дата, номер, наименование) для удобства навигации. Все ADR и реестр-ADL лежат в отдельном каталоге нашего репозитория.
Vision
Документ о концепции и границах (Vision) для нас – центральный артефакт концептуального проектирования. Он оформляется аналитиком обычно на основе резолютивной части ADR в сроки и по поручению руководителей проектов или руководства компании.
Методически мы опирались на подход Карла Вигерса и Джоя Битти, изложенный в их уже классическом труде «Разработка требований к программному обеспечению» (с момента выхода первого издания в 1999 году прошло больше четверти века!).
И, конечно, адаптировали – см. наш пример:
Документ о концепции и границах
Подсистема бизнес-ссылок на объекты в Платформе
Термины и сокращения
Сокращение | Описание |
Платформа | Сокращение для платформы Общества |
БиСО | Подсистема бизнес-ссылок на объекты на Платформе |
Конфедерация | Архитектурное решение в рамках Платформы, позволяющее функционировать территориально разделенным элементам подсистемам |
Регион конфедерации | Территориально обособленный элемент конфедерации Платформы |
ПО | Программное обеспечение |
Ядровой функционал | Общесистемный, доступный и свободно потребляемый прикладными приложениями код Платформы |
ПС | Подсистема сообщений Платформы |
СУПД | Система управления правами доступа в составе Платформы |
Адресаты
Настоящий документ по концепции и границам адресован бизнес-аналитикам прикладных проектов, руководителям проектов прикладных решений, руководителям по направлениям разработки для ознакомления и внесения корректировок при последующем оформлении SRS.
1 Бизнес-требования
1.1 Исходные данные
Значительный объем документов в модулях Платформы подвергается многоступенчатой последовательной обработке пользователями в рамках конкретных бизнес-процессов. Причем, часто возникает необходимость в рамках данной последовательной работы поделиться со смежным пользователем, вовлеченным в этот же бизнес-процесс, ссылками на документы, обработанные пользователем. В настоящее время пользователь должен каким-либо уникальным способом описать последовательность своих действий по входу в какой-либо модуль, описать условия отбора документов, перечислить их номера и воспользоваться сторонним средством коммуникации (например, электронной почтой, телефоном) для передачи этих сведений заинтересованному адресату. Форматы эти разнообразны и не стандартизированы.
Т.о. контекст и проблематика происходит из отсутствия в настоящее время простого и удобного механизма передачи сведений об объектах(документах) между пользователями Платформы.
1.2 Возможности бизнеса
Команды аналитиков в прикладных проектах, транслируя пожелания пользователей, а также ориентируясь на возможности конкурирующих программных продуктов затребовали оформление разработки базовой концепции в задаче на проектирование https:/xxxx/issue/PLATFORM-1618
Реализуемое решение, в свою очередь, должно вынести ручную обработку пользователем сведений о передаваемых другому пользователю документах в удобный автоматизированный инструмент, позволяющий с минимальными затратами времени получить требуемый результат через пользовательский интерфейс.
Потенциальными пользователями решения станут все авторизованные в Платформе пользователи.
1.3 Бизнес-цели
Поскольку настоящее решение реализуется в рамках проекта Платформы, соответственно общие бизнес-цели, критерии успеха, бизнес-риски и предположения с зависимостями рассмотрены также в документации по головному проекту.
Частными бизнес-целями решения являются:
BO-1 | Уменьшить временные потери пользователей на подготовку сведений о документах платформы |
BO-2 | Устранить передачу сведений об объектах системы через внешние средства коммуникации, повысив степень безопасности коммерческих данных за счет применение концепции полномочий при получении ссылок на внутренние объекты и документы платформы |
1.4 Критерии успеха
SM-1 | По крайней мере 30% пользователей платформенных решений, поддерживающих функции БиСО, должны регулярно использовать появившийся функционал |
1.5 Видение решения
Настоящая подсистема бизнес-ссылок на объекты (БиСО) предназначена для реализации возможности получения ссылки на произвольный бизнес-объект пользователями Платформы для дальнейшего использования по потребности – передачи пользователям через подсистему сообщений (далее – ПС) или через иное средство коммуникации.
Конструктивно решение должно быть реализовано как ядровой функционал, обеспечивающий заявленные функции для любого из новых разрабатываемых прикладных модулей Платформы по принципу «из коробки».
Бизнес-ссылка должна иметь формат гиперссылки, которую возможно вставить в любой документ – текстовый файл, почтовое сообщение и т. д.
Бизнес-ссылки должны хранить в себе сведения о регионе конфедерации (и конкретном ландшафте-хосте), в котором хранятся документы, на которые она ссылается.
Конкурентные ERP содержат похожий функционал, рекомендовано ознакомиться с одним из похожих решений:
https://wonderland.v8.1c.ru/blog/ispolzovanie-dopolnitelnykh-parametrov-v-navigatsionnykh-ssylkakh/
https://wonderland.v8.1c.ru/blog/uluchsheniya-v-rabote-s-navigatsionnymi-ssylkami/
1.6 Риски
RI-1 | Универсальная коробочная реализация может потребовать слишком много ресурсов по разработке и стать нецелесообразно дорогой |
1.7 Предположения и зависимости
AS-1 | Реализация новой функциональности не гарантирует ее автоматическое появление в каждом из ранее разработанных модулей. Предполагается необходимость их доработки для целей обеспечения полноты информации в новой технологии |
AS-2 | Развитие версий настоящего решения зависит от реализации подсистемы сообщений платформы (рассмотрено в «Vision ПС») в части последующей интеграции с функционалом включения полученных ссылок во внутрисистемные сообщений |
AS-3 | БиСО интеграционно зависима от СУПД в части обеспечения безопасности данных с гарантированной невозможностью просмотра по ссылкам документов, запрещенных для просмотра по полномочиям СУПД |
As-4 | Авторизация пользователей на Платформе должна выполняться стандартным образом и никак на связана с содержимым бизнес-ссылки. Однако, поскольку желательно избавить пользователя от принудительной авторизации в случае, если в переход по бизнес-ссылке производится из внешнего источника (письма, сообщения мессенджера) и при этом у пользователя уже открыт браузер с действующей авторизованной сессией в Платформе – необходимо воспользоваться уже существующим токеном и открыть еще одну вкладку Ланчера, то существует зависимость сервиса авторизации от БиСО |
2 Рамки и ограничения проекта
2.1 Основные функции
FE-100 | Возможность формирования ссылки пользователем-отправителем из тулбара любого грида (как головного, так и подчиненного) на А) Запись раздела с отражением единственной фокусированной ссылочной записи Б) Запись раздела с отражением единственной фокусированной ссылочной записи и вызванной для нее формой модального просмотра |
FE-110 | Возможность формирования ссылки пользователем-отправителем из тулбара любого грида (как головного, так и подчиненного) на В) Отражаемые на его экране множественные записи раздела с наложенными фильтрами Г) Отражаемые на его экране множественные записи раздела с наложенными фильтрами и сфокусированной строкой |
FE-120 | Возможность формирования ссылки пользователем-отправителем из тулбара любого грида (как головного, так и подчиненного) на Д) Отражаемые на его экране множественные записи раздела с наложенными фильтрами и помеченными записями |
FE-200 | Возможности добавления комплексного текстового описания для формируемой ссылки |
FE-210 | Возможности автоматического формирования текстового описания для сформированной ссылки для случаев FE-100 |
FE-300 | Возможность включения сформированной ссылки пользователем-отправителем в сообщение, отправляемое по электронной почте |
FE-310 | Возможность включения сформированной ссылки пользователем-отправителем во внутрисистемное сообщение (в составе интеграции с функциональностью ПС Платформы) |
FE-400 | Зеркальная возможность для FE-100 для пользователя-получателя – провалиться по полученной ссылке - с реализацией ограничения на просмотр данных из СУПД и авторизацией в платформе (при необходимости) |
FE-410 | Зеркальная возможность для FE-110 для пользователя-получателя – провалиться по полученной ссылке - с реализацией ограничения на просмотр данных из СУПД и авторизацией в платформе (при необходимости) |
FE-420 | Зеркальная возможность для FE-120 для пользователя-получателя – провалиться по полученной ссылке - с реализацией ограничения на просмотр данных из СУПД и авторизацией в платформе (при необходимости) |
FE-500 | Пользователь-отправитель должен иметь возможность управлять направлением просмотра документов ссылки («У отправителя» или «У получателя») для того, чтобы получатель проваливался либо непосредственно в систему отправителя (его конфедеративный регион, хост), либо в локальные реплицированные данные получателя (локальный конфедеративный регион и хост получателя). Для случая «У отправителя» в состав данных бизнес-ссылки необходимо включать сведения о конфедеративном регионе, хосте отправителя для автоматического направления туда получателя. Для случая «У получателя» такие сведения в состав бизнес-ссылки не включаются (а включается ссылка на дефолтный хост через переменную окружения и признак ландшафте: dev, qa, prod) и получатель должен сначала авторизоваться в Ланчере в нужной ему системе, а потом заходить по ссылке. |
Важно: для целей передачи фильтрованных данных необходимо также включать в состав данных бизнес-ссылки сведения о сессионных пользовательских настройках, поскольку они неявно участвуют в фильтрации данных пользователя на экране
2.2 Состав первого и последующих выпусков
Функция | Выпуск 1 – Базовый функционал | Выпуск 2 – Развитый функционал | Выпуск 3 – Интеграция с ПС |
FE-100 | X |
|
|
FE-110 |
| X |
|
FE-120 |
| X |
|
FE-200 | X |
|
|
FE-210 |
| X |
|
FE-300 |
| X |
|
FE-310 |
|
| X |
FE-400 | X |
|
|
FE-410 |
| X |
|
FE-420 |
| X |
|
FE-500 |
|
| X |
2.3 Ограничения и исключения
LI-1 | Реализация функционала Выпуска 3 возможна только после реализации в ядровом функционале ПС Платформы |
3 Бизнес-контекст
3.1 Профили заинтересованных лиц
Детально в настоящем документе не описываются, поскольку категории «Ценности», «Отношений», «Интересов» и «Ограничений» являются общеплатформенными и должны быть рассмотрены в документах Vision по Платформе.
3.2 Приоритеты
Все функции выпуска 1 должны быть полностью реализованы
Все функциональные тесты должны быть выполнены.
Все тесты безопасности данных должны быть выполнены
Выпуск 1 должен быть доступен в ядре к dd.mm.yyyy г.
Последующие выпуски определяются соответствием критериям успеха и приоритизацией задач по проекту Платформы
Реализуется составом команды по проекту «Платформа».
Первичное апробирование в прикладных решениях осуществляется привлечением команды по проекту «Феникс»
3.3 Особенности развертывания
Реализация функционала БиСО потребует:
· выпуска новой версии ядра Платформы с соблюдением функционирования ранее разработанных приложений в legacy-режиме
· доработок сервиса авторизации в части вторичного использования токена уже открытых сессий
Реализация функционала БиСО в модулях, разработанных до реализации функционала БиСО, потребует опциональной переработки кода таких приложений для включения в них новых функций.
Не будем его пересказывать – за эти годы написаны просто «тонны» работ по этой теме, подчеркнем только те моменты, которые мы изменили:
В первом разделе бизнес-требований:
Практически полностью исключили денежную составляющую. Затраты оцениваются после Vision на основе трудооценки, которую дают лиды. А поскольку наш продукт – внутренний, то прямые продажи мы также не оцениваем.
В видении решения отказались от формализованных диаграмм. Максим Цепков на своих выступлениях назвал подобное «диаграммой с домиками и гномиками» - мы тоже рисуем простые, но понятные картинки с архитектурой верхнего уровня, отдаленно напоминающие контекстную диаграмму – не более. Все-таки формализованные диаграммы требуют владения нотацией – а ключевые стейкхолдеры «просто хотят посмотреть презентацию» и не разбираться в видах гейтов и пиктограмм.
В третьем разделе бизнес-контекста:
Отказались от формата приоритетов проекта по измерениям – ну, не понимают потребители Vision этих суррогатов – «Движущая сила», «Степень свободы»! Всегда было какое-то недоумение по этому пункту. Переписали его простыми русскими словами и ушли от табличной формы.
Расширили раздел развертывания. Тут Вигерс уже не дает полноценного шаблона – нам же нужно хорошо понимать влияние но��ой функциональности на весь наш DevOps в случае, если разрабатываемое решение его как-то существенно модифицирует.
В итоге наш Vision исполняет протокольное поручение ADR и преследует единственную цель – описать в крупную клетку будущее решение и объяснить всем стейкхолдерам, что же мы на самом деле собираемся сделать и достичь единого понимания задачи.
Мы всегда проводим очную защиту Vision. Это важно! Аналитик чуть ли не вслух читает особо существенные положения, особо акцентируя внимание на:
Архитектурном скетче – фактически, проводит презентацию вот этой неформализованной картинки – это и есть «проговаривание», пояснение всей начинки Vision
Составе релизов и сроках. Собственно, после основной презентации – это часто центральный пункт всей защиты. Самые серьезные споры возникают по составу MVP и срокам его реализации. Оно и понятно – MVP-то будет сделан, а вот все последующие релизы – еще большой вопрос. Получит ли заказчик в составе MVP половину яблока или жалкий огрызок функциональности –предмет ожесточенных баталий.
Бывали случаи, когда Vision так и не удавалось согласовать – но, тогда мы и не углублялись в подробную аналитику и разработку, не тратили на это время! Да – мы отказались от работ, но сделали это на максимально ранней стадии, не потратив ресурсы.
По итогам успешной очной защиты мы дорабатываем Vision и проводим его через окончательное Git-согласование стандартным образом.
SRS
Редкий для нас случай, поскольку оформляется он для не совсем типовых задач на основе ADR или Vision. За основу мы взяли «старинный», но рабочий шаблон того же Вигерса и адаптировали под наши нужды, расписав примеры формулировок для аналитиков по каждому пункту.
Уберем его под спойлер - это большой документ.
Спецификация требований к платформенным продуктам и системным компонентам
Термины и сокращения
Базовый словарь приведен в Vision Платформы. Расширяется следующими понятиями:
Сокращение | Описание |
Шаблон, Шаблон требований | Альтернативное название настоящего документа – спецификации требований к платформенным и системным компонентам |
Заказчик | Представители прикладного или платформенного проекта, выступающие в такой роли (внутреннего Заказчика). Как правило, это - аналитики и технологи таких проектов. |
Внешний Заказчики | Представители Клиентов, потенциальных Клиентов. Как правило должны донести свои требования до внутреннего Заказчика для оформления ими настоящего Шаблона |
Исполнитель | Вендор Платформы, Компания ООО «НАУКА», производитель ПО для внешнего Заказчика |
Общие положения
Настоящий документ содержит шаблон спецификации требований, которые предъявляются к существующему или новому ядровому функционалу Платформы или сервисного компонента Платформы.
Как правило, настоящий документ должен быть оформлен внутренним Заказчиком и уточнен аналитиком ядра или СК (по результатам их совместной работы и консультаций) по факту выставления каких-либо функциональных требований к ядру или СК.
Настоящий Шаблон требований должен соблюдаться безусловно, в полном объёме. В случае, если какие-либо разделы Шаблона описывать нецелесообразно или они по факту отсутствуют в содержании требуемой функциональности, то они явно должны быть помечены как отсутствующие в соответствующем разделе.
В Шаблоне не должна рассматриваться высокоуровневая спецификация, характерная для документов уровня концепции, Vision и т.д – предполагается, что требования заявляются к существующему компоненту ядра или СК. В случае, если требования касаются необходимости разработки нового компонента, то Шаблон не оформляется, а по распоряжению РП Платформы архитектором Платформы подготавливается Vision на такой потенциальный новый компонент.
В случае, если на момент оформления Шаблона информации по разделу недостаточно, то необходимо пометить неисследованную проблему тегом «TBD» (to be determined – необходимо определить позднее).
Адресаты
Настоящий документ адресован:
Аналитикам и технологам прикладных и платформенных проектов для целей первичного оформления требований по Шаблону
Команде ядра и СК Платформы:
аналитикам, архитекторам - для целей анализа исходных требований Заказчика, их уточнения, дооформления, согласования с Заказчиком и формирования итоговой документации (технических заданий, частных технических заданий и т.д.) для передачи в конвейер разработки.
тех.лидам, программистам, тестировщикам, РП – для ознакомления с исходными согласованными требованиями внутреннего Заказчика. В случае, если в оформленном Шаблоне по согласованию тех. лида и аналитика Платформы или СК присутствует достаточно информации для начала разработки, то допускается передавать в конвейер разработки сам Шаблон без оформления ТП, ЧТП и т.д. В противном случае аналитик ядра или СК обязан оформить дополнительную рабочую документацию.
техписам – для оформления пользовательских инструкций
1 Сведения об инициаторе
В данном разделе указываются формальные сведения об инициаторе требований
Тип сведений | Содержание | Примеры и особенности заполнения |
1.1 Ф.И.О. Инициатора | Полное Ф.И.О и должность Инициатора | Примеры: Младший аналитик Петров Иван Федорович |
1.2 Проект | Наименование платформенного или прикладного проекта (продукта), который заявляет требования. При необходимости указывается несколько проектов | Примеры: Web.УТО Web.МТО Ядро СК |
1.3 Дата оформления требования | Дата первичного оформления Шаблона Заказчиком |
|
Номер требования | Кодированный в рамках проекта номер требования, присваивается Инициатором | Каждый проект использует префикс требования идентичный префиксу проекта в системе «Феникс» Примеры: AVRORA_II -123 KATALG-15 SBIT-345 |
1.4 Наименование требования | Краткое (не более 1 предложения) наименование требования для удобства навигации по каталогу требований, отражающее его суть | Примеры: Доработка СУПД в части реализации парольной политики Дополнение тулбара общесистемного грида кнопкой общесистемной печати Реализация механизма прогреваемого кэша в ЦСД |
1.5 Заказчик | Указывается (при наличии) клиент, инициировавший данное требование, договор и этап, документ-основание (акт, протокол разногласий, протокол производственного совещания и т.д.) контактное лицо Клиента | Примеры: Внутренняя инициатива команды проекта Решение арх. комитета, протокол страт. сессии (ADR) от 13.02.2024 ООО «Рога и копыта», закрытие работ по 3-му кв. 2024 г. в части СУПД, Сидоров С.С. ПАО «Альфа и омега», актирование работ по 2-му кв. 2024 г. в части Сбыта, протокол производственного совещания от 13.05.2024, Иванов И.И. |
2 Назначение и границы
Тип сведений | Содержание | Примеры и особенности заполнения |
2.1 Назначение | Кратко описывается продукт, приложение, функциональность внутри приложения, идентифицируйте полный путь к месту доработки\разработки – в частных случаях необходимо локализовать место доработки до конкретного грида, кнопки, иного объекта внутри модуля. Указывается заменяемая историческая функциональность (желательно указать доступ к тестовому стенду исторической системы) Расшифровывается контекст и происхождение функциональности Визуальная модель в виде контекстной диаграммы не подготавливается Заказчиком, должна быть разработана аналитиком ядра или СК при необходимости в рамках ТП | Примеры: Разработка модуля ведения конкурсов в составе приложения МТО, позволяющая реализовать функциональность регистрации, согласования, наполнения, проведения, результатов конкурса. Заменяет модуль «Конкурсы» ИС «Очень старая система». Доработка инлайн-редактирования в гриде ядра в части реализации выпадающих справочников при редактировании ячеек Доработка приложения «General Data», модуля «Объекты ЕОС» - внесение пагинации в грид объектов для целей повышения производительности |
2.2 Версия ПО | Указывается (при наличии) текущая версия (релиз) дорабатываемого компонента. Целесообразно указывать ссылку на статью с релизом в соответствующем разделе Git | Примеры: Новое ПО (компонент), версия еще не существует General Data 1.0.0 |
2.3 Термины и сокращения | Оформляются так же, как в настоящем документе – отдельным разделом с глоссарием терминов. В случае, если документ конкретизирует документ более высокого уровня, например, Шаблон конкретизирует Vision, то глоссарий Шаблона должен содержать только новые, еще не раскрытые в Vision термины
| Рекомендуется не расшифровывать массовые общеупотребительные и действительно широко распространенные аббревиатуры – например, REST, API, СУБД, а сконцентрироваться на специфических сокращениях Примеры: Контировка – это указание в первичном или сводном документе бухгалтерских счетов для последующей записи (проводки) по ним хозяйственной операции из документа |
2.4 Границы | Кратко описываются границы функциональности |
|
2.5 Ссылки | Перечисляются ссылки на нормативную базу, внутренние стандарты и положения В случае использования в функциональности стандартизированных протоколов, форматов обмена данными их указание обязательно в данном разделе Возможно указание ссылок на платформенные стандарты (например, концепцию интерфейса) в противоречивой или требующей дополнения части | Примеры: Итоговая выгрузка данных декларации выполняется в соответствии с утвержденным ФНС форматом. Получение данных от ЦБ РФ производится через API, контракт которого размещен на сервере |
2.6 Характеристики пользователей | Для вновь разрабатываемой функциональности, по которой такая оценка еще не проведена в ранее сформулированных требованиях более высокого уровня, указываются: · пользователи (реальные или технические, «роботы», сервисы), которые будут пользоваться требуемой функциональностью · их фактическое или потенциальное количество с трендом роста на обозримом интервале жизни продукта · режим работы пользователей и их часовые пояса · перечисляются привилегированные пользователи, администраторы всех видов, супер-пользователи · режим предоставления функциональностью ответа пользователю – синхронный или асинхронный | Пример: Функциональность не изменяет оценку пользователей, ранее предоставленную в Vision Все конечные прикладные пользователи прикладного приложения Web.УТО На текущий момент на продуктивной системе ООО «Альфа и омега» количество пользователей может быть оценено в 50 человек. Потенциально может быть увеличено до 70 человек в ближайшие 3 года. Продукт должен предусматривать гарантированное конкурентное функционирование до 200 пользователей (на потенциальных предприятиях-клиентах) Все пользователи работают режиме 8 часового режима рабочего времени с понедельника по пятницу, работа в выходные дни не ведется. Возможно автоматизированное обращение к разрабатываемому сервису через API заданием по расписанию (указать) в синхронном режиме Все пользователи сконцентрированы в едином часовом поясе +3 по МСК. Пользователи используют функциональность в режиме 24/7, вывод системы из эксплуатации (профилактика, обновление) возможны по предварительному согласованию в соответствии с Регламентом (указать). Привилегированные пользователи отсутствуют |
2.7 Операционная среда и зависимости | Описывается операционная среда, в которой предполагается разрабатывать требуемую функциональность: указываются только отличия от стандартного платформенного приложения или уже разработанного стека технологий существующего компонента ядра Платформы \ СК При наличии сведений уточняются и обосновываются: · особые аппаратные требования (наличие специализированного оборудования, серверов, конфигурации сетей) · требования к использованию конкретного программного обеспечения: ОС, СУБД, серверов приложений, платформ, фреймфорков, библиотек, SDK, программно-аппаратных комплексов · обязательна полная расшифровка используемого стороннего проприетарного ПО; ранее не использованного ПО в составе Платформы и СК, блокирующего ПО Указанные выше зависимости могут потребовать эскалации Шаблона до арх. комитета для принятия решения и санации рисков, о чем необходимо упомянуть в данном пункте | Примеры: Новая функциональность является частью платформенного приложения «Web.УТО» и не выходит за пределы его стека. Новое приложение разрабатывается как стандартное приложение Платформы с использованием следующих компонентов: ядро, UI Kit, сервисы (авторизации, логирования), Content Server (решение арх. комитета в рамках стратсессии от 12.02.2024) Вновь разрабатываемое приложения является отдельно стоящим приложением, разрабатываемым на следующем техническом стеке: БД Redis, Java, Vaadin, React. Указанный стек фиксирован в требованиях внешнего Заказчика (см. п.4.3 ТП от Заказчика)
TBD: Стек технологий вновь разрабатываемого приложения не может быть сформулирован на момент написания настоящих требований и требует выполнения исследовательских работ (указать мотивацию неопределенности – highload, объемы данных и т.д.) |
3 Функции системы
В зависимости от сложности требуемой функциональности необходимо декомпозировать функциональные требования иерархическую структуру, где в головные общие разделы подчинить более низкоуровневые функции и подфункции.
Рекомендуется использовать метод классификации по функциональным областям.
Каждая конечная функция описывается следующим составом сведений:
Тип сведений | Содержание | Примеры и особенности заполнения |
3.1 Код функции | Присваиваемый код функции для каталогизации и оформления ссылок функциональности, зависимостей и т.д. Присваивается Заказчиком. Рекомендуемый формат: FE-xxxx | Примеры: FE-1000
|
3.2 Описание | Кратко (1–2 предложения) описывается суть функции
| Примеры: Интерфейс ведения CRUD-операций в модуле «Типы документов» Обеспечение экспорта данных в MS Excel выделенных записей в гриде |
3.3 Функциональные требования | Перечисляются по пунктам конкретные функциональные требования к данной функции, реакции на действия пользователей, типовое поведение, альтернативные варианты функционирования, поведение при возникновении ошибок. Не допускается офор��ление требования в формате User-Story Допускается оформление функционального требования в спецификации Use-Case Для требований могу указываться атрибуты: · особое основание, · источник-инициатор (конкретное лицо, важный стейкхолдер), · состояние (актуально, отложено в бэклог и т.д.), · приоритет по оценка Заказчика (критический - низкий) · отнесение к релизу, пункту плана (требуется в составе MVP или нет) |
|
3.4 Требования к производительности | Описываются особые требования по производительности для бизнес-функции, если они не укладываются в общесистемные для приложения, модуля и т.д. | Пример: Для разрабатываемого отчета допускается увеличенное время его формирования – до 1 часа |
4 Требования к данным
В зависимости от масштаба требуемой функциональности описываются следующие требования к данным:
Тип сведений | Содержание | Примеры и особенности заполнения |
4.1 Характер обрабатываемых данных | Описывается характер и основные варианты обрабатываемых данных Указываются все типы обрабатываемых данных и схема их хранения, тип БД (реляционная, NoSQL, in-memory, распределенная и т.д.) | Примеры: Система должна обеспечивать хранение видео-файлов форматов (MP4, MOV) на сетевом хранилище Система хранит бизнес-данные документов в виде строк реляционной БД Postgres (стандартное приложение Платформы) Система хранит шардированные по годам и компаниям-владельцам данные в in-memory кластере Tarantool (json-документы формализованной структуры – указать какой), доступ по key-value |
4.2 Источники данных | Описываются системы, которые являются источниками данных для каждой сущности, механизмы из появления, как порождаются данные Определяются ведущие мастер-системы, системы-потребители данных Указывается наличие или отсутствие дублирования данных по описанным системам, подписки на данные и т.д. Для сложных систем желательно приложить общую диаграмму движения данных в виде скетча, наброска | Примеры: Все сущности проектируемой функциональности обслуживаются модулями приложения «Сбыт», данные хранятся централизованно в единой схеме БД приложения «Сбыт» Сущности «Накладные» и «Счета» порождаются непосредственно действиями пользователя в интерфейсе разрабатываемых модулей приложения «Сбыт», не загружаются из внешних систем. На данные сущности может быть оформлена стандартная подписка Платформы другими приложениями Платформы. Работа в режиме «мульти-мастер» невозможна - единственной мастер-системой является для данных сущностей приложение «Сбыт» Сущность «Счета-фактуры» загружается по расписанию через ETL Clich в структуры модуля «Счета-фактуры» приложения «Сбыт» из системы ИС «Очень старая система». В модуле «Счета-фактуры загруженные данные доступны только для чтения и не могут изменяться. Проектируемые модули используют подписку на приложение General Data в части справочников «Материалы», «Контрагенты» |
4.3 Схема хранения данных | На момент оформления требований для вновь разрабатываемых решений может отсутствовать подробная спецификация атрибутов данных и их взаимосвязь – она может быть разработана позднее в ходе проектных работ, однако, для целей предотвращения архитектурных ошибок должны быть обозначены следующие сведения (по каждой проектируемой логической сущности): · типовой объект ведения данных (приблизительный атрибутивный состав с типами данных) · объем данных (количество записей, документов) с темпами роста на горизонте планирования проекта (продукта) Для доработок существующих решений и компонентов необходимо указывать ссылку на существующие схемы описания данных Для реляционных схем хранения данных желательно приложить проект физической ERD-диаграммы Для остальных – логическую ERD-диаграмму В случае, если на момент выставления требований известно о следующих особенностях ведения данных (например, из-за гарантированных объемов данных), их необходимо описать: · очевидна необходимость применения партиционирования на уровне СУБД · очевидна необходимость применения шардирования на уровне СУБД Необходимо обосновать принятые решения с учетом пункта «Отчетность» и механизмов доступа к данным | Примеры: Система хранит сведения о контрагентах в структуре реляционной БД (см. общую ERD-диаграмму) Необходимо дополнить набор сведений о службе в словаре General Data «Службы» локализованными данными (см. таблицы ref_branches_langs) на диаграмме
Система хранит формализованные в виде json документы об истории курсов валют. Формат json приведен здесь. Предполагаемое количество записей в сущности «Счета-фактуры» - до 1 млн. в месяц с ежегодным темпом роста в 10% Целесообразно применение шардирования данных с разбивкой по признаку структурного подразделения, поскольку пользователи системы всегда вносят и выбирают данные только по своему подразделению, данные между подразделениями распределены относительно равномерно. |
4.4 Резервирование и целостность | В случае, если требуемая функциональность требует особого, отличного от стандартного Платформенного приложения механизма, регламента и процедуры резервирования данных, то необходимо описать его Указываются: · все требования, относящиеся к защите целостности данных системы. · процедуры, которые могут потребоваться, например резервное копирование по расписанию, создание контрольных точек · проверка корректности данных · политики, которые должна применять система для хранения или утилизации данных, в том числе временных данных, метаданных, остаточных данных (таких как удаленные записи), данных в кеше, локальных копий, архивов и промежуточных архивов | Примеры: Резервирование данных осуществляется силами и средствами внешнего Заказчика без привлечения вендора (Компании Наука) Резервирование выполняется встроенными средствами разрабатываемой функциональности (функция FE-0101) Резервирование выполняется с использованием стороннего проприетарного ПО (указать), интегрируемого с разрабатываемым приложениям через механизм считывания WAL БД Postgres Проверка целостности и корректности данных выполняется на двух уровнях – на backend в рамках бизнес-логики методов, выполняющих операции с данными, и на уровне БД путем выставления ограничений и внешних ключей В системе реализуется политика логического удаления бизнес-данных – физически они не удаляются, лишь получают отметку об удалении |
4.5 Физическое расположение | В случае, если на момент выставления требований известно о следующих особенностях ведения данных, их необходимо описать: · Указать потенциальное физическое (территориальное) расположение данных – продуктивных и иных ландшафтов в привязке к ЦОД · Политики автономности · Конфедеративный режим для Платформенных приложений | Пример: Проектируемая функциональность не расширяет географию ведения данных, она определена вышестоящими документами и проектной документацией приложения Web.УТО Проектируемая функциональность оперирует данными, размещенными частично на серверах ООО «Альфа и омега», частично на серверах ЦОД ООО «Омега и альфа», должна обеспечивать функционирование в конфедеративном режиме |
4.6 Механизмы обращения к данным | Описываются механизмы создания, исправления, удаления, чтения данных Желательно обозначить доли операций записи (CRUD) и чтению, классифицировать систему, как преимущественно транзакционную, аналитическую, смешанную. В случае автоматизированного (не пользовательского, интерфейсного ввода), например, через вызов API, скриптами на уровне БД, ETL импорта и т.д. необходимо указать интенсивность таких операций | Примеры: Планируемая функциональность не затрагивает изменение существующего порядка обращения данных, определенного в вышестоящей документации по проекту. Операции с данными выполняются исключительно через пользовательский интерфейс разрабатываемых модулей Функциональность должна предоставлять возможность ведения CRUD-операций через безопасный внешний API, который будет использоваться внешними системам с интенсивностью до 100 операций модификации данных в минуту. Соотношение операций записи к операциям чтения (для целей выбора данных в гриды и отчетности) составляет 1 к 10, т.е. система преимущественно аналитическая В связи с тем, что в проектируемой функциональности крайне высока интенсивность операций по выборке данных целесообразно выделение нагрузки на чтение данных для целей аналитики в отдельную витрину данных |
4.7 Срок хранения данных, горячее и холодное хранилища данных | При наличии сведений описывается (по каждой сущности, группе сущностей):
· Временная глубина гарантированного хранения данных непосредственно в оперативном хранилище приложения (исходя из интенсивности и статистики обращения пользователей) · Критерии и необходимость разделения данных на горячее и холодное хранилище | Примеры: Система должна обеспечивать оперативное хранение и вывод данных пользователю непосредственно в интерфейсах модулей (гридах) и в отчетных формах за последние 5 лет (горячее хранилище). Более старые данные можно отнести в холодное хранилище и осуществлять из выборку по запросу. 98% запросов пользователей по выборке данных относятся к текущему дню Система должна хранить в холодном хранилище данные лицевых счетов глубиной 75 лет, после чего они могут быть безвозвратно удалены в установленном порядке (указать регламент делопроизводства, стандарт внешнего Заказчика, нормативный документ и т.д.). |
4.8 Законодательные и иные ограничения | Описываются нормативные ограничения, возникающие вследствие необходимости работы с данными:
· наличие персональных данных · наличие биометрических данных · данных мед. характера · секретных сведений в соответствии с ФЗ, требующий соответствующего допуска · сведений, составляющих коммерческую тайну В случае наличия таковых данных описывается: · порядок доступа к ним специалистов Исполнителя, их допуски, режим работы на предприятии в случае командирования (пропуска, согласования допуска и т.д.) · необходимость лицензирования систем, согласования с органами исполнительной власти РФ Описывается возможность (или невозможность) получения данных от внешнего Заказчика для создания тестовых стендов, ландшафтов и Исполнителя проектных работ, процедуры обезличивания данных Описываются требования к локализации данных | Примеры: Проектируемая функциональность не содержит персональных, биометрических, мед. данных, секретных сведений. Вся информация, хранящаяся в продуктивных и тестовых системах внешнего Заказчика отнесена им к коммерческой тайне и подлежит передаче Исполнителю исключительно в обезличенном виде |
5 Отчетность
В зависимости от сложности требуемой функциональности и вообще наличия в ней отчетности (печатных форм документов, формуляров, выгрузок электронных документов, ЭДО) необходимо декомпозировать описание отчетности по крупным блокам отчетности, в некое подобие иерархической структуры, где в головные общие разделы подчинить более низкоуровневые отчеты.
Рекомендуется использовать метод классификации по функциональным областям.
Каждый конечный отчет описывается следующим составом сведений (допускается в условиях недостаточности информации описывать группы единообразных отчетов без конкретизации реквизитов каждого из них):
Тип сведений | Содержание | Примеры и особенности заполнения |
5.1 Код отчет, группы отчетов | Присваиваемый код отчета Присваивается Заказчиком. Рекомендуемый формат: REP-xxxx | Примеры: REP-1000
|
5.2 Описание | Кратко (1–2 предложения) описывается суть отчета
| Примеры: Реестр счетов-фактур Товарно-транспортная накладная Группа единообразных отчетов по расшифровке строки 1420 бухгалтерского баланса |
5.3 Вид отчета | Указывается вид отчета | Примеры: · пиксель-ориентированная типографская форма типового межотраслевого документа · утвержденная Заказчиком уникальная форма первичного документа · списочная форма, аналитическая разработочная таблица |
5.3 Источники и объемы данных | Указывается, из каких источнико�� данных собирается данный отчет В случае обращения к внешним для проектируемой функциональности источникам данных – они перечисляются (БД других приложений, витрины данных, данные внеплатформенных приложений и сервисов) Оцениваются объемы данных, обрабатываемых данным отчетом с учетом параметров, которые может задать пользователь Периодичность формирования Требования к производительности и времени выдачи результата пользователю | Примеры: Отчет собирается по данным приложения Web.УТО, обращение к внешним источникам не производится Отчет собирается с учетом динамического обращения к API ФНС в части получения сведений об актуальности контрагентов Отчет оперирует всей совокупностью данных, размещенных в сущностях «Хозяйственные операции», «Контрагенты», «Банки» Отчет формируется пользователем непосредственно в модуле «Лимитно-заборные ведомости» нажатием на кнопку тулбара и гарантированным получением ответа в течение 10 минут |
5.4 Алгоритм | Описывается алгоритм формирования отчета, его сложность Целесообразно указывать фактически реализацию отчета (модули, процедуры) в ИС «Очень старая система» или иной замещаемой системе | Примеры: · Отчет формируется как простая выборка из данных приложения с использованием языка SQL · Отчет формируется путем последовательного обсчета ячеек отчета средствами «Каталога алгоритмов»
|
5.5 Версионирование | Необходимость сохранения рассчитанных отчетных данных для дальнейшей работы пользователя | Пример: Рассчитанные данные отчета должны сохраняться в служебных таблицах системы с ведением версионирования в разрезе пользователей, доступны через пользовательский интерфейс |
5.6 Интерактивность | Описывается наличие или отсутствие интерактивности в отчете, например, проваливания; выполнения каких-либо бизнес-функций, редактирование данных | Пример: Интерактивность отсутствует, отчет формируется в виде не редактируемого pdf файла Отчет позволяет пользователю выполнять операции по аннулированию данных, отраженных в отчете, через выполнение действия «Аннулировать» (см. бизнес-функцию FE-1367) Отчет позволяет довносить непосредственно в гриде и сохранять сведения о мерах, принятых к ликвидации задолженности, построчно |
5.7 Внешний вид | Прикладываются скетчи, фотографии, образцы заполненных форм при наличии |
|
6 Интерфейсы
В этом разделе описываются требования к пользовательским и внешним интерфейсам, гарантирующим корректное функционирование проектируемой функциональности
Тип сведений | Содержание | Примеры и особенности заполнения |
Пользовательские интерфейсы | Указывается подчиняется или нет проектируемая функциональность стандартной концепции пользовательского интерфейса Платформы. Если нет – обосновываются и конкретизируются причины, по которым интерфейсы должны подчиняться другой парадигме Указываются типовые компоненты UI Kit Платформы Указываются необходимые сторонние компоненты и библиотеки для обеспечения требований Указываются приложения, модули из унаследованного ПО, которое подлежит переводу на Платформу, которое имеет интерфейсную общность с проектируемой функциональностью Указывается стороннее ПО, которое имеет интерфейсную общность для реализации эквивалентного решения Требования к производительности и времени отклика пользовательского интерфейса (если не могут быть определены для всего приложения, модуля в целом, то необходимо уточнять требования по производительности в рамках каждой бизнес-функции в разделе 3) Требования по локализации интерфейса: необходимость в каком-либо языке, отличном от русского, учет дат и времени в различных часовых поясах, форматах, символы валют, система мер | Примеры: Интерфейс проектируемых модулей подчиняется общей концепции интерфейса Платформы Интерфейс использует полный набор стандартных компонентов UI Kit Платформы Для реализации функциональности необходимо приобретение компонента Vaadin Rich Text Editor Проектируемая функциональность является преемницей функциональности подписантов в системе ИС «Очень старая система», примеры экранов см. в модуле «Настройки подписантов» Проектируемая функциональность должна в значительной степени повторять экраны и функции консоли K8s в части мониторинга состояния кластера Необходимо обеспечить наличие интерфейса всех проектируемых модулей на английском языке |
Дизайн | Макеты экранов, конкретные последовательности экраном (мастера), состав колонок гридов и т.д. не проектируются на момент оформления Шаблона – данные работы выполняются аналитиком непосредственно при оформлении ТП на проектируемую функциональность. На момент оформления Шаблона достаточно сформулировать общие подходы к пользовательским интерфейсам В случае существенных отличий от концепции Платформы целесообразно приложить скетчи с описанием таких особенностей |
|
Интерфейсы ПО | Описываются связи функциональности и других компонентов ПО (идентифицированные по имени и версии), в том числе другие приложения, базы данных, операционные системы, средства, библиотеки, веб-сайты и интегрированные компоненты. Желательно предоставлять такие сведения в виде диаграммы. Указывается назначение, форматы и содержимое сообщений, данных и контрольных значений, обмен которыми происходит между компонентами ПО. Указывается наличие или отсутствие соответствия между входными и выходными данными между системами и все преобразования, которые должны происходить с данными при перемещении между системами. Описываются компоненты Платформы (шина, ETL Clich и проч.), неплатформенное ПО, необходимое для интеграции с внешними компонентами ПО Определите данные, которыми будут обмениваться и к которым будут иметь общий доступ компоненты ПО. Для каждого интерфейса описываются требования по производительности (время отклика), меры и ограничения безопасности. |
|
7 Безопасность
В этом разделе описываются требования к безопасно��ти
Тип сведений | Содержание | Примеры и особенности заполнения |
7.1 Политики безопасности | Указывается, предполагается ли использовать стандартные средства Платформы (сервис авторизации) или нет. Указываются требования о поддержке внеплатформенных протоколов и средств авторизации при необходимости (например, по требованиям внешнего Заказчика) Перечисляются политики безопасности с приложением стандартов. Предполагается ли использование СУПД Политики аудита доступа к данным Описывается порядок авторизации при межсервисном взаимодействии различных компонентов проектируемой функциональности, а также с внешними системами
| Примеры: Разрабатываемся функциональность предполагает использование стандартных средств авторизации в Платформе с использованием сервиса авторизации, использование СУПД с ролями и наборами объектов полномочий. Необходимо обеспечить возможность аудита доступа к существенным коммерческим данным по сущности «Договоры» для документов с бюджетом более 1 млн. руб. Для внешнего Заказчика необходимо реализовать возможность соблюдения утвержденной им парольной политики (приложить правила) |
8 Документация
Тип сведений | Содержание | Примеры и особенности заполнения |
8. Дальнейшие документы | Указывается, предполагается ли оформление дальнейшей проектной документации (ТП) и т.д. | Примеры: Настоящий Шаблон является основанием для передачи в разработку, оформление детальных ТП не планируется На основании настоящего Шаблона будут оформлены ТП, макеты экранов и технические спецификации API в установленном порядке |
В чем «особенность» задач, для которых мы пишем SRS, а не ТП? Обычно — это отклонения от нашего стандартного платформенного приложения по данным (экстремально большие объемы или не-реляционное-хранение) с сопутствующими проблемами по скорости выборки и отклику для конечного пользователя, или уж совсем уникальные сервисы для внутреннего обслуживания Платформы.
Наш формат SRS довольно полон, он работает как чек-лист – аналитик не имеет права убирать из него разделы. И вот тут – хочешь не хочешь – а нужно что-то вписать в каждый пункт, тут уже работает ответственность аналитика – если он что-то существенное не описал для технических специалистов, то это - его недосмотр. Задача нашего SRS – не оставить техлидов «слепыми» при принятии решения о техническом стеке задачи, указать им на выходы за условно-стандартные рамки.
Отметим, что на основе SRS, может быть написан Частный ТП, для, например, конкретизации макетов интерфейсов, но, чаще его сразу отдают в разработку.
В рамках этой статьи мы не будем подробно рассматривать наш SRS – это довольно классический и неспециализированный документ.
Детально мы рассмотрим наш самый распространенный документ – технический проект– в последней части статьи.
Подытожим - мы осветили баланс документации и состав наших типовых артефактов. Дадим читателю еще одну передышку и перейдем к составу и деталям технического проекта в третьей части статьи.
