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

Российский  государственный социальный университет

Факультет Информационных технологий

Кафедра информационной безопасности и программной инженерии 
 
 
 
 
 

По дисциплине: «Теоретические основы автоматизированного управления» 

На тему:

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

                                                                                Работу выполнила:

студентка группы

АСУ-В-4

Хрусталева  Н. В. 
 

Проверил: 

к.т.н., доц. Шевченко И.В.. 
 
 
 
 
 
 
 
 
 

Москва 2011 г.

Содержание 

Требования  к автоматизированной системе…………………..3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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