Среди изученных мной классификаций требований я не нашел ту, которая наиболее полно описывала целостную структуру требований к системе и их взаимное влияние. Однако, полученная информация в совокупности позволяет сформировать представление о структуре требований к системе в целом и использовать рекомендации по видам требований для подготовки более качественного аналитического материала. Многие опытные аналитики знают, что частой проблемой IT проектов является передокументирование - ситуация, когда на разработку документации тратится огромное количество ресурсов, при этом объема информации значительно больше, чем требуется для разработки самой системы. В таком случае, мне видится, что первоочередной задачей является оценка необходимости и достаточности того или иного вида требований. Эта задача может быть решена только понимая, как тот или иной вид требований влияет на конечный программный продукт, учитывая его назначение, стадию реализации, состав и квалификацию команды, модель разработки и другие факторы.

Понятие “Уровень требований”

В различных классификациях понятие “Уровень требований” или “Уровень детализации” либо отсутствует вовсе, либо не имеет определения, хотя сами виды требований по уровням распределены. Чтобы исключить двусмысленность при освещении темы приведу мое личное понимание термина и буду придерживаться его. Уровень требований - это глубина детализации описания системы, процесса ее проектирования и разработки в зависимости от стадии, на которой находится проект.

Почему я рассматриваю требования к проекту и продукту, почему продуктом выбрана АС?

Разработка программного продукта или в более широком смысле автоматизированной системы это всегда проект. Выпустить продукт к определенному сроку, решающий конкретные задачи - формулировка полностью соответствующая заветам SMART (методика постановки целей). Проработав структуру требований к наиболее общему случаю, всегда можно трансформировать ее к частному или дополнить, для исключительных ситуаций. Сама информационная система это симбиоз программных, аппаратных средств, людей и любой информации, относящейся к предметной области системы.

Структура требований к программному обеспечению. Общая схема.

Почему я придерживаюсь трехуровневой структуры требований?

В отдельных документах ГОСТа на разработку ПО определяются 2 уровня требований, которые характеризуются максимально размыто: верхний уровень требований и нижний уровень требований. Четких правил определения видов требований на тот или иной уровень мне найти не удалось. Лишь косвенно можно судить, что верхний уровень содержит более общее описание продукта, без технических подробностей, а нижний, соответственно, более детализирован. Карл Вигерс и Дин Леффингуэлл приводят описание трехуровневой структуры требований. Несмотря на некоторые различия в названиях видов требований, размещенных на уровнях, обе концепции объединяет последовательность формирования требований на каждом из уровней и их четкая взаимная зависимость друг от друга. Дробление структуры на большее количество уровней потребует наличия однозначных критериев для определения в них требований, и как мне кажется, является избыточным, поскольку на каждом уровне требований должны быть сформированы  артефакты (документы), необходимые на текущей стадии проекта. Трехуровневая структура наилучшим образом соотносится с процессами сбора, формирования и управления изменениями требований вне зависимости от применяемой на проекте методологии, например водопад или SCRUM.

I уровень требований

Верхним уровнем требований (первым) являются бизнес-требования. Тезисы с которых начинается IT проект и последующее обсуждение будущего продукта. 

Бизнес-требования содержат высокоуровневые цели (потребности) заказчиков системы. Во многих подходах к классификации требований бизнес-требования являются основополагающими, их часто относят к области проблемы, идее. На основе бизнес-требований, как правило, невозможно произвести оценку трудоемкости проекта, однако они определяют ценность продукта и ограничивают требования и фантазии пользователей. Первый уровень требований находит свое отражение в таких документах как: vision, концепция автоматизированной системы, дорожная карта и т.п.

II уровень требований

Второй уровень включает в себя два вида требований: требования пользователей и бизнес-правила. 

Пользовательские требования описывают цели и задачи, которые система позволит решить пользователям. Существует множество подходов к описанию пользовательских требований. Для примера приведу некоторые из них: user story, use cases, модели и описание бизнес процессов, тезисный список пожеланий. Так или иначе, в основе лежит изучение предметной области в тех границах, которые очерчены бизнес-требованиями. Безусловно, выходить за пределы границ при анализе приходится, но конечная реализация должна соответствовать исходным целям бизнеса.

Бизнес-правила описывают корпоративные политики, правительственные постановления, промышленные стандарты, вычислительные алгоритмы и, как правило, сами по себе являются артефактами (документами). Их очень часто относят к нефункциональным требованиям. Я намеренно на схеме разместил бизнес-правила и функциональные требования на разных уровнях. По большому счету, бизнес-правила существую скорее как свойства предметной области, они не появились просто так и не стали продуктом творчества проектировщиков продукта. В этой связи, изучать и анализировать их следует в контексте связанных бизнес-процессов и пользовательских сценариев, чтобы учесть в будущем в функциональных требованиях и ограничениях системы.

Пользовательские требования можно использовать для предварительной оценки трудозатрат, но следует принимать во внимание возможные риски, связанные с изменением процессов работы пользователей, корректировкой бизнес-правил. К счастью, при должном описании требований на этом уровне, управлять изменениями можно без существенных потерь.

III уровень требований

Третий уровень самый насыщенный. Пять групп требований описывают систему и процессы, связанные с выпуском продукта. Именно на основе требований третьего уровня и будет разрабатываться будущий продукт. В современной литературе часто выделяют всего три группы требований: функциональные, нефункциональные, системные. На практике же, приходится сталкиваться с дополнительными характеристиками системы и процесса ее разработки, которые не находят по разным причинам своего отражения в проектной документации, что в конечном счете приводит к незапланированному изменению объемов работ.

Группа функциональных требований

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

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

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

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

Эмерджентные свойства описывают требования, которые не относятся к отдельным функциям системы, а проявляются в результате выполнения совокупности функций (иногда совершенно независимых друг от друга). Являются свойствами целостности системы. В большинстве классификаций, такие свойства не рассматриваются как отдельный вид требований, однако, при определенных обстоятельствах, наличие и понимание таких свойств может определять логику взаимодействия отдельных элементов системы друг с другом или же системы в целом с внешним миром.

Группа системных требований и ограничений

Системные требования и ограничения определяют общие для всей системы характеристики. В данную группу входят целевые показатели системы, требования к структуре и функционированию системы, эргономике, технической эстетике и usabilty (UX).

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

Структура и функционирование системы отражает требуемый компонентный состав системы, перечень программных и аппаратных средств, режим функционирования системы в целом и ее компонентов. 

Эргономика, техническая эстетика, удобство использования (UX) - это, как правило, общие требования к реализации интерфейсов, применению цветовых схем, гарнитур шрифтов, наличию общих функций для отдельных компонентов пользовательского интерфейса, а также требования к организации рабочего пространства и установки оборудования. Данные требования направлены на повышение эффективности использования разрабатываемой системы.

Группа нефункциональных требований

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

Атрибуты качества описывают способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени. Стандарт ISO 9126 содержит характеристики и атрибуты качества, а также метрики для их оценки. Часть атрибутов качества из ISO может быть неприменима к разрабатываемой системе, часть атрибутов будет обусловлена назначением и областью применения продукта.

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

Требования безопасности системы подразумевают не только информационную безопасность, но и правила безопасности использования входящего в систему оборудования.

Требования к сохранности (данных) содержат описание функций и свойств системы по сохранности и восстановления данных при сбоях, правила длительного хранения, архивирования исторических данных.

Группа требований к внешним интерфейсам

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

Требования к интерфейсам пользователя (UI) очень часто ограничиваются только макетами или скетчами, реже подготовкой прототипов. На самом же деле, макеты и прототипы необходимо дополнять описанием поведения компонентов интерфейса, или формировать типовые компоненты, с однозначно определенным поведением.

Требования к программным интерфейсам указывают на особенности системы к взаимодействию модулей и компонентов системы друг с другом, а также правила и форматы взаимодействия системы с внешним миром (другими системами например). 

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

Требования к интерфейсам связи и коммуникации - это требования к каналам и протоколам передачи данных из системы и к системе, а также между распределенными узлами системы при их наличии.

Группа требований к видам обеспечения

Требования к видам обеспечения больше относится к процессам проектирования, разработки, внедрения и сопровождения системы, нежели к самой системе.

Требования к программному обеспечению обычно включают наименования, характеристики, версии ПО, используемого в разработке, сопровождении, тестировании, мониторинге, а также в качестве отдельных элементов системы (включая серверные операционные системы, СУБД, конверторы данных и прочее).

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

Требования к информационному обеспечению описывают совокупность системы классификации и кодирования информации, унифицированных систем документации и информационных массивов. К числу объектов, к которым могут предъявляться требования относятся не только базы данных самой системы, способы ее ведения, кодирования и обновления, но и любые информационные носители (в том числе и физические документы предметной области) относящиеся к процессу эксплуатации системы.

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

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

Требования к методическому обеспечению описывают состав нормативно-технической документации системы, количество и содержание руководств для пользователей и администраторов, методики.

Выводы

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