Формулирование требований к проектируемой системе

Формулирование требований является ключевым моментом в проектировании АСОИУ. Этому вопросу посвящена специальная литература, например, [6, 43, 50, 86]. Карл Вигерс и Джой Битти представили фундаментальное 736-страничное исследование, посвященное разработке требований к ПО. Первое издание этих авторов по данной тематике датировано 1999 г.

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

Все требования к будущей АСОИУ принципиально можно разделить на две группы: 1) функциональные требования; 2) другие требования. Функциональные требования обусловливают алгоритмическую составляющую, которая должна быть реализована в готовом программном продукте. Поэтому они являются определяющими. К другим требованиям могут, в частности, относиться:

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

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

Основные факторы, создающие проблемы в будущих проектах по созданию АСОИУ [50, с. 35]:

• • недостаток исходной информации от клиента (13% всех проектов);
• • неполные требования и спецификации (12% проектов);
• • изменение требований и спецификаций (12% проектов).

«Все современные методологии разработки предполагают возможность изменения требований в ходе разработки, т. е. процесс управления требованиями не заканчивается с разработкой ТЗ и внутренних спецификаций системы, а продолжается на протяжении всего ЖЦ ПС и заключается в управлении изменениями в требованиях. При этом необходимо помнить, что всякое изменение в требованиях связано с изменением стоимости и сроков выполнения проекта и может влиять на качество ПС» [24, с. 132]. Тем не менее, базовый объем требований должен быть выявлен к началу проекта по созданию АСОИУ.

По мнению Карла Вигерса и Джой Битти (со ссылкой на Иена Соммервилля и Пита Сойера, 1997 г.), под требованиями следует понимать спецификацию того, «…что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы» [6, с. 5].

«Требования являются основой для любого проекта. Они определяют те потребности „заинтересованных сторон“ (stakeholders) — пользователей, потребителей, поставщиков, разработчиков и самого бизнеса, которые являются для них необходимыми, а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти потребности» [86, с. 2]. Далее авторы приводят таблицы, в которых указаны основные причины неудачных и удачных проектов (рис. 2.1). Точками отмечены причины, связанные непосредственно с требованиями.

Рис. 2.1. Причины удачных и неудачных проектов [86, с. 3].

Поскольку любая АСОИУ по своему назначению всегда является прикладной, все требования к ней должны исходить от тех категорий специалистов, которые будут взаимодействовать с будущей системой в самых разных аспектах на этапах ее проектирования, разработки, тестирования и эксплуатации. Наиболее полный список возможных заинтересованных лиц показан на рис. 2.2. Однако очевидно, что в зависимости от специфики проекта не в каждом из них будут принимать участие все представленные на рисунке заинтересованные лица. Их качественный и количественный состав является вариативным и определяется, в частности:

• • масштабом проекта (объемом его функциональности);
• • внутренними особенностями объекта автоматизации (используемые производственные и управленческие технологии);
• • особенностями взаимодействия объекта автоматизации со смежными системами и организациями;
• • управлением проектом;
• • профессионально-квалификационным уровнем команды разработчика.

Рис. 2.2. Возможные заинтересованные лица в команде проекта, в разрабатывающей организации и за пределами организации [6, с. 29]

В работе [40] отмечается, что формирование требований к автоматизированным системам является наиболее трудной частью процесса проектирования и разработки АСОИУ и часто сопровождается следующими проблемами:

• «сложно получить исчерпывающую информацию от заказчика для оценки требований;

• • требования от различных заинтересованных лиц могут быть противоречивыми;
• • требования не всегда ясны и имеют много источников происхождения;
• • заказчик, как правило, не является ИТ-специалистом и может формулировать требования вне возможностей информационных технологий;
• • число требований может быть огромным (и разной степени детализации) и вследствие этого неуправляемым;
• • требования изменяются и т. д." [40, с. 137—138].

В дополнение к перечисленным проблемам можно добавить ряд других, которые также сопутствуют процессу формулирования требований и приведены в [6, с. 21—23]:

• • недостаточно активное вовлечение пользователей;
• • небрежное планирование, т. е. плохо продуманные и поэтому часто меняющиеся требования;
• • «разрастание» требований, т. е. сроки и бюджет проектирования и разработки системы не должны вступать в противоречие;
• • двусмысленные требования, т. е. неоднозначная интерпретация однотипных требований разными пользователями. В качестве решения предложено для таких случаев приглашать экспертов с целью унификации «разных трактовок»;
• • требования — «бантики». Под ними авторы понимают функции, которые привносят в проект разработчики по собственной инициативе, полагая, что их предложения должны понравиться заказчику. Особенно это касается «красивостей» интерфейса. Между тем любые излишества (включая дополнительную функциональность) не могут включаться в проект без разрешения заказчика;
• • пропущенные классы пользователей. При выявлении и анализе требований какие-либо группы потенциальных пользователей, например, не принимали участие в анкетировании или не были опрошены при проведении интервью.

В работе [50] приводится рисунок (рис. 2.3), который демонстрирует такую зависимость «…если стоимость усилий, необходимых для обнаружения и устранения ошибки на стадии написания кода принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5—10 раз меньше. А стоимость обнаружения и устранения ошибки на стадии сопровождения — в 20 раз больше» [50, с. 37]. Авторы особо выделяют две категории ошибок, которые обнаруживаются на стадии проектирования [50, с. 38]:

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

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

Рис. 2.3. Относительная стоимость устранения ошибки в различных фазах жизненного цикла [50, с. 38].

Аналогичная точка зрения на как можно более раннее выявление требований излагается в работе [86]. «На вопрос „В соответствии с чем должны выполняться приемочные испытания?“ напрашивается ответ — „в соответствии с пользовательскими требованиями (stakeholder requirements)“. Сразу становится очевидным, что требования, разработанные в самом начале проекта, так или иначе, используются на его самом последнем этапе» [86, с. 8]. Авторы рассматривают классическую V-модель («ви-моделъ»), которая описывает различные стадии проекта и в основном базируется на связи между требованиями и их тестированием. «V-модель также отображает системную разработку в терминах уровней (layers), где каждый уровень соотноситься с определенным этапом разработки. Несмотря на то, что на каждом уровне может быть использовано несколько различных процессов, основной принцип работы с требованиями не меняется» [5, с. 9] (рис. 2.4).

Карл Вигерс и Джой Битти рассматривают различные типы требований. При этом авторы обращают внимание на очень важный аспект — взаимосвязь между требованиями (рис. 2.5).

Таким образом, выгоды от высококачественного процесса разработки требований способствуют:

• • выполнению проекта в рамках установленных сроков и бюджета;
• • минимизации возможных переделок в проекте;
• • уменьшению стоимости последующей модернизации системы;
• • высокому уровню валидации реализованного проекта.

Рис. 2.4. Уровни разработки требований [5, с. 9]

Рис. 2.5. Типы требований [6, с. 5].