Post #370

Сколько информации в ваших требованиях? Сложный пост с математическим уклоном. Задача аналитика — снизить неопределенность при проектировании системы, чтобы выйти на ограниченный набор возможных решений. Важное слово здесь — "ограниченный", потому что чем больше неопределенность (непонятно, что нужно), тем больше вариантов решений. Фактически, речь идёт об энтропии — числе способов, которыми можно расположить и связать компоненты системы. А это напрямую связано с количеством информации, описывающей систему. Не сильно вдаваясь в математические модели, можно сказать, что энтропия — это разница между новой информацией, содержащейся в сообщении, и хорошо известной информацией (о которой, может, и говорить-то не стоит). Например, хорошо известно, что любая сущность в системе должна быть создана и предъявлена/прочитана/использована. С большой вероятностью она должна быть удалена или архивирована. С некоторой вероятностью — изменена. Это обычный CRUD, которым можно контролировать полноту, но который почти ничего нового не сообщает об устройстве системы: можно было бы просто перечислить список сущностей, и завести CRUD для каждой. А вот когда мы начинаем задавать вопросы — когда и кем создается сущность? кому, когда и для чего её показывать? зачем и кто её изменят? — мы можем извлечь дополнительную информацию, передать в требованиях что-то, что не очевидно с самого начала. Таким образом снизив энтропию — уменьшив количество вариантов и рассказав что-то интересное. Интересное нам нужно, чтобы можно было выбирать обосновано. Если все варианты решений одинаковы — энтропия максимальна, это хаос, ну или нормальное распределение — верно нечто среднее. Такую картину мы получим, если требования собраны случайным образом, бессистемно: будет средняя система, непойми что, информации мало. Если вариантов нет и всё очевидно — энтропия будет минимальной или нулевой, но и информации никакой нет — нечего решать. Мы обычно находимся в интересной промежуточной ситуации, когда расхождение между очевидным и хаотичным велико. А значит, нужно много информации для снятия неопределенности. Поэтому требования должны быть неожиданными! Если вы читаете требования, и всё выглядит усредненно-понятным, значит, требования не передают много информации. То ли система очень простая (нет), то ли работа аналитика выполненная так себе. Требования должны быть неожиданными! И требования должны быть разными! Помните, как работает архиватор? Он выбирает одинаковые последовательности и заменяет их одним символом — повторение не несет информации. Если вы видите, что в ваших требованиях постоянно что-то повторяется: формулировка, обоснование, решение — остановитесь и задумайтесь. Не пропускаете ли вы здесь важную информацию? Стоит покопать поглубже, и получше разобраться? Или это хорошо известная информация? тогда и повторять её не имеет смысла, нужно упаковать в более компактный вид. А сколько у вас в документе неожиданных требований? Знаете, как в шахматной нотации ставят ! и !! и иногда !? Хороший ход, отличный ход, и неожиданный ход (возможно, ловушка). Скольким требованиям в документе вы может поставить такие значки? Конечно, удалять все дубли опасно, тут сразу можно вспомнить про избыточность информации — ведь информацию специальную дублируют при передаче, да и естественный язык у нас крайне избыточен. Но это делают в случае зашумленных ненадежных каналов — когда мы знаем, что часть информации будет потеряна или воспринята неверно. Тут, конечно, нужно смотреть по фактическому положению дел — насколько часто у вас такие проблемы в принципе возникают, и какую степень избыточности вам требуется предусмотреть в требованиях, чтобы информация из них всё-таки дошла.