Уважаемые форумчане, 
по работе появилась необходимость разобраться с управлением требованиями, но тема для меня новая, помогите пожалуйста разобраться.
Читаю Вигерса "управление требования к ПО" и не все понятно. В указанной книге есть следующая схема http://iiba.ru/wp-content/uploads/2013/04/requirement_types.jpg. Собственно вопросы по ней
1. В книге сказано "Спецификация требований к ПО может представлять собой отчет, сгене-
рированный на основе информации, хранимой в средстве управления тре-
бованиями." т.е. это сводный документ который содержит множество требований. Пример и структура этой спеки в книге есть. А что из себя тогда представляют сами отдельные требования (например функциональные, требования к интерфейсам...). Какая структура у них? Из каких частей отдельных требований формируется "Спецификация требований к ПО"? Как это выглядит в промышленных RMS?
2. Что из себя представляет документ "Документ о вариантах использования" (в моем бумажном экземпляре книги этот документ называется "Документ пользовательских требований"). Для кого он предназначен? Можете ткнуть в пример такого документа?.
3. Правильно понимаю, что в общем случае документы "Документ об образе и гарницах", "Документ о вариантах использования", "Спецификация требований к ПО" заменяют ТЗ (если например заказчик не настаивает именно на ТЗ)?

PS если мое сообщение не по профилю ветки, скажите куда правильно перенести, я пока в структуре форума не совсем разобрался.

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

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

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

Уважаемые форумчане, 
по работе появилась необходимость разобраться с управлением требованиями, но тема для меня новая, помогите пожалуйста разобраться.
Читаю Вигерса "управление требования к ПО" и не все понятно. В указанной книге есть следующая схема http://iiba.ru/wp-content/uploads/2013/04/requirement_types.jpg. Собственно вопросы по ней
1. В книге сказано "Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями." т.е. это сводный документ который содержит множество требований. Пример и структура этой спеки в книге есть. А что из себя тогда представляют сами отдельные требования (например функциональные, требования к интерфейсам...). Какая структура у них?

Типовая структура требований выглядит как "Система должна … <утверждение о необходимом функциональном поведении системы>" или "система должна позволять … <утверждение о возможности, предоставляемой пользователю или внешней системе>. Например:

"Система должна вести журнал всех действий пользователя" или
"Система должна позволять создавать новые Проекты".

Из каких частей отдельных требований формируется "Спецификация требований к ПО"?

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

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

Как это выглядит в промышленных RMS?

Зайдите на сайт любой промышленной RMS и ознакомьтесь с демо-материалами. Если не найдёте — спросите у них. Там есть специально обученные люди, которые получают за это зарплату, чтобы вам было всё понятно.

2. Что из себя представляет документ "Документ о вариантах использования" (в моем бумажном экземпляре книги этот документ называется "Документ пользовательских требований"). Для кого он предназначен? Можете ткнуть в пример такого документа?.

И снова я не понимаю. У Вигерса же есть пример такого документа в книге? Вы его видели?

3. Правильно понимаю, что в общем случае документы "Документ об образе и гарницах", "Документ о вариантах использования", "Спецификация требований к ПО" заменяют ТЗ (если например заказчик не настаивает именно на ТЗ)?

Для ПО — да, заменяет. Только "Образ и границы проекта" ближе к документам "устав проекта" и "концепция ПО", чем к ТЗ.

Кроме того, важно понимать, что в российской практике часто делают не ТЗ на проектирование ПО (чему соответствует спецификация требований к ПО), а сразу ТЗ на разработку ПО. Т.е. уже после разработанной архитектуры ПО описывают не только внешние функции, алгоритмы и атрибуты качества, но и состав компонентов и взаимодействие между ними. (Я такой подход не применяю, т.к. он повышает риски натягивания решения на технологию).

Добрый день!
Денис, благодарю за ответ!
Попробую переложить вопросы на пример. Общее описание - создается некоторая система. В этой системе оператор должен выполнять множество действий, возьмем пока
одну из задач - регистрация клиента.
В процессе регистрации оператор
- печатает форму договора которая передается клиенту для заполнения,
- вносит в систему данные о клиенте - ФИО, адрес, семейное положение и тд.д.
- а так же выполняет сканирование документа клиента и данный скан прикрепляется к карточке клиента.
Теперь это попробую разложить в виде требований и документов как я это вижу. Вопросы по тексту.
Цели проекта пока опущу. Начинаем с пользовательского требования.

1. Пользовательское требование -
Идентификатор: ПТ1.
Заголовок: - Регистрация клиента.
Описание:
система должна обеспечивать возможность зарегистрировать нового клиента.
Вопрос1. Нужно ли тут расписывать полностью все действия описанные в шапке
-1.1.печать договора,
-1.2. сканирование документа клиента...?
- 1.3.нужно ли описывать тут состав данных которые оператор вносит в систему?
Т.е. например так "в процессе регистрации оператор должен распечатать форму договора и переадть её для подписи клиенту.
Оператор должен отсканировать паспорт клиента и данный скан сохранить как приложение к карточке клиента, внести в систему данные - ФИО.."?

Диаграмма процесса:
Например есть диаграмма процесса она прикрепляется к данному требованию.

Вопрос 2. Требование к форме отчета "Договор клиента" это отдельное требование?

2. Создается требование к внешнему интерфейсу (интегарция со сканером)
Идентификатор: ИНТ1.
Заголовок: - Интеграция со сканером.
Описание:
система должна обеспечивать возможность получить копию документа клиента со сканера. Для этих целей необходимо обеспечить
взаимодействие системы со сканером <Модель>.
Схема взаимодействия
<тут размещаем схему>

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

Описание протокола взаимодействия
<длинное описание протокола взаимодействия со сканером>

3. Теперь формируем функциональное требование на выполнение пользовательского требования регистрации клиента
Идентификатор: ФТ1.
Заголовок: - Регистрация клиента.
Для выполднения сценария регистраии клиента неоходимо реализовать соледующие функциональные возможности
<Компонента CRM>
необходимо разработать форму с составом полей ..., на форме расположить кнопку сканирования документа...
обеспечить взаимодействие со сканером... описание схемы взаимодействия отсыл к требованию ИНТ1.
<Компонента ЛК (Личный кабинет Web интерфейс)>
В ЛК создать учетную запись клиента с логином соответствующим номеру ЛС, пароль сгенерировать...


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

Вопрос 3.
В посте выше Денис цитировал
"Из каких частей отдельных требований формируется "Спецификация требований к ПО"?
Не очень понял вопрос. Вы же сказали, что ознакомились со структурой документа у Вигерса? "
вопрос состоит в следующем
-в SRS должны попасть ФТ1 и ИНТ1, но например ИНТ1, может быть очень большим, нужно ли в SRS тащить  подраздел "Описание протокола взаимодействия",
или достаточно описания? Аналогочно для схемы которая может быть достаточно большой.

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

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

Добрый день!
Денис, благодарю за ответ!
Попробую переложить вопросы на пример. Общее описание - создается некоторая система. В этой системе оператор должен выполнять множество действий, возьмем пока
одну из задач - регистрация клиента.
В процессе регистрации оператор
- печатает форму договора которая передается клиенту для заполнения,
- вносит в систему данные о клиенте - ФИО, адрес, семейное положение и тд.д.
- а так же выполняет сканирование документа клиента и данный скан прикрепляется к карточке клиента.
Теперь это попробую разложить в виде требований и документов как я это вижу. Вопросы по тексту.
Цели проекта пока опущу. Начинаем с пользовательского требования.

1. Пользовательское требование -
Идентификатор: ПТ1.
Заголовок: - Регистрация клиента.
Описание:
система должна обеспечивать возможность зарегистрировать нового клиента.
Вопрос1. Нужно ли тут расписывать полностью все действия описанные в шапке
-1.1.печать договора,
-1.2. сканирование документа клиента...?
- 1.3.нужно ли описывать тут состав данных которые оператор вносит в систему?
Т.е. например так "в процессе регистрации оператор должен распечатать форму договора и переадть её для подписи клиенту.
Оператор должен отсканировать паспорт клиента и данный скан сохранить как приложение к карточке клиента, внести в систему данные - ФИО.."?

Диаграмма процесса:
Например есть диаграмма процесса она прикрепляется к данному требованию.

"Нужно ли описывать… " — ответ зависит от того, чем вы занимаетесь.

А. Вы пытаетесь сформировать набор требований для выбора готовой системы?
Б. Вы пытаетесь создать набор требований для предварительной оценки подрядчиком / командой?
В. Вы пытаетесь поставить задачу на проектирование системы?
Г. Вы пытаетесь поставить задачу на разработку системы?

В случае А вам возможно не нужна такая детализация.
В случае Б она полезна.
В случаях В-Г она необходима.

Вопрос 2. Требование к форме отчета "Договор клиента" это отдельное требование?

"Печать договора", "сканирование документа клиента" — это не части одного пользовательского требования, а отдельные требования, подчинённые ему.

Вигерс различает такие требования как пользовательские и функциональные. Я считаю такую классификацию неудачной и называю их:
- Пользовательское функциональное требование (описание результата, нужного пользователю)
- Техническое функциональное требование (обеспечивают реализацию пользовательского ФТ)

Форма отчёта — это тоже отдельное, но подчинённоё НФТ.

2. Создается требование к внешнему интерфейсу (интегарция со сканером)
Идентификатор: ИНТ1.
Заголовок: - Интеграция со сканером.
Описание:
система должна обеспечивать возможность получить копию документа клиента со сканера. Для этих целей необходимо обеспечить
взаимодействие системы со сканером <Модель>.
Схема взаимодействия
<тут размещаем схему>

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

Описание протокола взаимодействия
<длинное описание протокола взаимодействия со сканером>

3. Теперь формируем функциональное требование на выполнение пользовательского требования регистрации клиента
Идентификатор: ФТ1.
Заголовок: - Регистрация клиента.
Для выполнения сценария регистраии клиента неоходимо реализовать соледующие функциональные возможности
<Компонента CRM>
необходимо разработать форму с составом полей ..., на форме расположить кнопку сканирования документа...
обеспечить взаимодействие со сканером... описание схемы взаимодействия отсыл к требованию ИНТ1.

Обратите внимание, что когда вы начали говорить, что необходимо разработать (а не какими внешними свойствами должно обладать разработанное), вы вывалились из роли аналитика-проектировщика в роль тимлида-менеджера проекта, который ставит задачи разработчикам. Зачем?

<Компонента ЛК (Личный кабинет Web интерфейс)>
В ЛК создать учетную запись клиента с логином соответствующим номеру ЛС, пароль сгенерировать...

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

Вопрос 3.
-в SRS должны попасть ФТ1 и ИНТ1, но например ИНТ1, может быть очень большим, нужно ли в SRS тащить  подраздел "Описание протокола взаимодействия", или достаточно описания? Аналогочно для схемы которая может быть достаточно большой.

Вы можете описать сценарии взаимодействия со сканером в приложении к SRS, а можете сделать отдельный документ по описанию интеграций.