четверг, 11 июля 2013 г.

Метод MoSCoW: хорош ли?

Многие системные аналитики знакомы с техникой (методом) приоритезации требований под названием MoSCoW. Данный метод основан на сопоставлении каждому из глаголов Must, Should, Could и Would значения важности (приоритета), которое присваивается требованию, сформулированному с использованием данного слова. Несмотря на то, что данная техника имеет англоязычные корни, русскоговорящие аналитики также используют данный подход: разумеется, заменяя английские слова русскими аналогами. Но настолько ли хорош данный метод, чтобы его можно было смело применять? На данный вопрос для себя я нашёл ответ в статье гуру Карла Вигерса Writing High Quality Requirements, перевод соответствующей части которой я и привожу ниже.

Я должен назвать это требованием


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

Слишком многие спецификации требований изобилуют случайным набором различных глаголов: shall (должен), must (обязан), should (следует), could (может), would (мог бы), is recommended (рекомендуется), is desirable (желательно), is requested (требуется), will (будет), can (может), may (может) и might (мог бы). Многие из этих слов взаимозаменяемы в повседневной речи, но они же могут внести путаницу в письменной спецификации. Читатель должен гадать, существует ли между ними тонкое, но значимое отличие. Обладает ли must отличным смыслом от can? Значит ли might (передаёт ощущение возможности в обычной речи) то же, что и may (передаёт ощущение разрешения)? Я также слышал о правилах, согласно которым shall обозначает требование, в то время как will определяет изложение дизайна, а must устанавливает ограничение. О боже!

Некоторые организации следуют на мной взгляд рискованной договорённости, согласно которой shall обозначает функцию, которая требуется; should определяет функцию, которая является желаемой; may обозначает функцию, которая является необязательной. Здесь возникает две проблемы. Во-первых, тут соединяются две концепции: формулировка намеченной функциональности и относительный приоритет этой функциональности. Во-вторых, информация о важности передаётся с использованием слов, смысл которых схож в повседневной речи.

Я предпочитаю использовать слово shall для определения функциональных требований когда только это возможно. Избегайти применения should, may, might и подобных слов, которые не дают уверенности, что утверждение является требованием. Мой коллега Брайан Лоуренс советует заменять should на probably won't (вряд ли) и потом смотреть, удовлетворит ли это клиента. Вряд ли.

Форма для определения требования "Системе следует (should) сделать X" может быть переделана на форму "Когда случается Y, система должна (shall) сделать X". И вместо использования цепочки shall-should-may для определения приоритетов, я предпочитаю формулировать требования в такой письменной форме:
1. Система должна … [Приоритет = Высокий].
2. Система должна … [Приоритет = Средний].
3. Система должна … [Приоритет = Низкий].

Цель ясного и недвусмысленного общения менее уловима, когда авторы требований применяют смесь практически идентичных по значению глаголов и ожидают, что читатели придут к тем же заключениям, что и они. Честно говоря, я не понимаю возражений против использования shall. Но если вам не нравится это слово, найдите ему замену (вроде must) и применяйте его схожим образом.

Комментариев нет:

Отправить комментарий