Создание эффективного инженерного документа требований (ERD): пошаговое руководство

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

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

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

Стандартные критерии для инженерного документа требований

Для начала, все эффективные инженерные документы требований имеют следующие шесть элементов общими:

Ясность

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

Необходимость

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

Координация

Инженерные требования должны быть правильными на протяжении всего дизайна продукта. ERD должен описывать все требования, цели, условия и возможности продукта. Когда возможно, объясняйте, что делает продукт, числовым способом для максимальной точности.

Проверяемость

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

Выполнимость

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

Прослеживаемость

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

Советы по написанию хорошего инженерного документа требований

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

Используйте шаблон инженерного документа требований

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

Избегайте написания операций и реализаций

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

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

Оцените ваш ERD

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

Используйте правильный язык

Есть некоторые языковые правила, которые всегда должны следовать при написании инженерного документа требований. Три больших ERD-специфических термина — shall, will, и should. «Shall» представляет требования, «will» представляет факты, а «should» представляет цели.

Специфический ERD-термин, который часто используется неправильно — support. В терминах ERD, «support» ссылается на способность структуры держать или выдерживать вес, а не на то, что она будет поддерживать или выполнять определенные возможности.

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

• But not limited to или etc. — Эти термины покрывают неизвестное, и в вашем ERD не должно быть ничего неизвестного или непредсказуемого.
• And/or — Это оставляет слишком много вариантов для интерпретации и пространство для ошибки, потому что подрядчик будет прав в двух разных сценариях (если они выберут AND или если они выберут OR).
• Слабые слова, не имеющие количественных значений. Это включает прилагательные вроде «мощный» и «эффективный», а также глаголы вроде «улучшить» или «усилить». Также старайтесь избегать сравнений (например, быстро или медленно, большинство или мало) и другого неколичественного языка.

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

Не будьте чрезмерно специфичными

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

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

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

Для дополнительных ресурсов по разработке продуктов, посетите центр обучения Fast Radius.

Готовы изготовить свои детали с Fast Radius?

Начните расчет стоимости