Как сделать технические требования
Оформление спецификации и технических требований
Продолжаем изучать возможности программного решения nanoCAD Механика с модулем «3D-моделирование и зависимости». В предыдущей статье мы рассмотрели порядок оформления сборочного чертежа. На очереди оформление спецификации и технических требований.
Оформление спецификации
Для оформления спецификации сборки необходимо проставить позиции деталей. Сначала настроим размерный стиль позиционных выносок. Для этого воспользуемся командой MCPARAMS, вызвав ее средствами классического или ленточного интерфейса (путь в обоих случаях одинаков: Механика → Настройки). В диалоговом окне Настройки nanoCAD Механика переходим в раздел Символы, раскрываем список параметров Выноска спецификации и вложенный в него список Текст, после чего в поле Высота текста изменяем значение согласно рис. 1 и нажимаем кнопку ОК.
Рис. 1. Диалоговое окно Настройки nanoCAD Механика
Завершив настройку размерного стиля, переходим к простановке позиций. Для этого нам понадобится команда МСПОЗИЦИЯ (mcposition); вызываем ее средствами классического интерфейса (Механика → Спецификация → Позиция) или ленточного (Механика → Позиция) – рис. 2.
Рис. 2. Вызов команды МСПОЗИЦИЯ средствами классического интерфейса
После вызова команды программа предложит выбрать начальную точку – ее необходимо указать на одном из объектов в сборке (например, указываем точку на детали «Ручка крепежа» в 2D-виде – рис. 3). Далее потребуется выбрать конечную точку – там, где разместится полка выноски (рис. 4). Полку позиционной выноски можно будет видеть после закрытия диалогового окна Редактор позиций.
Рис. 3. Позиция детали «Ручка крепежа»
Рис. 4. Полка позиционной выноски
После выполнения этих действий откроется диалоговое окно Редактор позиций. Здесь нужно будет проставить значения в полях Раздел спецификации и Наименование, как показано на рис. 5. Дальнейшее заполнение полей позиций выполняется в диалоговом окне Редактор спецификаций.
Рис. 5. Диалоговое окно Редактор позиций
Когда значения проставлены, закрываем окно и проводим аналогичные действия с остальными деталями сборки. Для элементов из базы (штифты, болты и гайки) следует выбирать раздел Стандартные изделия.
Выравниваем позиционные выноски. Для этого воспользуемся функцией Выровнять выноски спецификации (команда mcposalign), вызвать которую можно в классическом или в ленточном интерфейсе. И в том и в другом случае потребуется пройти один и тот же путь: Механика → Спецификация → Выровнять выноски спецификации (рис. 6).
Рис. 6. Выравнивание выносок спецификации
После вызова функции в командной строке появится предложение указать объекты (рис. 7). Выделяем секущей рамкой необходимые позиционные выноски и нажимаем Enter. Далее программа предложит выбрать один из методов выравнивания (рис. 8) – в нашем случае щелкаем левой кнопкой мыши (ЛКМ) на опции L-Линия. С помощью ЛКМ указываем начальную и конечную точки линии (рис. 9), позиционные выноски выравниваются согласно указанной линии. Проделываем данную операцию для всех выносок. При необходимости расположение выносок можно подкорректировать вручную с помощью их «ручек». Результат выравнивания можно видеть на рис. 10.
Рис. 7. Указание объектов
Рис. 8. Выбор метода выравнивания
Рис. 9. Указание начальной и конечной точек линии выравнивания
Рис. 10. Выровненные позиционные выноски
Следующим шагом необходимо открыть панель Спецификация. Для этого воспользуемся командой showtabspec, вызвав ее в классическом интерфейсе (щелчок правой кнопкой мыши (ПКМ) на пустом пространстве закрепленных вкладок→ Функциональные панели → Спецификация) – рис. 11.
Рис. 11. Функциональная панель Спецификация
Привяжем формат к спецификации. Для этого переходим в лист А1 с чертежом и в панели Спецификация щелкаем ПКМпо строке Сборочная единица. В контекстном меню выбираем Формат → Привязать формат (рис. 12) и с помощью ЛКМ выбираем штамп форматки. Формат привяжется к спецификации, что позволит сэкономить время при ее последующем заполнении. Результат привязки можно видеть на рис. 13.
Рис. 12. Привязка формата
Рис. 13. Спецификация с привязанным форматом
Далее следует войти в Редактор спецификации. Вызвать его можно командой МССПЕЦФ (mcspecification) либо в классическом интерфейсе (Механика → Спецификация → Редактор спецификации), либо в ленточном(Механика → Редактор спецификации) – рис. 14.
Рис. 14. Редактор спецификации
В диалоговом окне Редактор спецификаций можно редактировать данные позиционных выносок. Для выбора спецификации щелкнем ЛКМ по ДП 24.05.07.001.500-19СБ Ложемент в левой части окна, после чего откроется список позиций, привязанных к формату (рис. 15).
Рис. 15. Диалоговое окно Редактор спецификаций
Заполняем поля позиций, как это показано на рис. 16.
Рис. 16. Заполненные позиции
Далее необходимо расставить номера позиций и отсортировать их по алфавиту – воспользуемся для этого функциями Сортировать (рис. 17) и Расставить позиции (рис. 18).
Рис. 17. Расстановка позиций по алфавиту
Рис. 18. Расстановка номеров позиций
Добавим запись в Сборочные единицы. Для этого щелкаем ПКМ по графе Сборочные единицы и выбираем опцию Добавить запись. После этого нажимаем на появившийся слева значок «+» и заполняем поля в соответствии с рис. 19.
Рис. 19. Сборочная единица
Теперь спецификацию необходимо вставить в пространство листа А4. Закрываем диалоговое окно Редактор спецификаций и щелкаем ЛКМ по вкладке А4 (рис. 20).
Снова открыв диалоговое окно Редактор спецификаций, выбираем спецификацию, указанную слева, и вызываем функцию Экспорт в чертеж (рис. 21).
Рис. 21. Экспорт в чертеж
После вызова появится диалоговое окно Заголовок чертежа, в котором можно выбирать позиции основной, справочной и инвентарной надписей (рис. 22). Поскольку мы привязали формат к спецификации, необходимые поля заполнились автоматически. Нажимаем ОК, после чего спецификация отобразится в пространстве листа и нужно будет выбрать точку вставки. Результат вставки спецификации показан на рис. 23.
Рис. 22. Диалоговое окно Заголовок чертежа
Рис. 23. Спецификация после вставки в пространство листа
Осталось лишь отредактировать значение поля Лист в штампе спецификации. Этот штамп открывается, как и штамп чертежа, двойным нажатием ЛКМ. В диалоговом окне Редактирование таблицы вписываем в поле Лист значение 2 и закрываем окно (рис. 24). Оформленная спецификация представлена на рис. 25.
Рис. 24. Редактирование значения поля в диалоговом окне Редактирование таблицы
Рис. 25. Полностью оформленная спецификация
Оформление технических требований
Создаем технические требования (ТТ) сборки. Для этого переходим в Модель и вызываем команду МСТЕХТРЕБ (MCTT) либо в классическом интерфейсе, либо в ленточном (в обоих случаях понадобится пройти один и тот же путь: Механика → Форматы → Тех. Требования) – рис. 26.
Рис. 26. Технические требования
Для начала настраиваем высоту текста ТТ. Нажимаем кнопку Настройки в окне Технические требования, в открывшемся окне Настройки nanoCAD Механика изменяем на 40 значение в поле Высота текста и нажимаем ОК (рис. 27).
Рис. 27. Настройка высоты текста технических требований
Далее в окне Технические требования вносим данные, представленные на рис. 28. Для вставки часто используемых требований (например, «Размеры для справок») можно воспользоваться Записной книжкой и ее полем поиска (рис. 29), а для вставки спецсимволов – кнопкой Вставить спецсимволы (рис. 30). Чтобы создать ссылку на позицию 6, в поле ввода нажимаем ПКМ → Взять с чертежа, в окне Выбор значения выбираем Взять из свойства (В), с помощью ЛКМ выбираем в пространстве модели позиционную выноску 6. Нажимаем Enter, в окне Свойства выбираем Позиция 1-6 и нажимаем ОК. Ссылка на выбранную позицию, выделенная синим цветом, появляется в ТТ (рис. 31).
Рис. 28. Заполненные технические требования
Рис. 29. Записная книжка и поле поиска
Рис. 30. Вставка спецсимволов
Рис. 31. Создание ссылки на позицию в технических требованиях с помощью функции Взять с чертежа
После заполнения ТТ нажимаем кнопку Разместить (рис. 32) и с помощью ЛКМпоследовательно выбираем левый верхний и правый нижний углы границ их вставки – как это показано на рис. 33. При необходимости границы вставленных ТТ можно изменить с помощью «ручек».
Рис. 32. Кнопка Разместить
Рис. 33. Границы вставки технических требований
Перемещаемся в лист А1, двойным нажатием ЛКМзаходим в видовой экран и корректируем расположение ТТ с помощью «ручек». Оформленный чертеж с ТТ в листе А1 представлен на рис. 34.
Рис. 34. Оформленный чертеж с техническими требованиями
Чтобы рассмотреть окончательный вариант оформленного чертежа с эскизом, 3D-моделью сборки, привязками, спецификацией и техническими требованиями, откройте файл Оформление спецификации и технических требований.dwg, прилагаемый к данному материалу.
На этом мы завершаем обзор функционала 3D-моделирования, зависимостей и оформления конструкторской документации nanoCAD Механика. До скорых встреч!
Ликбез по техническому заданию
Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.
Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).
Время чтения: 7 минут.
Отправная точка — требования
Хочу пирожное, потом морожное!
Вовка в тридевятом царстве
Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.
К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег.
Жутко правда? Бюджет уже потрачен и срок истек.
Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
Удобный вид требований — ТЗ
Замесить и нарубить!
Вовка в тридевятом царстве
Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.
Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.
Рецепт грамотного ТЗ
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
Концептуальная модель
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
Функциональная карта
Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.
Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
Путь пользователя
Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.
Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
Пользовательский интерфейс
Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
Программные интерфейсы
Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
Нефункциональные требования
Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
В требованиях к безопасности можно указать, что передача данных в чате должна осуществлять с помощью шифрования SHA-1 и что при регистрации сложность пароля должна быть не менее 8 бит.В требованиях к производительности говорится о связи компонентов и отказоустойчивости, например стоит указать, что таймаут на чтение сообщения в чате не более 1 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.