Требования к автоматизированным информационным системам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение