0) Подумать, а на сколько критично вообще решение в данном вопросе.

Если не критичное место, то возможно первое попавшееся решение будет приемлемо. (Мне, например, без разницы какого цвета стикеры использовать, и формализовывать процесс выбора стикера — трата времени).

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

1) Определить критерии для оценки альтернатив

Обозначить величины и их приоритеты (если несколько критериев). Рекомендуется использовать опыт предыдущих анализов, очень вероятно что критерии повторятся.

SW: критерии для выбора платформы — доступность разработчиков под эту платформу, стоимость решений на этой платформе, потенциальная производительность, риски.

2) Обозначить альтернативы

Поиск альтернатив проводить как внутри команды, так и используя внешние знания (поиск, анализ конкурентов).

SW: кластерное решение системы управления базами данных: MS SQL server, Oracle, или как показал поиск по гуглу — то еще MySQL.

3) Выбрать способ оценки альтернатив

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

Понять во что обойдется (время, стоимость и пр) оценка альтернатив по выбранному способу.

SW: синтетические тесты, экспертная оценка, моделирование — первые пришедшие в голову примеры методик оценки.

4) Проанализировать альтернативы используя п1 и п2

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

Возможно вернуться к п3 и анализировать другим методом если выбранный метод ранее не дал отчетливых значений выбранных критериев в п1.

SW: выполнить моделирование/тесты, выделить значния важных критериев, сохранить отчеты в репозиторий.

5) Выбрать из п2. базируясь на п1

Так как, часто анализ выполняется по моделям (то есть не полной информации), то при рекомендации одной из альтернатив не забыть указать в рисках, как было выбрана эта альтернатива.

SW: выбрали RAC Oracle, т.к. среди прочего показал больший рост производительности при добавлении ноды — риск: тестировали с ограничением на типы операций и объемы данных.

Резюме:

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