Я провел достаточный анализ и использовал ряд инструментов для сбора требований: созданные пользователем раскадровки, варианты использования, чертежи графического интерфейса, прототипы графического интерфейса, пользовательские истории и сценарии, которые могут использоваться в качестве критериев приемлемости и т. д.
Хотя каждый из них имеет более или менее достоинства, я думаю, что есть один отсутствует важный бит. Эти методы могут точно фиксировать, как пользователь взаимодействует с вашим приложением., но программист должен создать и разработать «модель», которая должна быть отражена в коде.
В последнее время я читал DDD Эвана , и он предлагает нечто иное. Вам необходимо создать модель предметной области вместе с экспертом предметной области и поделиться ею с ним. Чтобы передать идеи пользователю, в книге он часто использует специальные рисунки, вдохновленные UML.
Интересно, это лучший способ поговорить о модели с экспертом в предметной области. Существуют ли какие-либо другие инструменты, помимо диаграмм UML, которые вы могли бы использовать для сбора знаний в предметной области и использования их при обсуждении предметной области со своим экспертом в предметной области?