2.3.2. Анализ требований к автоматизированным информационным системам
Существует значительное количество различных классификаций требований [9 – 14].
Прежде всего, выделяют требования к продукту и требования к проекту.
Требования к продукту – это то, что формулирует заказчик. Цель, которую преследует заказчик – получить хороший конечный продукт. Поэтому требования к продукту являются основополагающим классом требований.
Требования к проекту – это то, как Разработчик будет выполнять работы по созданию системы. Требования к проекту не лежат в компетенции Заказчика. Однако Заказчик рискует получить продукт с опозданием или ненадлежащего качества. Для снижения рисков вводится регламентация процесса создания программного обеспечения и его аудит. Степень подробности регламентации требований к проекту зависит от множества факторов, таких, как ценность конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма подписанного контракта, увязка срока сдачи продукта в эксплуатацию с бизнес-планами Заказчика и т.д. С одной стороны регламентация процесса Заказчиком позволяет снизить его риски, а с другой – приводят к дополнительным накладным расходам. Требуется найти разумный компромисс между степенью контроля рисков и величиной расходов.
Для упрощения анализа требований используют принципы абстракции и декомпозиции. Применительно к анализу требований к программным системам эти принципы работают следующим образом. Требования разделяются по уровням. Уровни требований связаны, с одной стороны, с уровнем абстракции системы, с другой - с уровнем управления на предприятии. Классические уровни требований по К. Вигерсу представлены на рис. 2.1 [10].
Рис. 2.1. Модель уровней требований к программному обеспечению по Вигерсу [8]
Выделяют функциональные и нефункциональные требования (Functional and Non-functional Requirements) – функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.
Требования к ПО состоят из трех уровней – бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. 2.1. иллюстрирует способ представления этих типов требований. Овалы обозначают типы информации для требований, а прямоугольники – способ хранения информации (документы, диаграммы).
На верхнем уровне представлены так называемые бизнес-требования (business requirements). Бизнес-требования [15] на разработку (доработку) информационной системы разрабатываются Заказчиком на самых ранних стадиях, как правило, до инициации проекта. Документ "Концепция" включает следующие разделы:
Общие положения
Обоснование необходимости автоматизации, целесообразность проекта
Цели проекта
Задачи проекта
Область покрытия проекта
Ограничения проекта (что не входит в рамки проекта)
Ожидаемые результаты проекта
Ожидаемые документы проекта
Ожидаемое архитектурное решение
Приоритет и ожидаемые сроки завершения
Перечень подразделений, участвующих в процессе
Характеристика объекта автоматизации
Детальное описание
Терминология предметной области
Продукты и услуги
Перечень продуктов и услуг, планируемых к реализации в проекте
Параметры продуктов и услуг (каналы продаж, тарифы и т.д.)
Бизнес-логика
Базовые сущности
Выходные печатные формы
Экранные формы, которые должны быть реализованы, доработаны или выведены из эксплуатации в ходе проекта
Название формы
Состав полей
Алгоритмы формирования
Способы использования
Печатные формы, которые должны быть реализованы, доработаны или выведены из эксплуатации в ходе проекта
Название формы
Состав полей
Алгоритмы формирования
Способы использования
Описание бизнес‑процессов
Бизнес-процессы, их место в общей цепочке бизнес-процессов
Состав процедур и их детальное описание для каждого бизнес-процесса
Изменения в отчетности
Приводится описание ожидаемых изменений в регулярной управленческой и бухгалтерской отчетности.
Требования к разграничению доступа и данным
Требования к каналам продаж
Описываются требования по использованию информационной системы в удаленных точках продаж и через электронные каналы продаж.
Требования к порядку внедрения
Приводятся требования к этапности внедрения, срокам, требования к квалификации персонала и его обучению, требования к сопроводительной документации.
Эксплуатационные требования
Требования к производительности
Требования к объемам информации
Требования к нагрузочному тестированию
Требования к условиям эксплуатации
Требования к доступности системы
Следующий уровень – пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). На втором уровне выделяют также нефункциональные требования – Бизнес-правила и Атрибуты качества.
Бизнес-правила (Business Rules) – связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т. д. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос "кто будет осуществлять конкретный вариант, сценарий использования" или диктуют появление некоторых функциональных требований.
Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям:
Usability (Применимость) – удобство использования
Reliability (Надежность)
Performance (Производительность)
Supportability (Эксплуатационная пригодность)
Третий уровень требований – функциональный (functional requirements). На этом уровне определяются функциональные и системные требования, внешние интерфейсы и ограничения.
Функциональные требования (Functional Requirements) регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику. Функциональные требования записываются, как правило, при посредстве предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные". Другим способом являются так называемые варианты использования (uses cases) – популярный и весьма продуктивный способ представления требований.
Системные требования (System Requirements) – описывают требования, выдвигаемые информационной системой среде своего функционирования (системной, аппаратной). Пример таких требований – тактовая частота процессора, объем памяти, требования к выбору операционной системы. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.
Среди внешних интерфейсов (External Interfaces) в большинстве современных информационных систем наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
Ограничения (Constraints) – условия, сужающие выбор возможных решений. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных и т. п.).
Источниками требований являются:
Федеральное, муниципальное и отраслевое законодательство (конституция, законы, распоряжения)
Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
Текущая организация деятельности объекта автоматизации
Модели деятельности (диаграммы бизнес-процессов)
Представления и ожидания потребителей и пользователей системы
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты.
Характеристиками качественных требований являются следующие [10]:
– Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности.
– Корректность. Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными.
– Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды.
– Необходимость. Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения.
– Назначение приоритетов. Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки.
– Однозначность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям.
– Проверяемость. Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются.
Основными методами выявления требований являются:
Интервью, опросы, анкетирование
Мозговой штурм, семинар
Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
Анализ нормативной документации
Анализ моделей деятельности
Анализ конкурентных продуктов
Анализ статистики использования предыдущих версий системы
Для документирования требований используется Спецификация программного обеспечения (SRS – Software Requirements Specification). Спецификацию программного обеспечения нельзя путать с техническим заданием, частью которого она является. При составлении спецификации следует придерживаться стандарта IEEE 830‑1998 [10, 16, 17]. Имеется перевод стандарта на русский язык [18].
Так как формирование требований – сложный процесс, который осуществляется на протяжении всего проекта, то возникло управление требованиями [19] (requirements management) — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Для управления требованиями известны специальные системы, например, IBM Rational RequisitePro [20].