Практический подход к систематизации требований при проектировании информационной системы
0 likes429 views
Документ описывает практический подход к систематизации требований при проектировании информационной системы, акцентируя внимание на важности формализации алгоритмов действий и бизнес-процессов. Основная цель заключается в создании общего понимания системы между аналитиком и разработчиком с использованием вариантов использования. Также обсуждаются требования к модели и документации, которые позволят успешно адаптироваться к различным ситуациям в процессе проектирования.
![Практический подход к систематизации требований
при проектировании информационной системы
Р.О. Гунченко, А.В. Симкин
Проектирование информационной системы (далее ИС) сложная
и комплексная задача, которая требует от аналитика учета специфических
требований, предъявляемых к разрабатываемой системе. В первую очередь
необходимо понять, сформулировать и описать последовательность шагов
для достижения поставленной цели: необходимо выбрать инструмент
и способ описания алгоритма действий.
Целесообразно начать с определения назначения и целей создания
системы, следуя лучшим практикам ГОСТ 34. Далее, для получения единого
виденья (vision) проектируемой ИС у всех заинтересованных лиц
(stakeholders) необходимо формализовать алгоритмы действий, выполняемые
системой. Для описания этих алгоритмов целесообразно использовать
модели бизнес-процессов.
Существует множество методологий описания бизнес-процессов [1]
применяемых в различных ситуациях. Выбор методологии зависит
от решаемой задачи. Основными требованиями к модели являются
наглядность последовательности выполнения операций, явное описание
данных и документов используемых в подпроцессах. Модель должна ясно
описывать алгоритм действий происходящих в системе. Понимая суть
работы системы на основании модели, можно будет перейти к детальному
формированию требований.
Для дальнейшего проектирования системы необходимо обеспечить
общее понимание ИС между аналитиком и разработчиком, для этой цели
наилучшим образом подходит описание вариантов использования (use cases),
опирающихся на разработанную модель бизнес-процессов.
Практика создания вариантов использования как средств уточнения
требований к поведению информационных систем и бизнес-процессов
широко используется в мировой практике [2]. Варианты использования
обеспечивают комплексное понимание функциональных требований,
сопровождение которых необходимо на всех этапах жизненного цикла (life-
cycle) системы, показывая, как будет применяться будущая система.
На первый взгляд идея вариантов использования, кажется простой. Тем не
менее, разрабатывая набор вариантов использования, необходимо определить
уровень их детализации.
Формализация вариантов использования не является конечным
результатом проектирования ИС, кроме этого необходимо представить
разработчику совокупность требований, взаимосвязанных между собой
и вариантами использования.
Модель требований (см. Рис. 1, Таб. 1) разработанная в ходе проектной
деятельности позволяет решить задачу проектирования ИС.](https://image.slidesharecdn.com/20120401techreq-130723141259-phpapp02/85/-1-320.jpg)
Практический подход к систематизации требований при проектировании информационной системы
- 1. Практический подход к систематизации требований при проектировании информационной системы Р.О. Гунченко, А.В. Симкин Проектирование информационной системы (далее ИС) сложная и комплексная задача, которая требует от аналитика учета специфических требований, предъявляемых к разрабатываемой системе. В первую очередь необходимо понять, сформулировать и описать последовательность шагов для достижения поставленной цели: необходимо выбрать инструмент и способ описания алгоритма действий. Целесообразно начать с определения назначения и целей создания системы, следуя лучшим практикам ГОСТ 34. Далее, для получения единого виденья (vision) проектируемой ИС у всех заинтересованных лиц (stakeholders) необходимо формализовать алгоритмы действий, выполняемые системой. Для описания этих алгоритмов целесообразно использовать модели бизнес-процессов. Существует множество методологий описания бизнес-процессов [1] применяемых в различных ситуациях. Выбор методологии зависит от решаемой задачи. Основными требованиями к модели являются наглядность последовательности выполнения операций, явное описание данных и документов используемых в подпроцессах. Модель должна ясно описывать алгоритм действий происходящих в системе. Понимая суть работы системы на основании модели, можно будет перейти к детальному формированию требований. Для дальнейшего проектирования системы необходимо обеспечить общее понимание ИС между аналитиком и разработчиком, для этой цели наилучшим образом подходит описание вариантов использования (use cases), опирающихся на разработанную модель бизнес-процессов. Практика создания вариантов использования как средств уточнения требований к поведению информационных систем и бизнес-процессов широко используется в мировой практике [2]. Варианты использования обеспечивают комплексное понимание функциональных требований, сопровождение которых необходимо на всех этапах жизненного цикла (life- cycle) системы, показывая, как будет применяться будущая система. На первый взгляд идея вариантов использования, кажется простой. Тем не менее, разрабатывая набор вариантов использования, необходимо определить уровень их детализации. Формализация вариантов использования не является конечным результатом проектирования ИС, кроме этого необходимо представить разработчику совокупность требований, взаимосвязанных между собой и вариантами использования. Модель требований (см. Рис. 1, Таб. 1) разработанная в ходе проектной деятельности позволяет решить задачу проектирования ИС.
- 2. Рис. 1. Модель требований
- 3. Таб. 1. Классификатор требований Код Требование BP Модель бизнес процессов U Классы и характеристики пользователей V Требования к вариантам использования F Общие функциональные требования FA Требования к алгоритмам работы функций I Требования к интерфейсу пользователя D Требования к описанию данных T Требования к тестированию R Требования к отчетам С Требования к управлению справочниками и классификаторами P Требования к средствам интеграции А Требования к администрированию, управлению доступом и безопасностью системы AR Требования к правам доступа TS Требования к техническому обеспечению SR Требования к программному обеспечению IS Требования к информационной безопасности системы RD Требования к надежности Кроме того следует отметить, что конечный состав модели требований определяется исходя из специфики решаемой задачи, т.е. разработанная модель может быть дополнена или сокращена. Таким образом, сформировав технические требования на систему подобного уровня детализации можно достаточно просто формировать документацию к системе определяемую требованиями ГОСТ 34. Из вышеперечисленного перечня требований можно получить: Техническое задание по ГОСТ 19 и ГОСТ 34. Схему функциональной структуры. Пояснительную записку. Описание постановки задач (комплекса задач). Описание информационного обеспечения системы. Программа и методика испытаний. Спецификации (для программиста). Литература 1. Ковалев С. М., Ковалев С. В. Современные методологии описания бизнес- процессов — просто о сложном // Журнал «Консультант директора». – 2004. – № 12 2. Коберн А. Современные методы описания функциональных требований к системам. – Лори, 2002. – 266 с.