Техническое задание и границы проекта
Цель: Научиться превращать идею электронного устройства в проверяемое техническое задание: функции, входы/выходы, питание, точность, среду, ограничения, безопасность и критерии готовности.
3 часа короткая теория, самостоятельная практика, проверка результата и тест.
Суть темы
Проект начинается не со схемы, а с вопроса: что устройство должно делать и в каких условиях. Фраза «сделать хороший измеритель температуры» не является техническим требованием, потому что не задаёт диапазон, точность, скорость обновления, интерфейс, питание и критерий приёмки.
Хорошее техническое задание отделяет обязательные функции от пожеланий и явно фиксирует границы проекта: что входит в изделие, что предоставляет внешняя система и какие режимы не поддерживаются. Это защищает от бесконечного изменения цели во время разработки.
- Функциональные требования описывают действия устройства и внешнее наблюдаемое поведение.
- Интерфейсные требования задают уровни, разъёмы, протоколы, нагрузку и направление сигналов.
- Параметрические требования должны быть измеримы: диапазон, accuracy, bandwidth, time, power, temperature.
- Ограничения включают стоимость, размеры, компоненты, нормативные требования, питание и условия эксплуатации.
- Критерии приёмки заранее определяют, каким тестом будет доказано выполнение каждого важного требования.
Ключевые связи и параметры
Требование должно быть однозначным и проверяемым. «Низкое энергопотребление» превращают, например, в «не более 50 мА от 5 В в рабочем режиме и не более 100 мкА в sleep при 25°C» — если именно такие значения подтверждены задачей. Числа в реальном проекте берутся из потребности, а не придумываются для красивого документа.
Requirements имеют приоритеты и связи. Если требуется 24-bit ADC resolution, это ещё не означает 24-bit absolute accuracy; ТЗ должно говорить о нужной измерительной характеристике, а техническое решение выбирается позже. Аналогично «USB разъём» не описывает автоматически protocol, power role и isolation.
Разбор примера
Плохо: `измерять температуру точно`. Лучше: `измерять −10…+80°C, погрешность системы не более ±1°C в диапазоне 0…60°C, обновление не реже 1 раза/с, питание 5 V USB, результат выдавать по UART 115200 8N1`. Такие требования можно превратить в test cases.
Граница проекта: sensor и PCB входят в изделие, внешний PC и terminal software — нет; устройство не предназначено для работы во влажной среде и не имеет galvanic isolation. Явные границы предотвращают скрытые ожидания.
Практическая работа и проверка
Возьмите простую идею, например регистратор температуры, и перепишите её в 10–15 измеримых требований.
- Опишите основную функцию одним предложением.
- Составьте перечень inputs/outputs и interfaces.
- Задайте measurable electrical/performance ranges.
- Зафиксируйте environment, size/cost/power constraints и safety boundary.
- Для пяти требований сразу напишите acceptance test.
Типичные ошибки и диагностика
- Начинать schematic, не согласовав функции и ограничения.
- Писать качественные слова «быстро/точно/надёжно» без измеримого критерия.
- Смешивать requirement и конкретное техническое решение, когда решение ещё можно выбирать.
- Не фиксировать, что явно находится вне scope.
Если проект постоянно «ползёт», сравните новые пожелания с исходным scope. Если два инженера понимают requirement по-разному, оно недостаточно однозначно и требует уточнения до следующей итерации.
Связь с реальным устройством
Техническое задание превращает идею в набор проверяемых обязательств и становится основой расчёта, архитектуры и финальных испытаний.
Что нужно запомнить
- Требование должно быть проверяемым.
- Функция и реализация — не одно и то же.
- Интерфейс описывает и электрический, и логический аспект.
- Scope фиксирует границы проекта.
- Acceptance test должен следовать из требования.