3.3. Пирамида типов требований

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

IEEE Standard Glossary of Software Engineering Terminology [14] определяет требования как

• условия или возможности, необходимые пользователю для решения проблем или достижения целей;

• условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;

Это определение охватывает требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Можно думать о требованиях, как о свойствах, которыми должен обладать продукт, чтобы представлять ценность для заинтересованных сторон. Следующее определение, данное Соммервиллем и Соером в работе [15] подтверждает различие типов требований:

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

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

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

Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обес­печить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений.

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

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

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

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

Заинтересованные стороны - это все, на кого реализация новой системы или при­ложения может оказать материальное воздействие.

Область проблемы — это сфера интересов заинтересованных сторон, чьи запросы должна удовлетворить команда разработчиков, чтобы построить совершенную систему.

Зачастую эти запросы формулируются представителями заинтересованных сторон неоднозначными и размыто. Например:

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

• Мне необходимо улучшить обратную связь с клиентами компании.

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

• Мне бы хотелось, чтобы существенно возросло количество заказов на покупку.

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

Запрос заинтересованной стороны это отражение некой личной, рабочей или бизнес-проблемы (или возможности), ре­шение которой оправдывает замысел, покупку или использование новой системы.

Эти запросы образуют кластер, ко­торый можно представить в форме небольшой пирамиды (рис 3.2.).

Рисунок 3.2. Запросы заинтересованных сторон, образующие область проблемы.

Практика показывает, что представители за­интересованных стороны, говоря о своих потребностях, часто описывают их не так, как показано выше.

Вместо этого заинтересованные стороны описывают некую абстракцию, что-то вроде:

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

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

• Необходимо, чтобы система формировала отчет, отражающий ежедневный приход товаров на склад.

• Необходимо реализовать заказ товаров через Интернет.

Эти высокоуровневые выражения желаемого поведения системы принято называть функ­циями (features) продукта или системы.

Функция — это предоставляемое системой обслуживание для удовлетворе­ния одной или нескольких, потребностей клиентов.

Следует отметить, что выявляемые таким образом функции часто не очень хорошо определены и могут даже противоречить друг другу, но так или иначе они являются отражением ре­альных потребностей. Это означает, что представитель заинтересованной стороны уже преобразовал реальную потреб­ность (производительность или безопасность) в поведение системы, которое, по его мнению, будет служить реальной потребности. При этом ответ на вопрос “Что мне нужно?" подменился ответом на вопрос "Что, по моему мнению, должна делать система, чтобы удовлетворить мою потребность". Это неплохо, поскольку представители заинтересованных сторон имеют реальный опыт в своей предметной области и реальное понимание значения функции. Кроме того, такие функции легко обсуждать и документировать на обычном языке, а также объяснять их другим, что существенно обогащает схему требований.

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

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

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

Функции представляют собой описания, которые команда будет использовать в качестве ярлыков, чтобы пояснить заказчику, как создаваемая система решает его задачу. Они представляют собой очень полезные конструкции для управления масштабом продукта на ранних эта­пах взаимных согласований и поиска компромиссов. Формулировка функций не требует значительных инвестиций; их легко описать и перечислить.

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

После того как определен набор функций и достигнуто соглашение с клиентом, можно пе­реходить к определению более конкретизированных требований, которым должно удовле­творять решение. Этот тип требований называется “тре­бования к программному обеспечению” (software requirements) и представляется в виде части пирамиды, расположенной у основания (рис. 3.3.).

Рисунок 3.3. Функции и тре­бования к программному обеспечению, образующие область решения.

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

• При вводе в форме авторизации пароля, длина которого меньше 6 символов, система выдает сообщение, содержащее текст “….”

• При отсутствии данных, вводимых пользователем в обязательном поле “Имя”, система должна повторно предъявить заполняемую форму, установив курсор в пустое поле и указать на ошибку “…”.

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

Тре­бования к программному обеспечению находятся в пирамиде требований ниже функций. Это означает, что команде разработчиков придется проделать большой объем работ, прежде будет достигнут этот уровень детализации.