Проектирование архитектуры информационных систем

3.6 Системные требования

Системные требования представляют собой формализованное техническое описание функций, характеристик, интерфейсов, условий и ограничений системы в целом. Они создаются путем преобразования потребностей заинтересованных сторон и пользовательских требований в требования, пригодные для проектирования и проверки. Пользовательское требование обычно описывает цель пользователя. Системное требование определяет, что должна обеспечить система для достижения этой цели. Например, пользовательское требование может звучать так: «Покупатель должен иметь возможность оплатить заказ банковской картой». Из него выводятся системные требования: система должна сформировать платежный запрос; передать его во внешнюю платежную систему; получить результат; связать платеж с заказом; зарегистрировать отказ; исключить повторное списание; уведомить покупателя; сохранить сведения для аудита. Системное требование рассматривает информационную систему как целое. Оно может распределяться между программным обеспечением, оборудованием, данными, персоналом и организационными процедурами. Например, требование обеспечить сохранность данных может реализовываться программными механизмами контроля доступа, резервным оборудованием, регламентом резервного копирования и действиями администратора. Системные требования включают требования к функциям, производительности, надежности, безопасности, пользовательскому взаимодействию, данным, интерфейсам, эксплуатации, сопровождению и ограничениям проектирования. Требования к внешним интерфейсам определяют взаимодействие с пользователями, другими системами, техническими устройствами и каналами связи. Например, требование к внешнему интерфейсу может устанавливать состав данных, передаваемых в государственную информационную систему, формат сообщения, частоту обмена, механизм подтверждения и обработку ошибок. Требования к данным определяют состав информационных объектов, правила качества, сроки хранения, владельцев, источники и ограничения доступа. Эксплуатационные требования устанавливают условия установки, настройки, администрирования, резервного копирования, обновления и мониторинга. Ограничения определяют обязательные условия, в пределах которых проектируется система. Ограничением может быть использование существующей инфраструктуры, определенной операционной системы, утвержденного протокола, конкретной территории хранения данных или установленного бюджета. Системные требования должны быть согласованы с архитектурой. Архитектура распределяет требования между элементами системы и определяет механизмы их выполнения. Например, требование выдерживать десять тысяч одновременных пользователей может привести к использованию балансировки нагрузки, нескольких экземпляров приложения, кэширования и масштабируемого хранилища. Требование сохранять работоспособность при отказе одного сервера влияет на резервирование компонентов и развертывание системы. Требование обеспечить конфиденциальность персональных данных влияет на аутентификацию, разграничение доступа, шифрование, журналирование и архитектуру информационных потоков. Системные требования должны описывать внешне наблюдаемые свойства системы и ограничения, но не всегда должны преждевременно фиксировать внутреннюю реализацию. Если технология не предопределена, требование должно определять результат, а выбор способа оставаться архитектурным решением. Например, требование «система должна обеспечивать восстановление работоспособности не более чем за тридцать минут» предпочтительнее, чем «система должна использовать определенную программу резервного копирования», если применение этой программы не является обязательным ограничением заказчика.

3.7 Функциональные требования

Функциональные требования определяют функции, операции и поведение, которые должна выполнять система. Они описывают преобразование входных данных в результаты, реакцию на события, бизнес-правила и взаимодействие с пользователями или внешними системами. Функциональное требование отвечает на вопрос: что должна делать система? Например, система должна регистрировать пользователя, рассчитывать стоимость заказа, проверять наличие товара, формировать счет, сохранять документ, отправлять уведомление или предоставлять отчет. Функция может инициироваться действием пользователя, поступлением сообщения, наступлением времени или изменением состояния данных. Например, функция формирования ежемесячного отчета инициируется календарным событием. Функция блокировки учетной записи запускается после определенного количества неудачных попыток входа. Функция обновления остатка выполняется после регистрации складской операции. Функциональное требование должно содержать условие выполнения, действие системы и ожидаемый результат. Формулировка «система должна поддерживать заказы» является слишком общей. Более точно: «После подтверждения покупателем состава корзины система должна создать заказ, присвоить ему уникальный номер, зафиксировать состав товаров, цены, адрес доставки, способ оплаты и состояние „ожидает оплаты“». Функциональные требования могут быть представлены на разных уровнях детализации. На верхнем уровне определяется функция «управление заказами». Она декомпозируется на создание, изменение, отмену, оплату, отгрузку и закрытие заказа. Каждая функция может дополнительно разделяться на отдельные операции. Например, создание заказа включает проверку клиента, получение товаров из корзины, расчет стоимости, выбор доставки, резервирование и сохранение. Функциональные требования должны учитывать бизнес-правила. Бизнес-правило представляет собой ограничение или условие предметной области. Например, «скидка предоставляется только зарегистрированным клиентам», «заявка стоимостью более установленного порога требует согласования руководителем», «студент не допускается к экзамену при отсутствии зачета». Бизнес-правило может использоваться несколькими функциями. Поэтому его целесообразно документировать отдельно и связывать с соответствующими требованиями. Функциональные требования должны учитывать права пользователей. Одна и та же операция может быть доступна разным ролям с различными ограничениями. Например, автор документа может редактировать черновик, руководитель — утверждать документ, а архивариус — переводить его на хранение. Необходимо описывать обработку ошибок. Требование не считается полным, если оно отражает только успешный вариант. Например, при загрузке файла система должна проверить формат, размер и наличие вредоносного содержимого. При нарушении условия операция отклоняется, а пользователю предоставляется понятное сообщение. Функциональные требования могут описываться с помощью моделей процессов, диаграмм состояний, таблиц решений и сценариев. Диаграмма состояний полезна, когда объект проходит через последовательность состояний. Например, заказ может иметь состояния «создан», «ожидает оплаты», «оплачен», «передан в доставку», «доставлен», «отменен». Требования должны определять допустимые переходы. Нельзя передать неоплаченный заказ в доставку, если бизнес-процесс не допускает оплату при получении. Таблица решений применяется, когда результат зависит от сочетания нескольких условий. Например, размер скидки определяется категорией клиента, суммой заказа и наличием акции. Функциональные требования образуют основу для функционального тестирования. Для каждого требования должны быть определены условия, входные данные и ожидаемый результат. При этом наличие большого количества функций не означает высокое качество системы. Система может реализовать все операции, но быть медленной, ненадежной или неудобной. Поэтому функциональные требования должны дополняться нефункциональными.

3.8 Документирование требований

Документирование требований представляет собой систематическую фиксацию требований, их источников, характеристик, связей, состояния и критериев проверки. Основная задача документирования заключается не в создании большого текстового документа как такового, а в формировании общего и контролируемого понимания будущей системы. Требования могут храниться в техническом задании, спецификации системных требований, спецификации требований к программному обеспечению, реестре требований, моделях, сценариях, таблицах, специализированной информационной системе или их сочетании. ISO/IEC/IEEE 29148:2018 устанавливает процессы инженерии требований и требования к информационным результатам, создаваемым в ходе этих процессов. ГОСТ Р 56713—2015 определяет содержание информационных продуктов жизненного цикла систем и программного обеспечения, включая документацию. В отечественном проекте автоматизированной системы значительная часть требований фиксируется в техническом задании по ГОСТ 34.602—2020. Требования могут дополнительно уточняться в проектной и программной документации. Каждое требование целесообразно снабжать уникальным идентификатором. Например, функциональное требование может иметь обозначение ФТ-015, а требование безопасности — БЗ-007. Идентификатор позволяет ссылаться на требование в проектной документации, программном коде, тестах, протоколах и запросах на изменение. Требование должно иметь наименование и текст, описывающий обязательное свойство или поведение. Дополнительно могут указываться источник, обоснование, приоритет, статус, версия, ответственный, способ проверки и связанные требования. Источник требования показывает, кто или что стало основанием для его появления. Источником может быть пользователь, закон, договор, стандарт, бизнес-процесс или внешняя система. Обоснование объясняет, почему требование необходимо. Это особенно важно, если требование ограничивает архитектуру или повышает стоимость. Например, требование хранить журнал операций пять лет может быть обусловлено нормативным актом. Без обоснования разработчик может ошибочно считать срок произвольным и предложить его сократить. Приоритет определяет относительную важность. Требования могут быть обязательными, желательными и дополнительными. Однако приоритет не должен подменять договорную ясность. Если все требования объявлены максимальными, приоритизация теряет смысл. Статус отражает состояние требования: предложено, анализируется, согласовано, реализовано, проверено, отклонено или изменено. Критерий приемки определяет, каким наблюдаемым результатом подтверждается выполнение требования. Например, для требования о времени отклика критерием может быть результат нагрузочного испытания. Для требования о формировании отчета — совпадение результата с контрольным набором данных. Требования должны обладать рядом качеств. Необходимость означает, что требование связано с реальной потребностью или обязательным ограничением. Ненужные требования увеличивают стоимость системы. Однозначность означает, что требование допускает одно разумное толкование. Следует избегать слов «быстро», «удобно», «современно», «при необходимости» и «по возможности» без пояснения критериев. Полнота означает наличие всех необходимых условий, входных данных, результатов и исключений. Непротиворечивость требует отсутствия конфликтов между требованиями. Например, одно требование не может предписывать автоматическое удаление данных через год, если другое требует хранить их пять лет. Единичность означает, что одно требование описывает одно основное обязательство. Формулировка «система должна зарегистрировать пользователя, отправить письмо, создать отчет и обновить справочник» содержит несколько требований и должна быть разделена. Реализуемость означает возможность выполнения требования при существующих технологиях, ресурсах, сроках и ограничениях. Проверяемость означает возможность объективно подтвердить выполнение. Прослеживаемость означает наличие связей требования с источником, более высокоуровневыми требованиями, проектными решениями, компонентами и тестами. Независимость от реализации означает, что требование по возможности описывает требуемый результат, а не преждевременно выбранный способ. Исключение составляют обязательные проектные ограничения. Для формулирования требований часто используется конструкция: «Система должна…». Она подчеркивает обязательность. Однако одного грамматического шаблона недостаточно. Требование должно содержать точный смысл. Плохая формулировка: «Система должна быстро сохранять документы». Улучшенная формулировка: «При размере документа до 20 мегабайт система должна завершать сохранение не более чем за три секунды для 95 процентов операций при одновременной работе до 500 пользователей». Второй вариант определяет объект, условия, показатель и допустимое значение. Документация требований должна различать обязательные требования и справочную информацию. Если пояснение, пример и требование оформлены одинаково, участники могут неправильно определить, что подлежит реализации и приемке. Необходимо документировать предположения. Например, проект может исходить из того, что внешняя система доступна круглосуточно или предоставляет определенный интерфейс. Если предположение окажется неверным, архитектуру придется изменить. Необходимо фиксировать ограничения. Ограничения могут быть нормативными, техническими, финансовыми, временными или организационными. Особое значение имеет матрица прослеживаемости требований. Она показывает связи между требованиями различных уровней и результатами разработки. Например, пользовательское требование ПТ-01 связано с системными требованиями СТ-11 и СТ-12. Они реализуются компонентами К-03 и К-07 и проверяются тестами Т-21, Т-22 и Т-25. Прослеживаемость позволяет определить, все ли потребности реализованы, почему существует определенный компонент, какие тесты необходимо повторить после изменения и какие части системы затрагиваются. Если изменяется требование безопасности, матрица позволяет найти связанные архитектурные решения, программные модули, инструкции и испытания. Документирование требований не является разовой работой. Требования изменяются, поэтому необходимо управление требованиями. Каждый запрос на изменение должен регистрироваться. Оцениваются причина, приоритет, влияние на стоимость, сроки, архитектуру, данные, документацию и испытания. После согласования обновляются связанные материалы. Неконтролируемое изменение приводит к расхождению между фактической системой и документацией. Например, программа может реализовать новую функцию, но техническое задание и руководство пользователя останутся прежними. Требования должны проходить проверку и валидацию. Проверка определяет качество формулировок: полноту, непротиворечивость и проверяемость. Валидация подтверждает, что требования отражают реальные потребности заинтересованных сторон. Для проверки используются рецензирование, совместные обсуждения, прототипы, моделирование, формальная проверка и подготовка тестов. Разработка тестов на этапе анализа требований помогает обнаружить непроверяемые формулировки. Если тестировщик не может определить ожидаемый результат, требование нуждается в уточнении. Прототип пользовательского интерфейса помогает проверить понимание сценариев. Однако прототип не заменяет требования. Он должен быть связан с текстовыми и модельными описаниями. Документация должна быть управляемой по версиям. Необходимо определять актуальную утвержденную редакцию, историю изменений и участников согласования.

3.9 Нефункциональные требования

Нефункциональные требования определяют характеристики качества системы, условия ее функционирования и ограничения реализации. Они отвечают не столько на вопрос, что делает система, сколько на вопросы: насколько хорошо она выполняет функции, в каких условиях работает, какие ограничения соблюдает и каким уровнем качества обладает. Термин «нефункциональные требования» условен. Эти требования не являются менее важными или необязательными. Во многих системах именно они определяют архитектуру и стоимость. Например, функция перевода денежных средств может быть реализована сравнительно просто. Однако требования к безопасности, целостности, доступности, производительности, аудиту и восстановлению превращают ее в сложную банковскую функцию. Нефункциональные требования часто называют требованиями к качеству, атрибутами качества или ограничениями. Эти понятия связаны, но не полностью тождественны. Требование «система должна обрабатывать тысячу запросов в секунду» относится к производительности. Требование «система должна использовать сертифицированное средство защиты» является ограничением. Требование «система должна хранить данные на территории определенного государства» является нормативно-организационным ограничением. Модель качества ISO/IEC 25010:2023 включает девять характеристик качества продукта: функциональную пригодность, эффективность функционирования, совместимость, способность к взаимодействию с пользователем, надежность, защищенность, сопровождаемость, гибкость и безопасность эксплуатации. Стандарт рассматривает эти характеристики как основу для определения, измерения и оценки качества информационно-коммуникационных и программных продуктов.

3.9.1 Функциональная пригодность

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

3.9.2 Эффективность функционирования

Эффективность функционирования характеризует соотношение между производительностью и используемыми ресурсами. К ней относятся время отклика, пропускная способность, использование вычислительных ресурсов и предельная емкость. Требование производительности должно включать операцию, нагрузку, условия и измеряемый показатель. Плохая формулировка: «Система должна обладать высокой производительностью». Корректная формулировка: «При одновременной работе 1000 пользователей время ответа на операцию поиска не должно превышать двух секунд для 95 процентов запросов». Время отклика представляет собой период между запросом пользователя и предоставлением результата. Пропускная способность показывает количество операций, обрабатываемых за единицу времени. Емкость определяет предельный объем пользователей, данных, подключений или операций. Ресурсная эффективность отражает использование процессора, оперативной памяти, сети и хранилища. Производительность должна оцениваться в условиях, соответствующих реальной эксплуатации. Результат теста на пустой базе данных не подтверждает работу системы при многолетнем объеме информации.

3.9.3 Совместимость

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

3.9.4 Способность к взаимодействию с пользователем

Данная характеристика охватывает свойства, обеспечивающие результативное, эффективное и удовлетворяющее пользователя взаимодействие с системой. К ней относятся понятность назначения, обучаемость, управляемость, защита от пользовательских ошибок, вовлеченность, доступность для различных групп пользователей и помощь пользователю. Требование «интерфейс должен быть удобным» непроверяемо. Необходимо определять конкретные показатели. Например, новый сотрудник после двухчасового обучения должен выполнить основной сценарий без помощи инструктора. Пользователь должен иметь возможность отменить ошибочно начатую операцию до ее подтверждения. Все обязательные поля должны быть явно обозначены. Защита от пользовательских ошибок включает предотвращение неправильных действий и понятную обработку ошибок. Например, перед необратимым удалением система должна запросить подтверждение и указать последствия. Доступность означает возможность использования системы людьми с различными физическими и сенсорными особенностями. Могут устанавливаться требования к управлению с клавиатуры, контрастности, текстовым описаниям и масштабированию.

3.9.5 Надежность

Надежность представляет собой способность системы выполнять требуемые функции в заданных условиях в течение установленного времени. Она включает безошибочность, доступность, отказоустойчивость и восстанавливаемость. Доступность показывает долю времени, в течение которого система готова к использованию. Требование может устанавливать: «Доступность системы должна составлять не менее 99,9 процента в месяц, за исключением согласованных периодов обслуживания». Необходимо определить, как рассчитывается показатель. Включаются ли плановые работы, с какого момента начинается отказ, какие компоненты учитываются. Отказоустойчивость означает способность продолжать работу при отказе отдельных компонентов. Например, при недоступности сервиса рекомендаций интернет-магазин может продолжать оформление заказов без персональных предложений. Восстанавливаемость определяет способность восстановить работу и данные после отказа. Используются показатели допустимого времени восстановления и допустимой точки потери данных. Например, система должна быть восстановлена не более чем за тридцать минут, а потеря подтвержденных данных не должна превышать пять минут.

3.9.6 Защищенность

Защищенность характеризует способность системы обеспечивать конфиденциальность, целостность, подлинность, учет действий и другие свойства защиты информации. Конфиденциальность означает доступность информации только уполномоченным субъектам. Целостность означает защиту данных и программ от несанкционированного изменения. Подлинность означает возможность подтвердить идентичность пользователя, системы или данных. Подотчетность обеспечивает связь действий с конкретным субъектом. Неотказуемость позволяет подтвердить совершение действия и препятствует необоснованному отказу от него. Требования безопасности должны основываться на анализе угроз и нормативных обязательствах. Например, система должна блокировать учетную запись после установленного количества неудачных попыток входа, регистрировать административные действия, шифровать конфиденциальные данные и ограничивать доступ по ролям. Формулировка «система должна быть безопасной» не имеет проверяемого смысла. Требование к журналированию должно определять регистрируемые события, состав записей, срок хранения, защиту журнала и права доступа.

3.9.7 Сопровождаемость

Сопровождаемость характеризует возможность анализа, изменения, тестирования и повторного использования системы. Она включает модульность, анализируемость, изменяемость, тестируемость и повторное использование. Модульность означает такое разделение системы, при котором изменение одного компонента оказывает ограниченное влияние на другие. Анализируемость отражает возможность определить причины ошибок и последствия изменения. Изменяемость характеризует затраты и риски внесения изменений. Тестируемость означает возможность установить критерии проверки и контролировать состояние системы. Сопровождаемость трудно оценить только по пользовательскому интерфейсу, но она существенно влияет на стоимость жизненного цикла. Требования могут устанавливать наличие автоматических тестов, документации интерфейсов, журналирования, модульной структуры и правил программирования. Например, «для всех внешних программных интерфейсов должна поддерживаться версионируемая документация» или «изменение настройки налоговой ставки не должно требовать изменения программного кода».

3.9.8 Гибкость

Гибкость в модели ISO/IEC 25010:2023 связана со способностью продукта адаптироваться, масштабироваться, устанавливаться и заменяться в различных средах. Она охватывает адаптируемость, масштабируемость, устанавливаемость и заменяемость. Адаптируемость показывает возможность приспособления к другим условиям. Масштабируемость означает способность увеличивать производительность или емкость при росте нагрузки. Устанавливаемость отражает возможность установки, удаления и обновления. Заменяемость характеризует возможность заменить другой продукт или быть замененным. Например, требование масштабируемости может устанавливать, что увеличение вычислительных ресурсов вдвое должно обеспечивать увеличение пропускной способности не менее чем на определенную величину. Требование адаптируемости может предусматривать настройку языка, часового пояса, справочников и бизнес-правил без изменения исходного кода.