Классификация требований

Записаться

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

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

Сегодня мы разберемся в классификации требований. Понимание, что такое требование, даст нам основу и фундамент для того, чтобы мы самостоятельно, на основе имеющихся у нас под рукой данных могли проводить классификацию требований для конкретного проекта и задачи. Мы посмотрим на то, какие бывают подходы, в частности, разберемся с подходом по ГОСТу, подходом по Карлу Вигерсу и распространенным подходом FURPS+.  Во всех этих подходах используются определенные активности. Некоторые из них мы уже знаем, о других, возможно, уже догадываемся, но некоторые из них станут для нас открытием. Классификация само по себе выполняет определенные задачи. Не нужно классифицировать требования просто потому, что это предписывает какой-то метод или подход. Всегда нужно понимать цель и назначение. Понимание целеполагания выполняемых действий поможет нам не заблудиться в инструментах и подходах и сэкономит наше время и ресурсы на выполнение работ.

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

Это дает основу для выполнения любой практически ценной классификации.

Дадим несколько формальных определений и сделаем несколько гипотез. Классификация – система или способ группировки субъектов наблюдения, то есть того, что мы изучаем, или исследования в соответствии с их общими явными и (или) потенциальными признаками. Понимание того, какое это требование, какая цель его формулирования, позволяет выполнить классификацию. Для того чтобы это сделать, нужно выявить интересные для нас признаки. Когда мы определились с классификацией, можно разрабатывать и использовать шаблоны для того, чтобы упростить работу над теми аспектами требований, которые интересны в данном конкретном шаблоне.  Подход шаблонизации предлагает простой, понятный путь работы над аспектами, которые являются наиболее ценными для данной конкретной среды. Шаблонизация должна использоваться на определенном этапе работы с требованиями. Этот этап нужно начинать, когда у нас нет вопросов, сомнений и мы точно понимаем, чему следует уделять наибольшее внимание. Шаблоны не являются универсальным инструментом и могут быть использованы тогда, когда мы понимаем классификацию, место и значимость каждого требования, работа над которым проводится. Работа над требованиями ограничена пониманием того, от кого мы получаем первоначальные требования и кто их потребляет. Это задает нужные нам рамки.

После того как сформулирована идея, точнее, когда стейкхолдеры ответят на вопрос, почему они хотят именно этого, начинается кропотливая работа по подсчетам того, насколько целесообразно это делать. Так, необходимо ответить на вопрос о том, сколько нам может или должна принести эта самая идея. Основной классификационный параметр – какую ценность мы получим, воплотив эту идею. Это формирует главный фокус в работе над бизнес-требованиями. Ценность – это сколько можно будет приобрести или сэкономить, насколько наша организация станет лучше, сильнее, а может, счастливее. После этого мы переходим к работе с заинтересованными сторонами, то есть с менеджерами и пользователями, которые своими действиями будут формировать эту самую ценность. Ведь ценность формируется в результате осознанного или бессознательного действия или бездействия со стороны исполнителей. Именно они воплощают в действительности то, что будет являться ценностным предложением. С этими сторонами тоже необходимо работать, собирая от них информацию о том, что и как они могут, что они привыкли делать. Именно это через какое-то время трансформируется в пользовательские требования к решению, то есть описание конкретных рабочих действий и активностях. После того как эта информация будет собрана, обработана, обсуждена и согласована, мы переходим к следующей стадии. На ней мы начинаем работать с описанием алгоритмов, методов, технологий, которые будут поддерживать работу над данными, которые нужны пользователям и составляют для них наибольшую ценность. Далее идут требования к решению. Больше всего заинтересован в этой категории требований специалист, который будет заниматься проектированием. В этих требованиях формулируется основа для построения системы, которая сможет обеспечить все необходимые функции требований заинтересованных сторон. Последние требования, о которых нужно поговорить, – переходные требования. Эти требования нужны в тех случаях, когда за одну рабочую итерацию сделать все необходимые требования заинтересованных сторон нельзя, но при этом необходимо поддерживать рабочий процесс, автоматизированный в информационной системе. При такой ситуации необходимо проектировать решение, которое позволит запускать функции итерационно, то есть шаг за шагом, где на каждом шаге есть необходимость выполнять рабочие действия и при этом получать результат. Переходные требования – мост для поддержки работоспособной ситуации на пути проведения изменений. Иногда этот путь длинный, иногда короткий. Переходные требования – компромисс в действии пользователей на пути к законченным пользовательским требованиям. В совокупности эти требования составляют жизненный цикл по работе над ними. Теперь давайте немного поговорим о конкретных методологиях, которые реализуют создание информационных решений.

Начнем с самой распространенной на территории нашей страны рабочей методологии – ГОСТ 34. Это и подход к работе, и способ классификации требований, и законченный высокоформализированный подход к организации работы над требованиями, и набор артефактов, которые предписано готовить по ходу выполнения проекта. Все это выражено очень четко, точно, понятно. ГОСТ 34 – это швейцарский нож проектов по разработке программного обеспечения. Но, к сожалению, этот ГОСТ не всегда приводит к нужному результату. Продукты, получаемые в ходе такой организации работ, очень часто дают крен в сторону документационного обеспечения, но не фокусируются вокруг продукта, не отслеживают его эффективность и востребованность у пользователей. Однако нужно отметить, что ГОСТ 34 – наиболее универсальный способ по запуску процессов создания информационных продуктов и систем для тех организаций, которые только становятся на этот путь, или для организаций, где нужно поставить на конвейер производство понятных, легкопроверяемых компонентов этих информационных систем. ГОСТ 34 предписывает строго определенную последовательность действий. Сначала – этап формирования требований. Тут мы исследуем проблему и помогаем формировать идею. Затем переходим к разработке концепции и более подробно изучаем рабочий объект. Затем приступаем к написанию технического задания. Следом готовим эскизный проект. Сразу после этого занимаемся подготовкой технического проекта. После готовим рабочую документацию для специалистов, которые будут заниматься поддержкой создаваемой системы. После этого осуществляем ввод объекта в действие и проводим послегарантийное обслуживание. Все просто и понятно. По ходу работы готовим все изученные требования, но, кроме этого, много чего дополнительного, что может пригодиться, а может и нет. И часть ресурсов уходит на подготовку документации, что не всегда обосновано и полезно.

Альтернативный подход – FURPS+. Немного по-своему, отлично от того, как мы рассматривали это ранее, этот подход преломляет, упаковывает и классифицирует требования, которые мы рассмотрели. Можно сказать, этот подход направлен только на работу с функциональными требованиями. FURPS+ имеет шесть классификационных категорий, каждая из которых внесла вклад в этот акроним. Так и сложилось его название. F – Functionality (функциональность). Это все то, что касается непосредственно функций, которые будет выполнять разрабатываемая система или ее компонент. U – Usability (удобство использования). Это функции, отвечающие за эргономичность системы и то, насколько удобной она является. R – Reliability (надежность). Это функции, которые повышают надежность создаваемой системы, – так называемая «защита от дурака», а также функции, которые делают систему более безопасной с точки зрения ее использования. P – Performance (производительность). Это функции, которые делают систему более быстрыми, – оптимизация алгоритмов расчета и более быстрые технологии, увеличивающие производительность. S – Supportability (поддерживаемость). Эти функции характеризуют, насколько просто и быстро можно устранять возможные проблемы и развивать систему. Это следующий класс категорий, характеризующих в целом зрелость системы. Ну и + (плюс), означающий ограничения, которые необходимо учитывать при сборе, анализе и проектировании требований. Это ограничения самого процесса проектирования, разработки, интерфейсов, которые могут вносить технологии, используемые для разработки конкретной системы.

Поговорим о еще одном подходе к классификации требований – возможно, наиболее авторитетном, распространенном и эффективном, который сформулировал консультант в области анализа, разработки и консалтинга информационных систем Карл Вигерс. Это комплексный подход, агрегировавший все типы требований, которые мы рассмотрели. Карл Вигерс, проводя деление, сформулировал две основные категории – функциональные и нефункциональные требования. Функциональные требования – это то, что должна делать система, то есть описание функций с разных точек зрения. Это бизнес-требования, пользовательские требования, функциональные и системные требования. Нефункциональные требования – то, как система должна реализовать функциональные требования. Это бизнес-правила, атрибуты качества, внешние интерфейсы и ограничения. В совокупности мы получаем комплексное, всестороннее описание системы с разных точек зрения. Для подготовки этих артефактов требуется логично собирать и обрабатывать требования и пожелания к тому, какой должна быть создаваемая система.

В российской литературе исторически употребляют выражение «сбор требований», но есть и корректный, въедливый перевод, который более точно описывает суть проводимых работ, – «извлечение требований». Главным является то, что клиент не попросит вас об использовании конкретной технологии. Если бы 100 или 150 лет назад вы спросили людей, что им нужно, они бы ответили: «Более быстрые лошади». Они не смогли бы и никогда не попросили бы автомобиль. Это очень точный и понятный пример, который расставляет акценты и фокусирует внимание на сути выполняемых работ. Аналитик не просто собирает требования. Если бы они росли в лесу и их просто нужно было бы собрать, аналитик назывался бы грибником. Вся суть этих действий состоит в том, что аналитик должен использовать анализ для того, чтобы дойти до сути сказанного, написанного, озвученного и, используя критическое мышление, понять, зачем это стейкхолдеру и что скрыто за тем, что было озвучено. Задача аналитика – получить именно такой результат. И тут мы подходим к следующему этапу – проанализированное нужно задокументировать.

После того как требования будут извлечены и проанализированы, необходимо зафиксировать их в формате, который будет способствовать последующей работе над ними. Документирование – это не только текст, это таблицы, графики, диаграммы, схемы, модели. Да и текст бывает разным, вернее, в разных форматах. Существует формат более структурированного изложения материала – например, как в спецификациях. Или формат, направленный на работу с пользователями, из которого им без дополнительных разъяснений будет понятно, о чем идет речь и что требуется от них с точки зрения полноты и сути излагаемой информации. Документирование способствует выявлению зависимостей в излагаемой информации, а также возможных явных закономерностей, которые могут быть использованы для формулирования «белых пятен». Именно документирование является атрибутом развивающейся аналитической культуры и основой для обсуждения и развития информации. Аналитики документируют не ради того, чтобы записать, а для того, чтобы применить к зафиксированной информации критическое мышление и анализ. Документируют для того, чтобы провести валидацию записанного на предмет уже имеющейся информации и подтвердить или скорректировать проектируемое решение. Документирование очень часто недооценивается и выполняется по остаточному принципу, но именно оно явилось мостиком к тому, чтобы человечество смогло развивать образование, культуру и науку. С разрабатываемыми информационными системами дело обстоит точно так же. Мнение, что документирование не меняется, – глубокое заблуждение. Оно меняется и развивается как этап анализа требований вместе с развитием информационных систем. Появляются новые подходы, которые интегрируют документирование и разработку. Возьмем, к примеру, литературное программирование. Эта концепция к написанию кода может найти развитие как в классической разработке информационных систем, так и в более продвинутых инструментах, например, RPA. Анализ требований – не статичная область. Она должна развиваться во всех своих проявлениях и направлениях. Но для того, чтобы развитие было оправдано, следует развивать требования не только в целом, как тип деятельности, но и как атрибут, который живет и развивается по ходу проекта автоматизации.

Для того чтобы отслеживать изменение анализа требований, существует отдельный вид деятельности – это трассировка. О ней мы уже немного говорили. Давайте формализуем ранее сказанное. У любого проекта есть ценность, которая выражается в виде озвученных целей. Цели подкрепляются требованиями бизнеса, которые были озвучены или извлечены. Требования бизнеса агрегируют в себе требования заинтересованных сторон и требования к создаваемой системе. Любое изменение или переформулирование цели приводит к тому, что требования заинтересованных сторон и системные требования должны меняться. Требования заинтересованных сторон должны согласовываться с бизнес-целями. Если этого не происходит, возникнут проблемы на каждом следующем этапе разработки, тестирования и внедрения создаваемой информационной системы. Эти требования должны удовлетворять создаваемую архитектуру решения, которая является центром для создания понятного, переиспользуемого и качественного кода и тестов. Все это множество атрибутов, артефактов связаны между собой. Разорвать связь – нарушить процесс циркулирования информации. Изменения в артефакте, на основе которого построены следующие артефакты, должно приводить к анализу изменений и корректировке артефактов. Это дорого, но только так можно соблюсти баланс между затраченными ресурсами и работами, которые выполняются в проекте создания системы. Трассировка должна запускать и контролировать процесс управления.

Управление работами по созданию и сопровождению требований как деятельность строится на активностях, которым уделяется разное внимание. Степень внимания определяет вид и качество результата. Основа процесса управления – трассировка и учет требований. Трассировать и учитывать абсолютно все требования – правильно, но это сложно, долго и затратно. Нужно концентрироваться на основных, наиболее приоритетных требованиях, которые приносят наибольшую ценность. Итак, мы подошли к процессу приоритизации. Для управления приоритизация – возможность сфокусироваться на основном. Но для того, чтобы управлять приоритизацией, следует выбрать самые важные атрибуты требований и сконцентрироваться на них. Запущенная приоритизация предписывает управлять и отслеживать изменения. Какие из этих изменений важны, а какие нет, подскажет карта и процесс трассировки. Все эти аспекты необходимо адаптировать под конкретный процесс управления требованиями. Каждая из этих дисциплин несет ценность, и эту ценность нужно осознать и использовать.

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

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

Итак, мы подошли к концу третьего модуля. Сегодня мы снова говорили о требованиях. В следующий раз мы продолжим разбирать оставшиеся аспекты требований и подведем итоги лекции 3. Перечислим основные выводы, которые будет полезно запомнить после сегодняшнего блока. Требование – это комплексное многосоставное понятие. Работа над требованиями – это уже во многом стандартизированный тип работ с описанием подходов и артефактов, которые должны быть результатом работы над требованиями. Инженерия требований имеет разнообразный инструментарий и типы активностей. Нужно стремиться использовать инструменты, наиболее подходящие для решения конкретных задач. До скорой встречи!