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

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

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

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

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

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

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

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

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

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

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