Обсуждение

Анатолий, сорри за оффтоп, но не знаете ли Вы стандарта на жизненный цикл требования или жизненный цикл пары "требование-реализация" (применительно к IT или вообще)? Спасибо.

Стандарт на жизненный цикл -- это как понимать?! Перечисление стадий жизни требования? Или набор практик, которые применяются к требованиям в ходе их жизненного цикла? Или и то и другое? И как вы выдираете жизненный цикл требований из контекста какой-то методологии разработки (т.е. жизненного цикла требований, архитектуры, тестов и т.д. в их взаимосвязи)? Тем не менее, на эти темы есть множество самых разных стандартов (и частных спецификаций конкретных производителей софта управления требованиями). Вопрос в том, что вам нужно. В том числе, не забывайте, что в разных школах мысли слово "требование" может означать очень разные вещи (например, быть "требованием заинтересованной стороны" или "требованием к системе", а еще есть "потребности" и "цели", которые к требованиям не всегда относятся). А пара "требование-реализация" -- это просто трассировка (хотя у нее тоже может быть жизненный цикл). Поглядите, например, http://community.livejournal.com/incose_ru/7754.html -- там тоже про "стандарт для требований".

Есть ощущение, что невозможно гарантировать полноту "списка пожеланий", и как следствие "контрольного листа требований", если танцевать только от развилок. Банально просто потому, что, например, инновации (т.е. внедрение подходов, которые еще не существуют "в железе", и поэтому отсутствуют в списке "возможных" решений) в этой логике совершенно никому были бы не нужны. Единственный способ избежать заведомых провалов и проколов на этой стадии - делать всякий выбор в наиболее общем контексте (т.е. например, действительно перечисляя все варианты, включая, например, выбор "выходя на улицу, встречу динозавра" наравне с выбором "встреча динозавра исключена"), для чего подчас нет необходимой инфраструктуры (т.е. каждый системный инженер может выбрать самый общий контекст априори, чем рискует оказаться в плену своих неявных предположений и суждений). Вывод, который мне напрашивается, про trade-off не забываем, но начинаем с начала (скажем, с мечты заказчика об идеальной системе, что бы она могла делать, какими свойствами и функциями обладать), и не отбрасываем варианты, пусть даже самые безумные, выбраковывая их только на стадии, когда задаем вопрос, а готов ли клиент к повышенной стоимости или повышенному уровню риска несоответствия, ввязываясь в инновации.

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

Поскольку сей труд я еще не читал - высказал всего-лишь свое мнение относительно мнения автора блога. Просто тут основной камень преткновения - когда заменять фантазии вариантами. Безинновационное развитие (низкорисковые проекты) делают это практически сразу - еще на уровне концепций. Т.е. нет аналога - спасибо за информацию, приходите еще. Инновационное - наоборот, тащит мечту до упора, и все время с ней сравнивается. Так что вопрос - каков приемлемый уровень риска.