Анализ требований. Основные артефакты, их назначение и ценность

Записаться

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

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

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

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

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

Первая группа пользователей, которую мы выделили, – топ-менеджеры, спонсоры. Для краткости мы дали им название «бизнес-пользователи». Они ставят перед собой цели и отвечают за их достижение. Они заинтересованы в выгоде. Документ, который позволяет это формализовать, – это бизнес-требования. Еще в ряде стандартов он называется концепцией.

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

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

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

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

Бизнес-требования должны отвечать на вопросы, зачем реализовывать требования, какую ценность эта реализация принесет бизнес-пользователям, сколько будет стоить реализация требований и какие риски она потенциально несет. Бизнес-требования должны содержать методику прогнозного расчета прибыли, которая может быть получена в результате реализации задуманной идеи. Среднестатистически бизнес-требования – не очень большой документ. От 3 до 5 страниц формата A4 хватит, чтобы заложить прочный фундамент развития каждой ценной идеи.

Следующий на очереди артефакт, который необходимо рассмотреть, – пользовательские требования. Цель этого документа – описать способы реализации идей через действия пользователей в какой-то одной или нескольких информационных системах.  Пользовательские требования получили реализацию в таком популярном шаблоне работы с требованиями, как User Story. Для фиксации пользовательских требований нужно ответить на несколько вопросов: кто пользователь, какая у него роль, что он делает, в какой момент процесса и что он хочет получить в результате, то есть для чего все это. Пользовательские требования связаны с алгоритмом работы пользователя. Для того чтобы формализовать и описать с другого ракурса – ракурса пользователя – ту самую идею, которую мы зафиксировали в бизнес-требованиях, нужно примерно от 10 до 15 страниц формата A4. То есть мы расписываем конкретные шаги, которые будет выполнять пользователь, чтобы реализовать задуманное.

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

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

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

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

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

При создании информационной системы очень важным является достижение единого понимания контекста создаваемой системы, способов реализации требований и результатах процесса разработки. В целях синхронизации разных групп пользователей и достижения конечного результата используются модели и диаграммы, позволяющие достичь единого понимания. К наиболее востребованным из них относят следующие: UML – универсальный язык моделирования, который позволяет представлять различные перспективы создаваемой информационной системы; BPMN, дающий возможность визуализации бизнес-процессов; DMN – таблица, формализующая принятие решений в состоянии комплексной сложности и многопараметричности; IDEF и DFD – семейство диаграмм, демонстрирующее поток данных от момента попадания в систему до момента формирования конечного результата.

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

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

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

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