функция — это преобразование входа в выход

если у вас дома есть питьевая вода, то через какой канал она пришла — это уже не функция, а решение/ограничение

ограничение — если заказчик задаёт его сразу

решение (decision) — если его принимает создатель решения (solution)

Но это не техническое решение все же. Вопрос того, к какому количеству международных GDS подключаться - это же не ТР. И то, что подключаться будем именно к SU и S7, но не будем к нордвинду с якутией - тоже не ТР

«Каждый клиент мнит себя инженером (а иногда не мнит, а является ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать требования стейкхолдера, а также требования к системе, но обязательно попытается сформулировать конкретные инженерные решения “прозрачного ящика” (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование).

Формально высказывания о “прозрачном ящике” не называются требованиями, поэтому некоторые авторы предлагают называть их “ограничениями” (свободы творчества инженерной команды). Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования. И если придуманное вами инженерное решение лучше того, которое требует клиент в своих ограничениях, попытаться убедить клиента снять эти ограничения. Но нужно понимать, что иногда эти ограничения отражают какой-то опыт клиента, неизвестный команде, или они появляются из неинженерных (политических, финансовых, логистических и т.д.) соображений. Поэтому по поводу ограничений нужно каждый раз понимать, почему они были прописаны, почему клиент без них не может обойтись (см. GORE).»

Разложите по уровням:
1. Бизнес
2. Пользователь
3. Техника
будет понятнее, сейчас у вас всё вместе.

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

"Сайт должен позволять" — это не БТ

Уровень требования определяется предметом требования

БТ — Бизнес должен ...

ТрСт — Роль должна ...

Требование к решению / системе — Решение должно ...

детальные функции решения могут появляться в ходе проектирования взаимодействия. обычно это этап техпроекта / разработки ТЗ на ПО (а не систему/решение)

распечатать билет вообще не входит в границы пользовательской задачи "купить билет"

проектировать взаимодействие и прописывать детальные функции ПО очень нужно и полезно при его проектировании с 0, но опасно, если вы будете выбирать готовое решение

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

спасибо. так понятнее, о чем речь

Господа ) Доброго дня
интересует вопрос преобразования ФОРМАТА *.BPMN в XML

Инструментарий (желательно ФРИ) и флоу конвертации

bpmn и есть xml

СПАСИБО!!!

фоточки такие, как будто никакого 19-го и в помине нет https://www.facebook.com/media/set/?vanity=analystdays&set=a.3516451441726515