Да, вы расскажите пожалуйста, что именно на вас наваливается.

На данный момент меня интересуют механизмы быстрой формализации предметной области.

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

Других способов для решения этой проблемы кроме использования того же ИИ я не вижу.
 

На данный момент меня интересуют механизмы быстрой формализации предметной области.

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

Других способов для решения этой проблемы кроме использования того же ИИ я не вижу.

Согласен, что задача автоматизации разбора документов важная и нужная.

Напомню, что есть инструменты, которые уже много лет помогают в ручном разборе (например, избавляют от копипаста и помогают контролировать проход по документу), типа https://www.visual-paradigm.com/tutorials/textualanalysis.jsp

Я бы предложил не ждать милостей у природы, а самим взять их у неё.
В смысле, например, разработать плагин для Google Docs, который будет делать базовый разбор текста.
Найдётся у вас время для такой работы?

Напомню, что есть инструменты, которые уже много лет помогают в ручном разборе (например, избавляют от копипаста и помогают контролировать проход по документу), типа https://www.visual-paradigm.com/tutorials/textualanalysis.jsp

Спасибо за ссылку. Идея отличная, но не уверен, что она получила широкое практическое применение. Вообще не вижу перспектив за продуктами типа confluence и плагинов к нему. Это безусловно лучше, чем word, но все равно не заменит "тяжелой" технологической системы.   

А такие мелкие сервисы типа вышеописанного очень капризны к качеству подготовки текста, установлению связей с другими такими текстами. Не очень понятно, как скажем при появлении второго документа заставить использовать элементы из репозитория?

Я бы предложил не ждать милостей у природы, а самим взять их у неё.
В смысле, например, разработать плагин для Google Docs, который будет делать базовый разбор текста.

Разбор текста для чего? Лексических и семантических анализаторов как собак нерезанных. Писать их в научном плане крайне приятно - лет двадцать тому назад так приятно было свои языки и компиляторы писать. Один из наиболее качественных анализаторов  у ABBYY например. Поставляются они и в виде готовых решений, и библиотек. Так что средств, которые могут хапнуть кучу документов, расчитатать по ним семантические метрики, откластеризовать и построить разного вида представления, характеризующие семантические связи по этим документам как грязи. Вопрос в том, как это провязывать к технологической системе. Так что к проблеме надо заходить со стороны СУТ. Причем такой тяжелой и правильной типа Cradle.

Самое обидное, что тот же 3SL двинулся во вполне правильном направлении в Loader. Они word файлы распаковывают, а xml пишут в базу. То есть разобранный документ они из базы обратно легко восстанавливают в первоначальном виде (что кстати довольно прикольно - родной микрософтовский sharepoint хранит вордовые файли как бинарные обьекты и попыток не делает их распаковать и проанализировать, хотя я думаю можно было бы с этого разные сервисы приятные поиметь) . Но при этом лексической единицей у Loader остается абзац - по вордовому форматированию Loader устанавливает иерархию этих абзацев, а в итоге иеррархию требований.

Соответственно сравнивая абзацы новых вернсий документов Loader понимает изменение требований. Но например в случае, если это не просто новая версия документа, а другой документ из той же ПО, но по другому оформленный,  понимаение изменений  возможно только в ручном режиме.

А вот если иметь семантический граф или онтологию, то понимание изменений возможно даже на неоднородных источниках   

Ну, да. Программисты случайно техподдержке не перепоручили техподдержке потренироваться в кодинге?

Вряд ли. На них "вертикаль власти" заканчивалась.

Ну чтобы совсем определиться с тем, насколько вредно знание инструментальных средств для начинающих аналитиков.

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

А джира какое имеет отношение к инструментарию аналитика? Это багтрекер - инструмент техподдержки. Может даже инструмент управления требованиями, но уж никак не их разработки.

Вы спросили, Вы ответили.

Не годятся примеры совсем. Был бы это пример аналитика, умеющего прекрасно строить IDEF0 в bpWin, но абсолютно не понимающего в анализе...

И такое встречалось. UMLки рисовал - заглядение, но вот смысл их был крайне мутным. Без доработки напильником обычно не обходилось. Зато прекрасно знал назначение каждой закорючки и штришка в языке. Куда лучше меня.

Просто пришло уже такое время, что без инструментария можно только совсем примитивными проектами заниматься.

Ну, значит я реликт. Со своим вордом, блокнотом и джирой(иногда). Проекты-то не сказать, чтобы примитивные.

Думаю в ближайшее время уровень СУТ может выйти вообще на принципиально новый уровень, так как именно СУТ является идеальной площадкой для применения искусственного интеллекта.

СУТ - это система управления требованиями? Так она же к инструментарию аналитика вообще и разработке требований в частности отношения не имеет? (с)

по сути разработка сведется к согласованию онтологий предметной области и разрабатываемой системы.

И все, аналитиков можно из проектных команд исключать.
Я примерно такие же слова уже лет 15 слышу в отношении автоматической генерации кода. С периодической демонстрацией какого-нибудь суперинструмента. Но пока все так, как есть.

Других способов для решения этой проблемы кроме использования того же ИИ я не вижу.

Ну... Некоторые чудаки все еще используют ЕИ. Естественный, в смысле.

Разбор текста для чего?

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

Например, из строки «Индвидидуальные предприниматели, ведущие деятельность на основании патента, обязаны сдать отчётность в срок не позже 4 мая текущего года» можно вытащить автоматически в словари-таблицы:
1. Субъект с уточнением — "ИП, ведущий деятельность на основании патента"
2. Объект — "отчётность"
3. Правило поведения — "сдать"
4. Правило-ограничение поведения — "до 4 мая"
5. Связка = 1 + 2 + 3 + 4
Потом можете эти словари загрузить куда угодно, т.к. первичный разбор сделан.

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

Например, из строки «Индивидуальные предприниматели, ведущие деятельность на основании патента, обязаны сдать отчётность в срок не позже 4 мая текущего года» можно вытащить автоматически в словари-таблицы:
1. Субъект с уточнением — "ИП, ведущий деятельность на основании патента"
2. Объект — "отчётность"
3. Правило поведения — "сдать"
4. Правило-ограничение поведения — "до 4 мая"
5. Связка = 1 + 2 + 3 + 4
Потом можете эти словари загрузить куда угодно, т.к. первичный разбор сделан.

Не готов дать экспертизу, но это сильно отличается от обычного применения анализаторов (по крайней мере то, что видел я). Судя по примеру, текст далеко не естественный, нам нужно уметь отличать эти самые уточнения, понимать, что это не просто какие-то буковки, а "правило-ограничения"....

Обычно результаты семантического анализа выглядят по другому. То есть анализаторы найдут  и выделят текстах:

ИП,деятельность, основания ,патент,отчетность, май

выделят отношения

ИП-деятельность -> вести
ИП-отчетность -> сдавать

итд

А что если нам что-то типа круглого стола организовать с ИИшниками, чтоб нам спецы рассказали, что можно, а что нельзя ?

"Возможности применения семантического анализа для неструктурированных описаний и онтологического анализа для структурированных описаний  требований"


   

Вряд ли. На них "вертикаль власти" заканчивалась.

Я где-то утверждал, что знание инструментария вредно? Если нет - зачем Вы это пишете?

Ну и я не утверждал, что главное - инструмент, пофигу методики.

На всякий случае еще раз: вредно ставить изучение инструментария впереди собственно аналитической работы.

Это абсолютно нормальная последовательность:

1) Изучение инструмента
2) Выполнение аналитической работы с помощью инструмента

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

Но это совсем не значит  , что я считаю, что на методики надо забить. Они точно такой же инструмент, технология его использования.

Ну, значит я реликт. Со своим вордом, блокнотом и джирой(иногда). Проекты-то не сказать, чтобы примитивные.

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

СУТ - это система управления требованиями? Так она же к инструментарию аналитика вообще и разработке требований в частности отношения не имеет? (с)

Ну вот....Восстанавливаем:

А джира какое имеет отношение к инструментарию аналитика?

Может даже инструмент управления требованиями, но уж никак не их разработки

Из этих утверждений не следует:
1) Что джира является СУТ (утверждается , только что джира может использоваться для управления требованиями, но не утверждается, она является системой управления требованиями. Так же как не является СУТ ваш блокнот, хотя используя его, Вы вполне можете разрабатывать и управлять требованиями)
2) Что в любой СУТ обязательно должен отсутствовать механизм разработки требований. И EA, и Cradle это наглядно   опровергают - и там , и там есть механизмы как разработки требований, так и управления ими.

Так что если и (с), то не мое.

И все, аналитиков можно из проектных команд исключать.
Я примерно такие же слова уже лет 15 слышу в отношении автоматической генерации кода. С периодической демонстрацией какого-нибудь суперинструмента. Но пока все так, как есть.

Позвольте не согласится с Вашим argumentum ad antiquitatem. У программистов сейчас не так , как было 30,20,10 лет назад. Их производительность труда по сравнению с программированием на машинных кодах сильно выросла, а появление новых инструментов не  привело к исчезновению их профессии, а просто повысила уровень требований к создаваемым ими системам. И с аналитиками и инструментарием для них тоже самое.

Ну... Некоторые чудаки все еще используют ЕИ. Естественный, в смысле.

Опять же ИИ не предназначен замены ЕИ, а предназначен прежде всего для его усиления, для решения тех задач , которые ЕИ решить может и не в состоянии.

Ой, чтота мне бухгалтера 80х вспомнились с арифмометрами и счетами...

2 Humbert
Этап выявления в проекте идет всегда вообще самым первым и базируется на большим количестве методик. Именно методики, а не инструменты рулят на этом этапе. 

Вы первый этап какого процесса имеете в виду? Создания ИС или информационного обследования? Если создания ИС , так собственно инструменты аналитика в своем большинстве на первом этапе и используются. В BPMN строим процесс, выявляем требования назначения и делаем описание обьекта автоматизации, в IDEF0 выявляем и фиксируем функциональные и нефункциональные требования. Ну и без инструментов разве только выявление целей и задач инструментов особых не требует, а все остальное совершенно незачем рисовать на ватманах...

Ну и без инструментов разве только выявление целей и задач инструментов особых не требует, а все остальное совершенно незачем рисовать на ватманах...

И тут есть мозговой штурм, вские брейнрайтинги,дерево целей, морфологически ящики Цвикки, диаграммы Исикавы, приницпы Парето и всякие приемы типа CATWOE и Н-метода, опять же Гольдратт с его подходами. Или это не считается инструментом?

Ну и я не утверждал, что главное - инструмент, пофигу методики.
Это абсолютно нормальная последовательность:

1) Изучение инструмента
2) Выполнение аналитической работы с помощью инструмента

Тем не менее, в нормальной последовательности им (методикам) места не нашлось.

Но это совсем не значит  , что я считаю, что на методики надо забить. Они точно такой же инструмент, технология его использования.

Нет, не такой же. Вести осмысленную аналитическую работу с методиками, но без крадла можно, а вот наоборот - нет.

Леонид, мне кажется Вы кокетничаете.

Какие же деликатные собеседники на форуме. Я бы по-другому сказал. )

Но примите во внимание, что Вы как специалист в другое время складывались. Специалист, который сейчас захочет расти , используя только блокнотик, в профессии может и не остаться. 

Равно как и тот, который использует все известные инструменты сразу.

Из этих утверждений не следует:
1) Что джира является СУТ (утверждается , только что джира может использоваться для управления требованиями, но не утверждается, она является системой управления требованиями.

Хех... То, что может использоваться как СУТ и используется как СУТ, скорее всего СУТ и является (как минимум, в рамках проекта). Что там в других местах - какая разница?
Гаечный ключ молотком де юре не является, но при должном энтузиазме и при отсутствии под рукой молотков, де факто очень даже.

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

Соглашусь. Сейчас практически любой программист может "печатать со скоростью 1000 знаков в минуту". Многие доказывают это на практике.

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

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

И с аналитиками и инструментарием для них тоже самое.

Работа аналитика сильно отличается от "механистической" работы программиста. В последнем случае влияние инструментария гораздо важнее (хотя и не всегда имеет решающее значение). Так что "то же самое" не получится.

Опять же ИИ не предназначен замены ЕИ, а предназначен прежде всего для его усиления, для решения тех задач , которые ЕИ решить может и не в состоянии.

Вот так звучит гораздо лучше, чем в посте, где "Других способов для решения этой проблемы кроме использования того же ИИ я не вижу."

Ой, чтота мне бухгалтера 80х вспомнились с арифмометрами и счетами...

Не зря вспомнились, кстати. Имеют прямое отношение к обсуждаемому вопросу. Те бухгалтера ан масс гораздо лучше понимали суть проводимых операций, чем сегодняшнее "поколение 1С". Хотя "поколение 1С" может нашлепать куда больше проводок за единицу времени даже не приходя в сознание. С точки зрения бизнеса это хорошо: нужные операции проводятся, а кнопкодавы стоят дешево и меняются легко и непринужденно. Но вот вырасти в главбуха у ортодоксального кнопкодава шансов никаких.

В какую неожиданную сторону развилась тема!
Про ИИ хочу добавить (не в рамках рекламы, а в качестве распространения информации от IEEE):
В рамках 24th IEEE International Requirements Engineering Conference Sept. 12–16, 2016, Beijing, China (http://www.re16.org/)
состоится
Monday, September 12th, 2016:
WS01. AIRE: 3rd Intl Workshop on Artificial Intelligence for Req. Eng.
      http://re.cs.depaul.edu/aire16/
Вероятно, если покопаться, то можно найти материалы предыдущих workshop'ов. В принципе, в рамках RE предыдущих годов возникали доклады на эту тему, если реально будут желающие, могу попробовать найти.

WS01. AIRE: 3rd Intl Workshop on Artificial Intelligence for Req. Eng.
      http://re.cs.depaul.edu/aire16/
Вероятно, если покопаться, то можно найти материалы предыдущих workshop'ов.

Увы,не удалось обнаружить докладов предыдущего workshop'а.
 
Вообще судя по темам  есть ощущение, что пока дело до конкретных реализаций применения ИИ в RE  не доходит.   

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

Было бы замечательно. Вообще спасибо за ссылкы - даже не подозревал о наличии такой организации.

в рамках RE предыдущих годов возникали доклады на эту тему

Да, очень интересно. Но текстов докладов тут вроде нет, только программы:
2015
2014

Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html

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

Само пошутило, само поржало. 
Небезызвестный Kirill Fakhroutdinov считает, что это " typical misconception", что я перевожу на язык тутошней планеты как "популярные грабли".

Кто в этот раз напишет "+100500 к граблям"? Вопрос риторический.