Хотелось бы получить критику или разъяснение статьи CMMI — шаг в будущее: разработка требований

Цитата1.
Требования клиента могут быть выражены в его собственных терминах и представлять собой нетехнические описания. Требования к продукту являются представлением требований клиента с помощью технической терминологии и могут быть использованы для проектных решений.

Вопрос 1.
Что значит выражены "с помощью технической терминологии"?

Цитата 2.
Разработка концепций и сценариев использования системы является первым шагом процесса анализа и утверждения требований

Вопрос 2.
Правильно ли я понимаю, что разработка концепции и ВИ есть суть анализа и осуществляется после сбора " требований клиента, требований к продукту и его компонентам, требований к компонентам продукта, требований к интерфейсам". Просто я как-то наивно полагал, что концепция делается до начала массового сбора требований?

Цитата 3 
Сценарий представляет собой последовательность событий, которые могут произойти при использовании продукта. Сценарий обычно используется, чтобы «высветить» некоторые потребности заинтересованных сторон. В отличие от сценария, концепция работы описывает, каким образом продукт используется или работает. Концепция зависит как от проектных решений, так и от сценария. Обычно при начальной выработке концепции альтернативные решения еще не существуют, поэтому концептуальные решения разрабатываются для анализа требований. По мере разработки технических решений и соответствующей разработки детальных требований нижнего уровня концепция работы может уточняться. Точно так же, как проектное решение для продукта может стать требованием для компонента продукта, концепция работы может стать сценарием (требованием) для компонентов продукта.

Вопрос 3
Как совершенно не въезжаю в то, что тут написано. То, что не понятно, подчеркнул.

Цитата1.
Требования клиента могут быть выражены в его собственных терминах и представлять собой нетехнические описания. Требования к продукту являются представлением требований клиента с помощью технической терминологии и могут быть использованы для проектных решений.

Вопрос 1.
Что значит выражены "с помощью технической терминологии"?

Там выше сказано:

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

Но по-моему, не стоит уделять этому слишком много внимания.

Цитата 2.
Разработка концепций и сценариев использования системы является первым шагом процесса анализа и утверждения требований

Вопрос 2.
Правильно ли я понимаю, что разработка концепции и ВИ есть суть анализа и осуществляется после сбора " требований клиента, требований к продукту и его компонентам, требований к компонентам продукта, требований к интерфейсам". Просто я как-то наивно полагал, что концепция делается до начала массового сбора требований?

...
Вопрос 3
Как совершенно не въезжаю в то, что тут написано. То, что не понятно, подчеркнул.

Возможно, автор попытался уложить в пару абзацев материал одной-двух глав увесистой книги. Или просто выбрал не самое удачное слово для обозначения какой-то сущности. Я так и не понял, что такое в данном случае "концепция" (не могу даже представить какой-то пример). Но у него это явно не "обзорный документ".

Я, конечно, не являюсь истиной в последней инстанции, но среди очень опытных специалистов, к коим я себя не отношу, бытует мнение, что CMMI, это платье голого короля, к тому же многие авторитетные издания пишут о том, что SEI, скоро придется переработать данную методологию, в связи с тем, что очень многие компании отнеслись к ней весьма скептически и не спешат приводить свои БП в соответствие с данной разработкой SEI. Сам я не рискну указывать на недостатки методологии, поскольку в компаниях, где я работал о существовании данной методологии мало кто знал, что не мешало им эффективно работать.

... к тому же многие авторитетные издания пишут о том, что SEI, скоро придется переработать данную методологию ...

Ага, именно по этому они и выпустили SCAMPI Lead Appraiser Body of Knowledge (SLA BOK) ?

С книгой, я, конечно, при возможности, ознакомлюсь, но думаю никакие книги сейчас не изменят тенденции о которой я упомянул. Да, крупные ИТ компании имеющие международные заказы будут продолжать сертифицироваться по уровням CMMI, но только для галочки, чтоб их заказчики были уверены, что обращаются в самые передовые компании.
А книга, ну, книга это всегда хорошо...
Как-нибудь посижу, почитаю...

А книга, ну, книга это всегда хорошо...

Это не книга - это свод знаний (BOK = Body of Knowledge != BOOK). Это свод знания для оценщика, т.е. руководство что и как делать, когда он (оценщик) сертифицирует  на CMMI какую-то компанию. Можно сказать, что это НОВЫЙ стандарт, кот описывает что должен знать оценщик и что он должен проверять при сертификации.

А вообще суть внедрения и сертифицирования на CMMI - это не переделывание процесса разработки ПО в компании, а "натягивание" CMMI на существующий процесс. Если чего-то не хватает в процессе, то только тогда добавляется, а не в коем случае не ломается и не строится все заново.
Другое дело, что денег это стоит не мало, но как по другому понять, что компания что-то умеет?
Просто как и везде, к сертифицированию по CMMI нужно подходить с толком, а то получится как обычно ...

Это не книга - это свод знаний (BOK = Body of Knowledge != BOOK). Это свод знания для оценщика, т.е. руководство что и как делать, когда он (оценщик) сертифицирует  на CMMI какую-то компанию. Можно сказать, что это НОВЫЙ стандарт, кот описывает что должен знать оценщик и что он должен проверять при сертификации.

А вообще суть внедрения и сертифицирования на CMMI - это не переделывании процесса разработки ПО в компании, а "натягивание" CMMI на существующий процесс. Если чего-то не хватает в процессе, то только тогда добавляется, а не в коем случае не ломается и не строится все заново.
Другое дело, что денег это стоит не мало, но как по другому понять, что компания что-то умеет?
Просто как и везде, к сертифицирования по CMMI нужно подходить с толком, а то получится как обычно ...

В плане идеологии вы все правильно говорите, даже книгу, являющуюся сводом знаний, новым стандартом имеете право назвать. Вот только опять возникает разрыв между реальностью и методологиями. Далеко не все практики в CMMI имеют смысл, но от них при сертификации никуда не деться. Получается так, что сертификация прошла, галочка есть, люди оставляют в практиках, то что действительно работает, а остальное выкидывается за ненадобностью. Я с парой таких примеров знаком, к слову, так делают и некоторые очень крупные российские интеграторы. А люди, которые проводят эти сертификации, тоже вполне адекватны и понимают, зачем и кому это нужно, особых иллюзий никто не питает. Я разговаривал с теми, кто занимался сертификацией нескольких очень крупных российских ИТ компаний, они лишь только подтвердили, то о чем пишу здесь я, ну и рассказали, как оно на самом деле.
Хотя в теории CMMI звучит отлично, как впрочем и многие другие методологии. Полезные практики  есть везде, полное соответствие разным методологиям не имеет смысла, ну кроме как в выше упомянутых вариантах. 
Не стоит видеть в CMMI решение всех проблем, а также не стоит данную методологию превозносить над другими не менее достойными, а мое личное мнение, что CMM была намного более жизнеспособна и приближена к реальности.
Думаю дальше обсуждать эту тему не имеет смысла, поэтому поставлю здесь точку в своих комментариях.

Я с парой таких примеров знаком, к слову, так делают и некоторые очень крупные российские интеграторы. А люди, которые проводят эти сертификации, тоже вполне адекватны и понимают, зачем и кому это нужно, особых иллюзий никто не питает. Я разговаривал с теми, кто занимался сертификацией нескольких очень крупных российских ИТ компаний, они лишь только подтвердили, то о чем пишу здесь я, ну и рассказали, как оно на самом деле...

Стоп ...
1) Кто это из "крупных интеграторов российских" РЕАЛЬНО адаптировал свои процессы, хотябы частично, под требования CMMI? К слову -- тот же Люксофт не является как таковым системным интегратором.
2) Интересно, с кем вы имели честь беседовать на тему сертификации крупных роcсийcких компаний по СММI, когда в Росии есть только один человек - официальный SCAMPI Lead Appraiser? А сертификацию проводили сплошь иностранцы, как у компаний-аутсорсеров, так и ту же Мотроллу?
3) CMMI это все-таки НЕ МЕТОДОЛОГИЯ, а модель ... давайте называть вещи своими именами.

Стоп ...
1) Кто это из "крупных интеграторов российских" РЕАЛЬНО адаптировал свои процессы, хотябы частично, под требования CMMI? К слову -- тот же Люксофт не является как таковым системным интегратором.
2) Интересно, с кем вы имели честь беседовать на тему сертификации крупных роcсийcких компаний по СММI, когда в Росии есть только один человек - официальный SCAMPI Lead Appraiser? А сертификацию проводили сплошь иностранцы, как у компаний-аутсорсеров, так и ту же Мотроллу?
3) CMMI это все-таки НЕ МЕТОДОЛОГИЯ, а модель ... давайте называть вещи своими именами.

Как я уже сказал, я не намерен называть ни компаний, ни людей.
А если мы начнем говорить терминами "РЕАЛЬНО", то получится, что на 100% никто не соответствует CMMI, потому что модель это одно, а реальность это другое.
А можно узнать кто у нас в России High Maturity Lead Appraisers (HM LA)?
По моим, скажу честно, довольно устаревшим данным, не было ни одного. Информация у меня полугодичной давности, за это время кто-то мог успеть получить HM LA.
Насчет того, что Maturity Model переводиться как модель зрелости, конечно, я спорить не буду, но поминуя о том, что "Методоло́гия - система принципов и способов построения организации теоретической и практической деятельности людей", думаю я не совершил, такой уж грубой ошибки, ведь если посмотреть со стороны, то CMMI вполне под это определение подходит, но в диспут вступать не буду, не вижу в этом смысла.