Без заголовка

Достаточно поглядеть на разницу между российскими и многими (не всеми, конечно) западными предприятиями. У меня подозрения, что сказки о западных предприятиях несколько преувеличены. По крайней мере у большинства корпораций, с которыми я имел дело, внутри тоже бардак, хотя и совсем другой по характеру. А всё идёт от мотивации. В Европе её ещё меньше. парсинг текстов на (возможно, псевдо)естественном языке Практически вся документация написана на псевдоестественном языке. Просто потому что формализация нужна даже тем, кто пишет. Хотя, в некоторых образцах находил по четыре нацепленных придаточных и вновьизобретённые слова, не встречающиеся в словаре. хотя подозреваю, что в ad hoc структуру для каждого отдельного проекта Вот пример одного из атрибутов требования. Вытаскивалось из текстового описания модулем на Perl. Причём ошибок было меньше десяти процентов в среднем документе и меньше тридцати в самом хреновом.

<!ELEMENT  Req          ( ... 
                          , ConfDocLst
                         ....)             >
<!ELEMENT  ConfDocLst  (ConfDoc)*       >
<!ELEMENT  ConfDoc     (PCDATA)         >
<!ATTLIST  ConfDoc
             type       (   CwUNKNOWN
                          | CwReview 
                          | CwAudit 
                          | CwDocumentation
                          | CwConcept 
                          | CwTest
                          ...
                          )             #REQUIRED
             inPhase    CDATA           #IMPLIED  >

Мне непонятно, как вы придумываете DSL Я нахожу закономерности в имеющемся тексте. Или (что случается гораздо реже) адаптирую "лучшие практики" И как потом обучаете пользователей следовать этой семантике, Обычно "Ни в коем случае не изобретайте ничего нового." А так, процесс работы идёт обычно через инженеров по сбору требований, которые и записывают результаты. Так, с вашими use cases непонятно, почему бы сразу не распечатывать plain text и не пинить те абзацы, где что-то не работает (или распечатывать каждый день новый текст, делая розовый фон для тех абзацев, где проблемы). Разные представления хороши для разных целей. UseCase - это линейное разложение графа. Когда граф представлен графом сразу видно отрубает ли ошибка боковую ветвь или блокирует основную функциональность. Тут есть еще один момент: откуда мы знаем, как шаги use case стали вдруг требованиями. Use Case и есть функциональные требования. На них накладываются нефункциональные. Но это уже другой список, элементы которого привязаны ко всему Use Case или к отдельному шагу.