– в окне текст «Ваша карточка сохранена!»;

– форматирование следующее: цвет текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA, шрифт: Arial – для заголовка и кнопки размер 10, для текста – 8;

А теперь представим, что требования цветов взяты из бренд-бука компании, который в этот момент также находится в разработке, поэтому цвет может быть и #0000BB, и #EEEEEE, и еще множество других вариантов, которые сейчас неизвестны.

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

Теперь по втором требованию. Пусть, для примера, фраза «Ваша карточка сохранена!» не полностью нравится бизнес-заказчику, у него есть мнение, что текст может быть «Операция выполнена!» или «Документ сохранен!», между которыми он никак не может выбрать.

Изменения по этим требованиям вроде бы не выглядят трудоемкими, но, если они потребуются десятки раз в течение проекта (а это вполне реально, если заказчик колеблется в выборе), это уже будет ощутимо.

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

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

Важно то, что наше внимание к особенностям реализации требования обусловлено не его содержанием «вывести текст», а его состоянием «заказчик колеблется в выборе текста».

Возвращаясь к общему случаю, получаем другую, более сложную модель требования, которая опирается на то, что:

– содержание требования, как его понимают все участники проекта, может изменяться в ходе проекта;

– связи требования с другими требованиями могут прояснятся и изменятся значимым для понимания других требований образом в ходе проекта;

– состав требований проекта может изменяться в ходе его выполнения, а именно, возможно возникновение новых требований, а какие-то существующие требования могут удалятся из рассмотрения как неактуальные.

Назовем это динамической моделью требования.

Перечитаем еще раз… Ничего стабильного… Как с этим работать то можно? Кажется, что с такими постулатами мы стоим на чем-то зыбком и совершенно неустойчивом… Как обрести твердую почву под ногами? Ответ прост – «замораживать» на время проведения работ. Именно так поступают строители, когда возводят сооружения на неустойчивых грунтах, также будем поступать и мы.

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

Разработка чего бы то ни было, будь то программное обеспечение, опытный образец продукта, методика или иной продукт творческо-производственной деятельности, происходит по одному и тому же укрупненному циклу:

– требования;

– проектирование;

– изготовление;

– проверка соответствия требованиям;

– устранение несоответствий;

… (пока не будет устранено несоответствие требованиями)

– проверка соответствия требованиям;

– приемка (передача в эксплуатацию)

Предсказуемость (да и возможность) выхода из этого цикла зависит от двух параметров:

– фиксированы ли требования,

– возможно ли исправить несоответствие требованиям.

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

Это не что иное, как ранее упомянутая простая модель требований со всеми ее достоинствами и недостатками.

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

В то же время простая модель может не отвечать жизненным реалиям, которые скорее описываются динамической моделью.

В этом случае необходимо представить динамическую модель как последовательность простых. То есть, на какое-то время требования фиксируются, затем опять могут изменяться, затем снова фиксируются и т.д. Как это сделать?

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

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

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

Подходы могут быть различны: ограничение точности достижения первоначального результата (какие и в какой мере будут реализованы требования изначальной постановки, в частность разного рода прототипы и MVP являются примерами такого ограничения), ограничение количества итераций, ограничение по ресурсам и времени – все это является предметом методологий, создавая им различные сферы применения.

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

Поняв эту специфику требований в целом, вернемся к их жизненному циклу в частности.

Требование, как мы уже поняли – это идея, которая возникает в голове у специалиста заказчика или аналитика, формализуется, документируется и, затем, исполняется.

Идеи, конечно, могут возникать одномоментно, как в комиксах: зажглась лампочка – есть идея!

Однако, требования, это не просто идеи, а идеи, обладающие определенными свойствами: однозначностью, непротиворечивостью, исполнимостью, измеримостью. К тому же, идея, составляющая требование, должна быть задокументирована для дальнейшей работы.

Поэтому между моментом «зажигания лампочки» и появлением документированного требования требуется, чтобы была выполнена работа, которая занимает некоторое время.

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

Это время составляет часть жизненного цикла, стоящую в начале жизни требования.

Проанализируем подробнее как эта работа происходит.

Идея развивается непрерывно, поэтому четко выделить и определить ее отдельные состояния в естественном развитии не получится.

Тем не менее, определенные состояния требования нам важно отследить, и эти состояния определяются некоторым уровнем наличия тех или иных свойств требования, а именно:

– однозначность,

– непротиворечивость,

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.