double arrow

Анализ требований к автоматизированным информационным системам


Существует значительное количество различных классификаций требований [9 – 14].

Прежде всего, выделяют требования к продукту и требования к проекту.

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

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




Для упрощения анализа требований используют принципы абстракции и декомпозиции. Применительно к анализу требований к программным системам эти принципы работают следующим образом. Требования разделяются по уровням. Уровни требований связаны, с одной стороны, с уровнем абстракции системы, с другой - с уровнем управления на предприятии. Классические уровни требований по К. Вигерсу представлены на рис. 2.1 [10].

Рис. 2.1. Модель уровней требований к программному обеспечению по Вигерсу [8]

Выделяют функциональные и нефункциональные требования (Functional and Non-functional Requirements) – функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

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

На верхнем уровне представлены так называемые бизнес-требования (business requirements). Бизнес-требования [15] на разработку (доработку) информационной системы разрабатываются Заказчиком на самых ранних стадиях, как правило, до инициации проекта. Документ "Концепция" включает следующие разделы:



Общие положения

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

Характеристика объекта автоматизации

  • Детальное описание
  • Терминология предметной области

Продукты и услуги

  • Перечень продуктов и услуг, планируемых к реализации в проекте
  • Параметры продуктов и услуг (каналы продаж, тарифы и т.д.)
  • Бизнес-логика

Базовые сущности

Выходные печатные формы

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

Описание бизнес‑процессов

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

Изменения в отчетности

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







Сейчас читают про: