Есть разные подходы к ведению требований к ПО: одни пишут полноценные сценарии использования, другие выбирают пользовательские истории, а третьи — вообще избегают формализации требований, считая это пустой тратой времени.

Но я так не считаю. Формализация — большой и важный этап разработки требований. В статье об этом расскажу: как происходит ведение требований у нас, какие этапы мы проходим, каких правил придерживаемся и что будет, если отклоняться от правил. Если вы системный или бизнес-аналитик, владелец продукта или просто работаете с требованиями к программному обеспечению, то эта статья для вас.

https://habr.com/ru/post/694864/?utm_source=habrahabr&utm_medium=rss&utm_campaign=694864

Всем привет, мы – Таня и Лиза, системные аналитики в МТС Банке, работаем над мобильным приложением и сайтом для физических лиц. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашем банке.

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

Добро пожаловать под кат!

https://habr.com/ru/post/686570/?utm_source=habrahabr&utm_medium=rss&utm_campaign=686570

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

Бизнес процесс описывает смену состояний бизнес-системы.

Бизнес-система – это логическая система, элементы которой связаны между собой отношением причинно-следственной связи, реализуемой через функции.

Функции причинной связи являются свойствами бизнес-системы.

Люди – члены организации, реализующей бизнес-процесс, составляют управляющую систему по отношению к бизнес-системе.

Управляющая система, состоящая из людей, является физической системой, и ее нельзя смешивать с бизнес-системой, которая является логической.

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

Программный комплекс – это логическая система.

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

Для проектирования программного комплекса необходимо построить информационную модель бизнес-системы.

BPMN не позволяет построить информационную модель системы, а лишь создает правдоподобную на первый взгляд имитацию модели.

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

Вместо BPMN и других графических нотаций бизнес-процессов для моделирования бизнес-систем лучше пользоваться такими понятиями как: информационный элемент, информационная совокупность, класс, атрибут, состояние, условие, функция.

https://habr.com/ru/post/681262/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681262