Здравствуйте!
Помогите, пожалуйста, с ответами на вопросы.
1. Можно ли говорить о критериях этапа выявления требований и нужно ли? Под критерием понимается некий признак, на основании которого производится оценка этапа выявления (сбора информации).
2. Покрывает ли этап анализа требований оценку этапа выявления?
3. Что вы скажете, если использовать следующие критерии:
- внутренняя согласованность и непротиворечивость;
- системность;
- объективность;
- историзм.
 ?
4. Внутренняя согласованность и непротиворечивость. В собранной информации, фактах, требованиях достигнуты единство, стройность, гармония, они недиффузны, отсутствуют формулировки, при которых одно требование исключает другое, несовместимое с ним, противоположное ему. Установлены синтаксические связи между зависимыми словами. Учтены оттенки модальности, такие как: пользователь знает, что ...; пользователь думает, что ...; пользователь хочет, чтобы...; пользователь считает, что ... Учтены границы сбора информации. Разрешены все противоречия предметной области и интересы пользователей при формулировании требований.
Системность. На основе собранной информации рассмотрены все уровни многоуровневой иерархической организации любых объектов. На каждом уровне определены специфические свойства объектов, выявлены необходимые связи между ними.
Объективность. Собранная информация, сформулированные факты, требования не истолкованы с точки зрения субъекта – аналитика по требованиям и/или пользователя/эксперта, а отражают настоящую действительность, проблему. Достигнута необходимая глубина понимания - осознаны смысл, сущность, значение.
Историзм. Этот критерий связан с развитием. В собранной информации присутствует история возникновения проблем, которые необходимо решать. Автоматизируемые процессы рассмотрены с учетом временных изменений - присутствует связь как с прошлым, так и с будущим. Структура собираемых требований и сами требования допускают подстройку и коррекцию, как в период разработки, так и во время эксплуатации разработанной системы.
?
5. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?

Алексей,

Ты говоришь о этапе выявления требований? Точно? У меня сложилось впечатление, что ты говоришь о критериях успеха этапов сбора, анализа и документирования.
ИМХО говорить просто про выявление (сбор) требований, не имеет смысла. Имеет смысл, как минимум, говорить об этапах Сбора и Анализа требований, т.к. они очень сильно переплетены. А мерить можно только то, что изложено хотя бы на бумаге. Т.е. критерии применимы только к этапам  сбора, анализа и документирования.

Критерии тобой приведенные будет сложно измерить...

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

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

Согласованность и непротиворечивость очень часто соседствуют с неполнотой.
А разрешение всех противоречий imho невозможно в принципе, если количество пользователей ненулевое.

В частности, для этого и придуманы основные документы, фиксирующие требования: концепция (aka vision) и ТЗ (у которого есть много других имён). Нет предела совершенству, но всегда нужно на чём-то остановиться, прийти к компромиссу и зафиксировать его, согласовав с заинтересованными сторонами.

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

А почему организация "любых объектов" обязательно иерархическая? И как можно "выявить необходимые связи" на одном уровне иерархической системы? Этот критерий представляется мне несколько "высоконаучным", т. е. не имеющим связи с реальностью.

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

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

Вопрос: кто будет производить оценку по этому критерию? Этот самый субъект?

ИМХО говорить просто про выявление (сбор) требований, не имеет смысла. Имеет смысл, как минимум, говорить об этапах Сбора и Анализа требований, т.к. они очень сильно переплетены.

Хорошо, соглашусь. У Вигерса этот этап звучит как "Проверка" и на нем можно проверить соответствующие характеристики требований: полнота; корректность; осуществимость; необходимость; однозначность; проверяемость. Получается проверкой характеристик требований я покрываю оценку этапов выявления, анализа, документирования - т.е. я оцениваю результат, так? Но ведь эта оценка осуществляется со стороны системы, а если я хочу понять хорошо ли я выполнил выявление, анализ и документирование со стороны предметной области, что делать в этом случае? А может ли мне это понадобиться вообще?

Критерии тобой приведенные будет сложно измерить...

А другие измеряемые критерии есть?

Я знаю про постфактумные критерии:
1. Кол-во исправлений от Старшего Аналитика
2. Кол-во запросов на доработку на этапе сдачи
3. и т.д.
Это все накладывается на сложность и время разработки требований.

Согласна с BAS.
Кроме этого хотелось бы обратить внимание на следующее:
Критерии и оценки хорошо бы применять не к работам (деятельности), а к результатам деятельности. Иначе очень трудно определить количественные оценки. Да и целью любых работ обычно является получение результата определенного качества.

Здравствуйте!
Помогите, пожалуйста, с ответами на вопросы.
1. Можно ли говорить о критериях этапа выявления требований и нужно ли? Под критерием понимается некий признак, на основании которого производится оценка этапа выявления (сбора информации).
2. Покрывает ли этап анализа требований оценку этапа выявления?
3. Что вы скажете, если использовать следующие критерии:
- внутренняя согласованность и непротиворечивость;
- системность;
- объективность;
- историзм.
 ?
4. Внутренняя согласованность и непротиворечивость. В собранной информации, фактах, требованиях достигнуты единство, стройность, гармония, они недиффузны, отсутствуют формулировки, при которых одно требование исключает другое, несовместимое с ним, противоположное ему. Установлены синтаксические связи между зависимыми словами. Учтены оттенки модальности, такие как: пользователь знает, что ...; пользователь думает, что ...; пользователь хочет, чтобы...; пользователь считает, что ... Учтены границы сбора информации. Разрешены все противоречия предметной области и интересы пользователей при формулировании требований.
Системность. На основе собранной информации рассмотрены все уровни многоуровневой иерархической организации любых объектов. На каждом уровне определены специфические свойства объектов, выявлены необходимые связи между ними.
Объективность. Собранная информация, сформулированные факты, требования не истолкованы с точки зрения субъекта – аналитика по требованиям и/или пользователя/эксперта, а отражают настоящую действительность, проблему. Достигнута необходимая глубина понимания - осознаны смысл, сущность, значение.
Историзм. Этот критерий связан с развитием. В собранной информации присутствует история возникновения проблем, которые необходимо решать. Автоматизируемые процессы рассмотрены с учетом временных изменений - присутствует связь как с прошлым, так и с будущим. Структура собираемых требований и сами требования допускают подстройку и коррекцию, как в период разработки, так и во время эксплуатации разработанной системы.
?
5. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?

Трудность использования предложенного подхода может быть связан с моделью, задающей логику в которой анализируются требования.
Обычно имеем следующую ситуацию: есть некоторое описание требований и есть некоторая модель, которая задает логику анализа требований. Требования анализируются на предмет соответствия модели бизнеса заказчика, оформленной в документе или существующей в головах участников проекта.
Здесь же предлагается рассматривать требования в рамках модели не сколько автоматизируемой деятельности, сколько модели собственно требований.
Вопрос, насколько объективны представление об этой модели, в частности с нашей с Вами точки зрения? В рамках одной модели требования могут быть непротиворечивы, а в рамках другой - противоречия возникают. В частности, уже в пунктах 4-5 есть указания на некоторые модельные представления, которые могут разными людьми, даже специалистами, трактоваться по разному.
Насколько реально однозначно и объективно интерпретировать следующие фразы:
* "Установлены синтаксические связи между зависимыми словами".
* "Учтены границы сбора информации".
* "Разрешены все противоречия предметной области"
* "все уровни многоуровневой иерархической организации любых объектов".
* "требования не истолкованы с точки зрения субъекта – аналитика по требованиям и/или пользователя/эксперта, а отражают настоящую действительность, проблему." Как определить, выполнено ли это требование, как решать такую задачу - отдельная тема.

Требование рассмотрения анализируемой деятельности в контексте истории её формирования ИМХО весьма полезно. Как правило, выводит на анализ истории бизнеса заказчика, причем не только как отдельного предприятия, а как вида, отрасли деятельности.
Предложенный взгляд на "внутреннюю структуру", логику требований интересен. Но модель, в рамках которой этот анализ производится требует уточнения.

Что-то я не понял, какую проблему решаем и почему она важна.

Алексей, можно Problem Statement? А то мне видится, что вместо проблемы обсуждается организация одного из множества возможных решений, со всеми вытекающими.

Что-то я не понял, какую проблему решаем и почему она важна.
Алексей, можно Problem Statement? А то мне видится, что вместо проблемы обсуждается организация одного из множества возможных решений, со всеми вытекающими.

Это не то, что бы проблема.
Существуют некоторые рекомендации по выявлению, высказанные не мной, например:
Аналитик обязан, попытаться вытащить на «поверхность» все предположения (знания) пользователей и разрешить конфликты между требованиями.
Учитывая, что модель пользователей может не полностью отражать действительность - «читайте между строк», чтобы определить те возможности или характеристики, которые пользователи полагают само собой разумеющимися и даже не считают нужным обрисовать.
Различные специалисты предлагают использовать бесконтекстные вопросы, узкоспециализированные вопросы и вопросы, допускающие разные толкования, чтобы выявить информацию о проблемах и их возможных решениях.
В процессе сбора информации и осмысления работающий творчески аналитик не только фиксирует слова пользователей, но и подкидывает им новые идеи и предлагает альтернативы.

Обладая некоторым практическим опытом и навыками я смогу, наверное,  выполнить большинство из этих рекомендаций. Но ведь у любой практики может быть теоретическое обобщение. Можно ли взять "нечто" (в данном примере "критерии"), наложить на собранную информацию, оценить и сказать в каких направлениях нужно доработать, какие вещи сформулировать по другому, каким образом разрешить конфликты и т.п., не обладая при этом большим опытом?
Я думаю, правильная структуризация требований, некие правила по формулированию требований, должны помочь в этом.

Я использовал слово «проблема» в системно-аналитическом, а не бытовом смысле. Проблема — это разница между Существующим и Желаемым.

Что происходит сейчас?
Что Вы хотите, чтобы происходило?

Нет критериев оценки качества выявления? А зачем они нужны? Сделайте RCA, пожалуйста.

Проблема — это разница между Существующим и Желаемым.
Что происходит сейчас?
Что Вы хотите, чтобы происходило?
Нет критериев оценки качества выявления? А зачем они нужны? Сделайте RCA, пожалуйста.

Не совсем понял, RCA - ...?

Аналитик требований, пообщавшись с заказчиком, приносит следующее требование:
"Проверить нагрузки, например привести пример одновременного сеанса работы на 20 АРМ, или как вариант запустить по несколько АРМ на одном ПК".
Что из него видно? У аналитика отсутствует понимание нагрузочного тестирования, у заказчика этого понимания тоже не видно, в результате появляется требование, которое совсем не отражает действительность, которой должна соответствовать система. Понятно, что на этапе анализа это несоответствие будет выявлено, Старший аналитик сделает замечание, будет проведена повторная беседа с заказчиком и требование будет отражать действительность.
Но, что хотелось бы увидеть - аналитик на этапе сбора информации, сразу, даже не обладая знаниями процесса нагрузочного тестирования, сможет отразить действительность, например:
1. Сформулирует с заказчиком цели/средства/методы проведения нагрузочного тестирования и определит необходимость этого требования;
2. Уточнит почему только 20 пользователей, а не максимальное возможное количество + %;
3. Уточнит выполнение каких действий подразумевать под работой;
4. ...

Можно ли под это подвести теоретическую модель, я не знаю.

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

Ida (в первом посте) дело говорит. Критериев качества и KPI для этапа выявления требований, причем универсальных и реально работающих в ЛЮБОЙ ситуации, нет. В каком-либо конкретном случае их можно придумать. Два разных примера - критерии этапа выявления требований при внедрении ERP и создании нового, уникального продукта. В одном случае работаем "по накатанной", продавливая, в т.ч. экономически, заказчика на стандартные процессы. В другом случае - чистый полет фантазии, ограниченный здравым смыслом. Как подходить с одним мерилом для этих двух разных случаев, с т.з. критериев оценки качества выявления требований?

Как правильно сказала Ира, наверное имеет смысл говорить о чек листе. Как, например, я находил по ВИ.

1. Можно ли говорить о критериях этапа выявления требований и нужно ли? Под критерием понимается некий признак, на основании которого производится оценка этапа выявления (сбора информации).
2. Покрывает ли этап анализа требований оценку этапа выявления?
3. Что вы скажете, если использовать следующие критерии:
- внутренняя согласованность и непротиворечивость;
- системность;
- объективность;
- историзм.
<...>

IMHO этапа сбора требований нет, а есть процесс сбора требований, который никогда не прекращается. То, что Вы написали в качестве критериев - чрезвычайно полезно, но IMHO - недостаточно, и даже не необходимо. Потому что главное - уловить и передать то, что на самом деле нужно заказчику. Внешний вид, внутреннее изящество требований, их соответствие стандартам - полезны, но вторичны. Можно и на словах, и даже на пальцах, причём (такова жизнь) даже без протокола.

Считаю, что критерии успешности сбора требований:

• Инвестору/владельцу бюджета/владельцу проекта понятно в первом приближении, "что, как и для кого" предлагается сделать, сколько вложить и за сколько это окупится
• Архитектору понятно, что проектировать, разработчикам - что разрабатывать, менеджеру проекта - как разбить функциональность по итерациям, когда, в каком порядке и что выдавать, тестировщикам - как понять, что изделие работает правильно, тех. писателям - как объяснить, как изделием пользоваться
• Продавцам понятно, как изделие продавать (и у них это получается), инженерам понятно - как это внедрять (и они не краснеют перед представителями заказчика), заказчики готовы сотрудничать, покупают тех. поддержку.

5. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?

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