Эд ... по целям и задачам. Цель имеет не столько ограничения, сколько численные критерии -- "Улучшить, ускорить, углубить :-), ... сократить, ..." и т.п. и желательно знать НАСКОЛЬКО увеличиваем/сокращаем, и в каких попугаях измеряем. Цель по аналогии с тем же outmost use case. Т.е. если ставим *типа* цель -- "выбрать тул для <чего-то>", то еще можно задать вопрос "а почему нам нужен тул"? ... вполне возможно, что при ответе на этот вопрос мы сможем сформулировать таки действительно цель -- что-то вроде "сокращения сроков/трудоемкости/ ... при разработке проектов ПО". Другой вопрос -- когда у нас есть иерархия целей, и мы говорим о достижении какой-то промежуточной цели, ... но в этом случае имеет таки смысл приводить всю иерархию. Можно ли говорить про то, что целью является приобретение некоего свойства/возможности, которой раньше не было? Думаю да ... например вполне себе цель "стать обеспеченным человеком с доходом не менее N килобаксов в месяц", если мы, предположим, не можем дать ответ на вопрос "почему необходим именно такой доход?" :-).
Далее, про процессы. RUP и иже с ним -- это очень общие процессы, как ты понимаешь, более того это фреймворки процессные, чем именно процессы. Более интересен ответ на вопрос не о поддерживает RUP или нет наш тул (ибо это слишком абстрактно), а сформулировать более детальный инстанс процесса (как именно и какие строим модели, как проводим управление изменениями с конкретным планом конфигуправления в этой части и с сущностями которыми мы при этом оперируем, как планируем и НА ОСНОВАНИИ ЧЕГО, что является единицей планирования, как учитываем результаты работ, какую именно технологию создания артефактов используем -- формальные документы по ГОСТ и т.п. или достаточно неформального вэб-сайта по проекту ...). Вот именно в разрезе такого детализированного инстанса процесса и интересно рассматривать использование инструментария. Отсюда же и критерии берутся. Посему ЛЕГЧЕ строить доклад в форме "МЫ РАБОТАЕМ ВОТ ТАК (описываем детали процесса и требования к артефактам) и используем вот такой набор инструментов для <того-то>. Таким-то образом автоматизирован наш процесс. При этом вот эти части процесса на ура автоматизируются, а это приходится делать наполовину вручную. Отсюда выводы ... если ваш процесс близок к описанному -- одна ситуация, если у вас вот такая и такая вариации -- то могут быть такие и такие траблы ... ". Думаю что в таком формате легче провести доклад и он будет легче воспринимаем. Альтернатива -- четкий, формальный набор критериев и методика оценки. На мой взгляд, второй вариант требует больше усилий. Если формат доклада будет таким как я говорил, не забудьте упомянуть меня "в благодарностях за оказанную поддержку" на слайдах доклада :-)))))).
[Семинар] - Альтернативные системы поддержки процесса разработки ПО (МСК)