Требования к автоматизированной системе.
Структура и содержание документа

 

Вступление

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

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

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

Моя цель иная. Я хочу рассмотреть структуру документа требований так, как ее вижу я, основываясь на определенном опыте работы в данном направлении. Структуру, основанную на применении процессного подхода. Т.е., руководствуясь принципом, что автоматизировать приходится не отдельно взятые функции, никак не связанные между собой, а именно процессы. При этом, подробно разбирая каждый элемент и объясняя его предназначение в документе, попытаться дать общее понимание того, что должен представлять собой документ требований к автоматизированной системе и на какие вопросы он должен отвечать. Тем самым, я надеюсь помочь тем, кому это необходимо, выработать взгляд на проблему "сверху". Взгляд, не скованный определенными рамками и стандартами, а основанный исключительно на здравом смысле и понимании тех целей, которых требуется достигнуть. Имея такое знание, будет очень легко подстроиться под любой шаблон или стандарт, или изменить его в соответствии со специфическими условиями конкретного проекта. Помимо этого, при переговорах с заказчиками (неважно, внутреннее ли это подразделение компании или внешняя организация) гораздо проще будет ориентироваться в ситуации, и предлагать решение, наиболее приемлемое в данных обстоятельствах.

При написании данной статьи я сознательно "забыл" все известные мне шаблоны и структуры представления требований. Возможно, кто-то, прочитав этот материал, скажет: да вот же, структура точь-в-точь такая, как описано в стандарте "ХХ". Ну и хорошо. Зато теперь этот человек будет не слепо следовать стандарту "ХХ", а понимать, что стоит за каждой строчкой требований этого стандарта. Ведь применение стандартов, как и любой рекомендации, дает положительный эффект только при определенной адаптации к условиям своего применения.

Кому-то материал, изложенный здесь, может показаться неинтересным, кому-то – настолько очевидным, что он пожалеет о потраченном на прочтение статьи времени. Так бывает всегда. Я, в первую очередь, ориентировался на тех, кто только делает первые шаги в области постановки задачи на автоматизацию. Тех, кто работает давно, но волею обстоятельств не имел возможности задуматься над вопросами, рассматриваемыми здесь. А также тех, кто не разрабатывает требования к автоматизированной системе, а читает, согласовывает и утверждает их, т.е., людей, заинтересованных в успешной реализации продукта (руководителей проекта, представителей заказчика).

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

Несколько слов о терминах

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

Самый, пожалуй, классический пример на сегодняшний день, это термин "Техническое задание". Чего только под этим не подразумевается на разных проектах. Начиная от простейшего верхнеуровнего описания функциональности системы (что-то, вроде требований пользователя) и заканчивая мощнейшим документом, описывающим не только все возможные требования к системе, но также и аппаратно-программную среду реализации, подробное описание архитектуры, проработанную схему БД, полностью расписанный UI (интерфейс пользователя), и еще много чего. Несомненно, что любой из этих вариантов (равно, как и все промежуточные) имеют право на существование. Я лишь хочу подчеркнуть, что, разговаривая о разработке документа требований (или технического задания) необходимо, чтобы все стороны, принимающие участие в разговоре, понимали предмет разговора одинаково. Это позволит в дальнейшем избежать разочарований при получении результата.

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

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

Место и роль документа требований в общем процессе разработки автоматизированной системы

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

Жизненный цикл разработки ПО в упрощенном виде выглядит так, как это представлено на Рисунке 1.

Рисунок 1. Упрощенное представление жизненного цикла разработки ПО

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

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

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

Таким образом, документ требований представляется своеобразным "корнем" и порождает целое дерево других проектных документов (Рисунок 2).

Рисунок 2. Дерево проектных документов

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

Верхнеуровневая структура документа требований

Верхнеуровневая структура документа требований (Рисунок 3). определяется структурой требований, выявление которых является необходимым условием успешного проектирования автоматизированной системы.

Рисунок 3. Верхнеуровневая структура документа требований к АС

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

Цели не должны восприниматься как банальная отписка, служащая введением в документ. Цели создания продукта являются основой для определения бизнес-требований к системе ( Business requirements ). Это самый первый, самый верхний уровень документа требований. Бизнес-требования описывают, КАКИМ ОБРАЗОМ разрабатываемая система связана с достижением бизнес-целей организации и ЧТО она должна для этого делать. Можно сказать, что бизнес-требования являются своего рода задачами, которые должна решать автоматизируемая система для достижения целей своего создания.

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

К функциональным требованиям относится все то, что описывает функциональность системы. Т.е., ЧТО, КАК и КОГДА делает система. А также, КТО принимает в этом участие.

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

Функциональные требования включают в себя, так называемые, требования пользователей и системные требования.

Требования пользователей ( Customer requirements ) - это те требования верхнего уровня, которые предъявляют к системе будущие бизнес-пользователи системы. Другими словами, те задачи, которые система должна решать с точки зрения бизнеса Заказчика. В качестве примера можно привести такие требования, как "Система должна позволять создавать новые договоры", "Система должна позволять менять статус существующего договора", "Система должна позволять создавать новое дополнительное соглашение к существующему договору" и т.д. Еще раз необходимо подчеркнуть, что требования пользователей описывают верхнеуровневую функциональность системы, не вдаваясь в подробности ее технической реализации.

Системные требования ( System requirements ) имеют ровно такой же смысл, что и пользовательские требования, с той разницей, что в большей степени продиктованы не потребностями бизнеса, а особенностями IT -инфраструктуры Заказчика. Т.е., это требования, которые определяют регламент взаимодействия создаваемого ПО с внешними системами, регламентируют программно-аппаратные платформы функционирования продукта и т.п. Например, "Система должна иметь возможность осуществлять автоматический обмен данными с системой учета персонала".

В то время как требования пользователей и системные требования, как правило, отвечают на вопрос: ЧТО должна делать система, то детализированные функциональные требования ( Functional requirements ) отвечают на вопросы: КТО, КАК и КОГДА. Требования этого типа определяются на основе анализа и детального описания процессов, озвученных в требованиях верхнего уровня – пользовательских и системных. Со всеми соответствующими атрибутами – функциями, условиями, событиями, исполнителями, входами и выходами. Т.е., фактически, представляют собой детальное описание реализуемых системой потоков задач и данных.

Более подробно обо всех видах требований рассказывается далее.

Распределяем ответственность

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

Рисунок 4. Основные участники процесса разработки требований

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

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

Подробная структура документа требований

Раздел 1. Назначение документа

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

Раздел 2. Цели создания (использования) системы и решаемые задачи (назначение системы)

В этот раздел входят сведения, которые описывают существующую технологию, цели и назначение создания системы, а также эффекты от ее внедрения. По своей сути данный подраздел является бизнес-требованиями ( Business requirements ) к разрабатываемой системе.

2.1. Краткое описание деятельности заказчика и существующей технологии

2.2. Цели создания системы. Эффекты от ее внедрения

2.3. Назначение системы

Краткое описание деятельности заказчика и существующей технологии (Описание объекта автоматизации). Деятельность заказчика и существующая технология обычно описываются "естественным" языком. Однако, в случае, когда этого требует специфика проекта (например, была проведена предварительная работа по описанию процессов заказчика AS IS ) можно, и даже нужно дополнять текстовое описание графическими моделями. Это поможет команде разработчиков более грамотно ориентироваться в существующем бизнесе заказчика и глубже понять его потребности. Вообще, традиционно считается, что связующим мостом между заказчиком и разработчиками при разработке автоматизированной системы является аналитик, и именно он, и только он, должен вникать в тонкости деятельности заказчика. И зачастую разработчики не удосуживаются разобраться в области, которую они автоматизируют. Однако практика показывает, что на тех проектах, где разработчики не ограничиваются только непосредственно требованиями, а пытаются разобраться, а как, собственно, устроен сам бизнес, вероятность успеха более высокая.

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

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

При определении формулировок целей желательно, чтобы цель отвечала критериям SMART. Т.е., была конкретной (S), измеримой (M), достижимой (A), релевантной (R) и имела сроки исполнения (T). Иначе говоря, для того, чтобы определить, достиг ли проект своей цели, необходимо формулировать конкретные и измеримые цели, имеющие непосредственное отношение к решаемой проблеме и достижимые в определенные отрезки времени. При этом желательно указать, как именно можно будет измерить результаты деятельности. Поэтому, для того, чтобы сделать определение положительного влияния внедрения системы более наглядным, в документе приводят эффекты от внедрения системы. Эффекты оперируют числовыми показателями. Как правило, относительно имеющихся статистических данных. Например, "уменьшить расходы на обслуживание бизнес-процесса на 10% после внедрения системы по сравнению с текущими показателями (данные берутся из квартальных отчетов)", "увеличить количество обрабатываемых документов с 20 до 50 в день в течение первых 6 месяцев эксплуатации системы" и т.д. Приведенные расчеты должны быть выполнены еще на этапе подготовки к проекту, и являться основанием для принятия решения об автоматизации. Наличие подобных расчетов показывает серьезность подхода заказчика к разработке АС и позволяет избежать многих рисков, свойственных проектам подобного рода. Может так случиться, что разработка системы обойдется дороже, чем ожидаемый эффект от ее внедрения.

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

Цели системы имеет смысл описывать как "естественным" языком, так и представлять в виде графической модели (например, Дерева целей ( Objective diagram ) программы ARIS Toolset ( IDS Scheer AG)). Такое представление упрощает восприятие текстовой информации (пример такого дерева приведен на Рисунке 5).

Рисунок 5. Дерево целей создания автоматизированной системы

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

Представленная в данном разделе функциональность АС является верхнеуровневой. Например:

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

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

...
...
...

Объектами автоматизации являются:
...
...

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

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

Раздел 3. Используемые документы

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

Используемые документы могут быть разделены на две категории:

• основание для разработки – документы, являющиеся основанием для разработки системы;
• нормативные документы.

В качестве основания для разработки указываются контрактные документы, документы, описывающие концепцию реализации системы, высокоуровневые документы требований (если разрабатывается подсистема) и прочие документы, являющиеся основанием для создания системы.

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

Раздел 4. Термины, определения и сокращения

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

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

Версия для печати	Вернуться на сайт