Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Алексей Шемис от 14 Мая 2009, 12:55:36
-
Здравствуйте!
Помогите, пожалуйста, с ответами на вопросы.
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. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?
По-моему, критерий прост. Аналитик - часть команды. Если он смог понять, что нужно потребителям и донести это до остальных, и остальные не подкачали - решение на базе продукта покупают и используют. А если сделали не то, что было нужно - это сразу видно.
-
Считаю, что критерии успешности сбора требований:
- Инвестору/владельцу бюджета/владельцу проекта понятно в первом приближении, "что, как и для кого" предлагается сделать, сколько вложить и за сколько это окупится
- Архитектору понятно, что проектировать, разработчикам - что разрабатывать, менеджеру проекта - как разбить функциональность по итерациям, когда, в каком порядке и что выдавать, тестировщикам - как понять, что изделие работает правильно, тех. писателям - как объяснить, как изделием пользоваться
- Продавцам понятно, как изделие продавать (и у них это получается), инженерам понятно - как это внедрять (и они не краснеют перед представителями заказчика), заказчики готовы сотрудничать, покупают тех. поддержку.
По-моему, критерий прост. Аналитик - часть команды. Если он смог понять, что нужно потребителям и донести это до остальных, и остальные не подкачали - решение на базе продукта покупают и используют. А если сделали не то, что было нужно - это сразу видно.
Вот как раз разрыв между 1 и 2 критерием получается. Заказчику понятно, что будет сделано, и Архитектору понятно - что делать, но... к сожалению, Архитектор понял совсем по другому нежели Заказчики, и мы получаем ситуацию описанную в самом конце :(
-
Чтобы этого не происходило, показывают, обсуждают и согласуют друг с другом артефакты. Как вариант - просят "рассказать своими словами, как понял, что сделать нужно".
Заказчику показывают наборы требований, прототипы, программу и методику тестирования, устраивают опытную эксплуатацию, дают возможность сообщать о дефектах и пожеланиях доработки.
В команде - общаются, выходят за рамки своей роли, не проходят мимо, когда видят, что коллега делает не то, что нужно.
А сильная формализация требований и процесса работы с ними IMHO может такому взаимодействию между людьми только мешать. Чем больше и сложнее документ - тем хуже его читают и понимают.
-
Саша,
Это все понятно, просто вопрос был про критерии. А твои критерии, к сожалению, не подходят :(
-
IMHO исходная тема несколько надуманная, как уже было отмечено ранее выступившими коллегами. Скорее всего это от желания застраховаться от недостаточной компетенции, типа придет дядя с линейкой и всех проверит. Поэтому присоединюсь к авторам, высказавшимся в дуже - учиться надо...
А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.
Вторая цитата:
Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели.
Вот Вам и критерий.
-
А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.
Хороший пример, спасибо. Мне кажется, оценка трудоемкости реализации не может выступать в качестве точности модели, а служит показателем того сколько требуется усилий аналитика определенной квалификации на построение модели с заданной точностью "А".
Вторая цитата: Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Вот Вам и критерий.
Как нам понять, что мы достигли заданного уровня точности?
Моделью для разрабатываемой системы являются классы требований (бизнес-требования, пользовательские, функциональные и т.п.) и их представление (диаграммы), точность характеризуется собираемостью требований того или иного класса и написанием тех или иных диаграмм, их детализацией. Формально, требование о нагрузочном тестировании написано, считается, что мы построили модель необходимого качества, так? Hо реально, требование не отражает действительность.
Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?
-
А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
Написано в книжке Дэвида А. Марка и Клемента МакГоуэн "Методология структурного анализа и проектирования SADT" (http://www.isuct.ru/~ivt/books/CASE/case8/sadt_index.htm), а именно Методология структурного анализа и проектирования SADT. Глава 1. Системы и модели/ 1.2. Модель отвечает на вопросы (http://www.isuct.ru/~ivt/books/CASE/case8/sadt/gl1.htm)
-
Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?
Еще можно добавить критерий "требования должны быть проверяемыми (в процессе приемочных испытаний)". В последнее время несколько раз приходилось сталкиваться с попытками зафиксировать в проекте требования, которые этому критерию не соответствовали.
Для достаточно детальных требований может быть интересна задача оценки их избыточности. В этом случае, как правило, можно выделить требования, которые заведомо удовлетворяются при выполнении других требований. Или переформулировать их все для исключения избыточности.
Правда данная задача актуальна для достаточно больших систем, требования к которым формулируются несколькими представителями заказчика и собираются разными специалистами.
-
Хороший пример...
Как нам понять...
По первому.
Вообще говоря, модель - это описание вне зависимости от средств, которыми оно создается. А создается оно не для того "штоб було", а для последующей реализации в виде информационной (например) системы. Поэтому, трудоемкость реализации (а не трудоемкость разработки модели) вполне может быть критерием, определяющим точность.
Про "усилия аналитика" - несколько не в кассу, т.к. он должен затратить столько усилий, сколько нужно для создания модели нужного уровня подробности и точности соответствия той же предметной области. И не менее...
По второму.
Тупо задавайте вопросы: а как происходит то-то и то-то? куда пойдет такая-то информация? какие связи будут задействованы в таком-то случае? и т.д.
Конечно для этого желательно знать минимум две предметных области: конкретную, для которой делается система, и область разработки ПО. Как раз требование о необходимости нагрузочного тестирования в первопричине может иметь источники в опыте работы во второй из этих предметных областей. Вряд ли заказчик настолько хорошо осознает зачем это надо, скорее положится на Вас как на специалистов в своем деле.
Так что не надо ждать от заказчика формулировки всего-всего-всего, нужно и свою голову тоже включать и предлагать ему не набор диаграмм и документации, а РЕШЕНИЕ!
И, наконец, последнее.
Если Вы ждете критериев, типа упомянутого (не содержать того, что можно уточнить), то скажу, что это недостижимо. Как Вы определите, в свою очередь, могут быть сущности еще уточнены или нет?
Так что, нет ничего обязательного в этой деятельности, есть наборы практик, инструментов, которые будучи использованы грамотно и по своему назначению с большей вероятностью приведут к успешному результату. Однако если те же практики и инструменты использовать формально (типа, вот какую крутую методологию мы используем со всеми ее элементами и закорючками), то можно и самому запутаться и задачу не решить, соответственно, результат получится прямопротивоположный.
Я, кстати, видел много случаев, когда человек, с виду не владеющий методологиями, вполне последовательно и качественно решал именно задачу. На вопрос "а ведь Вы использовали такие-то элементы такой-то методологии" он отвечал что-то в духе "а выручалочка-то вот она где", постукивая себя по лбу.
Поэтому не увлекайтесь формализмом - решайте задачу!
-
To Galogen
Это разве важно? Гораздо важнее уметь правильно и по месту применить :о))
P.S. А еще существуют цитатники великих и просто известных...
-
не туда наблюдаете :о))
-
А как Вам идея выставления оценок по требованию другими Аналитиками ревьюирами, Разработчиками, Тестерами, Внедренцами, Заказчиками и т.д.?
Что-то типа голосования за качество требование от 2 до 5. И делать это необязательным, а just for fun.
Из этого голосования можем получить вот что:
1. Кол-во обращений к Требованию
2. Ценность требования (если за требование проголосовали, то это действительно очень важное требование)
3. Среднюю оценку работы Аналитика за период.
Только данный механизм должен быть легок в использовании и скорее всего его имеет смысл использовать только в СУТ.
-
Вот еще некоторые мысли по оцениванию работы Аналитика:
http://www.requirementsnetwork.com/node/620
-
По поводу оценки требований другими участниками команды.
IMHO многие требования - как рыбий жир или хинин. Участникам команды нужно быть очень "взрослыми", чтобы понять их важность и необходимость. Менее "взрослым" кажется, что требования и планы лишают их свободы и возможности реализации своих идей. Вряд ли их оценки могут быть репрезентативными.
С другой стороны, иногда требования нужны, чтобы "прикрывать пятую точку". В этом случае требования нужны тоже... весьма специфические. Тут уж МП или архитектор могут плохо оценивать простые и конкретные требования с хорошей тестируемостью.
Тем более, возможность отрицательно оценивать требования может быть использована в "подковёрных играх": хочется избавиться от системного аналитика, у которого есть "особое мнение" - оцените все его требования плохо.
Зачастую самые ценные требования - самые неприятные, спорные (трудно изложить и придумать за разработчиков с архитекторами хорошее решение) и трудно реализуемые. А живой и актуальный draft лучше отлично сформулированного, но никому не нужного требования.
IMHO лучше уж учитывать результаты "разбора полётов", после того, как обнаруживается, что какая-то часть программы не делает того, что от неё ожидают. Но и тут дело может быть в требованиях, а может быть в тысяче других причин.