Секреты успешных НИОКР

2. Промышленные, производственные и испытательные требования.

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

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

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

• Измеримость, когда характеристика выражается объективно и количественно, может быть проверена при испытании.

• Достижимость, техническая реализуемость при доступных затратах, параметры элементов должны соответствовать законам физики и современным технологиям.

• Прослеживаемость, когда требования нижнего «дочернего» уровня должны четко вытекать из требований более высокого «родительского» уровня. Требования, не имеющие «родителей», должны быть оценены для необходимости включения на данный уровень.

При выполнении анализа требования полезно классифицировать, разделяя на основные типы.

1. Функциональные требования, отвечающие на вопрос «что система должна делать?» Например, обеспечить связь между землей и самолетом.

2. Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?»

3. Экологические/нефункциональные требования (сценарии использования), отвечающие на вопрос «при каких условиях (экологии, надежности и доступности) система должна работать для удовлетворения данного требования?»

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

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

6. Требования к качеству (включая требования к безопасности).

7. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).

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

Функциональные (эксплуатационные) требования к системе должны включать следующие основные позиции.

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

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

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

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

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

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

Цепочка проектирования системы (продукта) включает несколько шагов определения и разработки требований.

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

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

3. Сформировать производные требования.

4. Определить методы верификации требований.

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

Одним из видов требований нижних уровней являются производные требования.

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

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

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

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

Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует избегать в предложении для ОКР:

• хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;

• лазеек, выражений типа «если это необходимо», поскольку они делают требование бесполезным;

• помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;

• неконкретных рассуждений;

• нечетких слов, таких как «обычно», «в основном», «часто», «нормально», «типично»;

• использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);

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

При написании детальных требований к системе используют, в частности, функцию развертывания качества (quality function deployment, QFD). Она переводит потребительские качества, желаемые пользователем, в технические функции и средства для их реализации и развертывания доступных ресурсов при создании продукта или услуги [2]. Метод QFD основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуют в технические. Технические характеристики преобразуют в характеристики компонентов, далее в характеристики процессов и, в завершение, в характеристики контроля продукта. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве.

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

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

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

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

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

1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.

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

3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.

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

5. Требования к интерфейсу включают логические и физические интерфейсы.

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

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

В результате процесса разработки формируется набор требований, который должен быть выполнен при создании продукта или системы. Этот завершающий комплект требований содержится в документах контракта, спецификациях или технических заданиях на выполнение работ (statement of work, SOW). Характеристики этого набора будут идентичны вышеописанным пунктам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным, то есть не нуждается в дополнительных пунктах требований. Входящие в него требования должны быть согласованными, то есть не содержат противоречий, дублирований, и др. Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 2.2).

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