Для показа сравнения СУТ можно взять список критериев и показать как это делается на любом примере:
http://www.paper-review.com/tools/rms/read.php

Также можно надергать основных фич СУТ из этих Д:
http://wiki.eclipse.org/Requirements_Statement#Additional_suggestions

Коллеги,

Ну вроде бы все согласны сделать Семинар по предложенному выше плану.
Давайте сделаем:
1. Проведем в апреле Семинар в Москве по 3ем Инструментам
2. Проведем 3 мастер-класса по Инструментам в Минске + после круглый стол по обсуждению

Тем самым Вы обкатаете мастер-классы на семинаре и выступите удачно в Минске.

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

Согласная я, только желательно в конце апреля семинар. У меня ожидается большая запарка на работе на апрель :-(

Ураааааааа, со всеми Докладчиками согласована дата семинара - 9 апреля 2009 года.

Теперь ждем от Иры список Фич, по которым будут показаны инструменты. Далее здесь этот список согласуем.

Вот составил первоначальный набор Фич, которыми должен обладать СУТ. Просьба добавлять\уточнять.
Также прикладываю скрин ментальной карты Функций СУТ и выгрузку пакета из Sparx EA.

Функции СУТ:
1. Сбор Требований
В вод Атомарных Требований                         
Богатое форматирование Текста                     
Загрузка Требований из Файла                     
Шаблоны описания Требований                       
Автонумерация Требований                         
2. Анализ Требований
Формирование структуры проекта                   
Классификация Требований                         
Трассировка Требований                           
Анализ влияния                                   
Анализ покрытия                                   
Трассировка к элементам модели и коду             
Отчетность по требованиям                         
3. Документирование Требований
Наследование (заново использование) Тр           
Поддержка форматов файлов для вывода             
Настройка шаблонов вывода Документов             
Шаблонный вывод Документов                       
4. Проверка Требований
Проверка орфографии                               
Нахождение дупликатов и зависимостей             
5. Управление Требованиями
Атрибуты Требований                               
Версионность Требований                           
История изменения Требований

Богатое форматирование текста - это зачет (по моему мнению форматирования надо не так уж и много)

Формирование структуры проекта  - что под этим подразумевается?

Анализ покрытия - чего покрывали то??

Саш, тут в соседней теме делали требования ИС Аттестации или как то так.

Почему не выделить такую же тему и решать задачу по описанию требований к идеальной СУТ там?

P.S.
где работа с Use Cases и сценариями?
где глоссарий?
если закладываемся на трассировку к элементам модели и кода, то где трассировка к тестам

Богатое форматирование текста - это зачет (по моему мнению форматирования надо не так уж и много)

Но оно нужно! Предложи тогда перевод - Rich Text Editor

Формирование структуры проекта  - что под этим подразумевается?

Это возможность формирования различных подразделов (Глоссарий, Цели и т.д.) и возможность формирования иерархической структуры

Анализ покрытия - чего покрывали то??

То что мы все вышестоящие требования покрыли в более детальных Требованиях.

Саш, тут в соседней теме делали требования ИС Аттестации или как то так.
Почему не выделить такую же тему и решать задачу по описанию требований к идеальной СУТ там?

Так тут как раз говорим о тех ф-ях, которые ребята будут демонстрировать в своих Инструментах.

где работа с Use Cases и сценариями?
где глоссарий?
если закладываемся на трассировку к элементам модели и кода, то где трассировка к тестам

1. Имелось в виду в п. "Шаблоны описания Требований", т.е. сценарный шаблон для ВИ. Что-то еще нужно для ВИ в СУТ?
2. А что нам нужно специфического для Глоссария? Кроме отдельного структурного раздела?!
3. Согласен. Трассировка к другим артефактам Разработки (Элементы модели, код, тесты и т.д.)

надо каждый пункт из твоего списка немного детализировать или описать словами, а то появляются вопросы.
(хотя может это я такой)

Дословный перевод с английского это зачастую смешно

по поводу покрытия: тогда в чем разница между трассировкой и покрытием?

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

еще по поводу требований к сут
- инструмент обсуждения требований с сохранением истории

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

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

Тогда нужно выбрать наиболее хорошо реализованные функции в СУТ, а по остальным сказать - есть или нет.

Лично меня сейчас очень интересуют вот такие функции инструмента управления требованиями:

- возможность представления "срезов" по определённой функциональности (пример: представить на одной странице всю информацию о требованиях к операции "отмена платежа");

- множественные представления одного и того же требования для разных условий - клиентов, проектов (пример: есть один "общий" вариант чека операции "продажа" и его модификации для отдельных клиентов);

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


Кроме того, интересно посмотреть на реализованные модели жизненного цикла требований (перечень и диаграмма статусов), насколько они гибки и адаптируемы к разным типам проектов и ролей.


Трассировка лично у меня ассоциируется с автоматическим изменением статусов: поменял какое-то требование, и это изменение автоматически отразилось на всех связанных объектах (зависимые требования, тест-кейсы).


Сам я в СУТ не силён пока. Постараюсь до семинара освоить OSRMT, чтобы было от чего отталкиваться (собственно, я уже начал).

Разослал всем Докладчикам ссылку на список фич СУТ. Вроде бы первое приближение получили. На основании выше и лично сказанного подправлю описание Фич и более полно раскрою каждую. К среде должны получить список, на который и должны ориентироваться Докладчики.

Решили заключение Семинара сделать таким:
1. Делаем на доске табличку где по горизонтали идут список Фич, а по вертикале СУТ. По мере доклада Модератор ставит оценку на пересечении каждой Фичи и СУТ. В конце подводим формальный итог.
2. Далее делаем голосование Слушателей - кому какая СУТ больше понравилась и делаем второе Заключение.
3. Если останется время, то Слушатели задают вопросы докладчикам.
4. Все заканчивается миром, дружбой и жвачкой.

Формальная оценка СУТ
К среде мы формируем список ФИЧ, которым должна удовлетворять СУТ, с кратким описанием. На семинаре Докладчик демонстрирует наиболее характерные Фичи для данной СУТ и Модератор проставляет - или + или +\- или ++ на пересечении Фичи и СУТ в таблице. Если Докладчик не успел показать какие-то фичи, то за 5 минут мы проходим по оставшимся и ставим + или - на против этих Фич на основании знаний Докладчика.
Система оценок:
"-"    - СУТ не поддерживает Фичу
"+\-" - СУТ поддерживает Фичу, но не в полном объеме*
"+"    - СУТ поддерживает Фичу в полном объеме*
"++"  - СУТ поддерживает Фичу в полном объеме*, да и еще что-то добавляет сверх описанного в Фиче.
* объем определяется описанием фичи и субъективной оценкой Модератора

Фуф, вроде все

Поддерживаю такую схему!
Осталось определиться, кто будет Модератором.
Ну и кто предоставит жвачку для концовки :-)

Открыта регистрация на Семинар Системы Управления Требованиями.