Использование семантической аннотации для идентификации требований

[hazard2]

Очень не хватает разбора конкретного примера.

[darkneo]

Конкретный пример. Берем два требования:

1. «Представитель заказчика должен иметь возможность редактировать документ на этапе согласования»
2. «Руководитель подразделения должен иметь возможность изменить контрагента на этапе согласования».

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

Требование 1:
Объект: документ
Субъект: представитель заказчика
Действие: редактировать
Условие: на этапе согласования

Требование 2:
Объект: контрагент
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования

Попарно сравнивая концепты мы заметим, что совпадают 2 из 4, т.е. семантическое расстояние будет равно 0.5

Предположим, что у нас уже реализовано третье требование: «Руководитель подразделения должен иметь возможность изменить телефон контрагента на этапе согласования».

Здесь видно, что телефон контрагента имеет отношение к контрагенту (телефон является частью сущности контрагент, по большому счету), то между этими концептами можно установить степень «похожести» 0.5 (установим экспертным путем). Рассчитаем семантическое расстояние:

Требование 3:
Объект: телефон контрагента
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования

Оно равняется 0,875

Видим, что требования 2 и 3 более близки, чем требования 1 и 2. Когда реализованных требований больше трех уже можно выбирать, какую реализацию допиливать до нужного функционала.

[Nashev]

Вот ещё б система подсказывать могла, что во втором требовании не указано, о согласовании чего идёт речь («документа»), а в первом — не уточняется что именно в документе править нужно…

[darkneo]

Можно увеличить количество категорий для описания — тогда оценка будет еще более точной.

[naething]

Судя по отсутствию комментариев, никто не понял, о чем этот топик. Я тоже не понял. Стиль изложения скорее не академический, а «наукобразный». Или Вы под текстом в академическом стиле подразумеваете тот, который никто никогда не дочитает до конца? Лучше бы привели конкретный пример. Без него все это выглядит игрой слов и притянутой за уши математикой.

И вообще какая-то каша:

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

Как будто без объектно-ориентированного программирования невозможно повторное использование кода.

[darkneo]

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

[darkneo]

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

[john_smith]

В целом понятно, что хотел сказать автор. Вводим веса, коэффициенты разные, метрику задаем и ищем похожие требования. Математика тут самая простая, на уровне интуитивно понятных определений. Как я понял данные мысли существуют только «на бумаге». Т.е. на сегодняшний день «живых» систем, реализующих инициализацию всех доменов, концептов и т.д., а также дальнейший поиск по описанной схеме, нет в природе? Хотелось бы поинтересоваться, какие у автора доводы в пользу эффективности представленной методики кроме теоретических?

[Nashev]

Ну оооооочень хочется поругать за «академический стиль изложенния»!

[darkneo]

Можно поругать. В комментах. =)

[Nashev]

Вроде ж в постскриптуме Вы просите об обратном ;)

Я лучше в очередной раз на Нору Галь сошлюсь, она с этого свою книжку начинала. Вот.

[darkneo]

Да, ругать нельзя. Но если очень хочется, то можно =)

[Nashev]

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

Хотя, подозреваю, чисто по человечески нереализуема, пока не будет автоматизирована. А единственная возможная здесь автоматизация — это машинное чтение и интерпретация обычных ТЗ, написанных человеческим языком. Что само по себе и так даст семантическую сеть, и автоматическое сравнение/узнавание…

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

[ddespot]

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

Сейчас мы используем только самую примитивную семантику, типо обработки текста после слова (поиск) как запроса и выдача списка документов по внутренней базе маркированным списком. Аналогично слова (задача), имя пользователя. В общем на уровне инструкций, но не требований. И нам и этоу уже очень нравиться.

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