Документ спецификация: Образец спецификации на поставку товара 2021 года + Бланк

Ниже приводится пример функциональной спецификации:

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

Располагается так:

Пример использования : подать заявку

Действующий субъект : Заказчик

Описание : Описывает процесс подачи заявки на кредитную карту

Успешное завершение :

1. Пользователь вводит информацию о приложении, включая дату рождения.
2. Система проверяет ввод на наличие ошибок при вводе данных
3. Затем система отправляет заявку.

Альтернатива : система отклоняет подачу заявки, ссылаясь на ошибку в форме для даты рождения.

Предварительное условие : Пользователь был направлен к заявке на получение кредитной карты из объявления, отправленного по электронной почте, или объявления на веб-сайте.

Постусловие : пользователь получает сообщение об успешном выполнении.

Допущения : Нет

Что такое функциональная спецификация? | by Essential Designs

Важные первые шаги при создании приложения

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

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

Кто это пишет?

FSD, создаваемые в начале каждого проекта, являются результатом совместных усилий команды разработчиков и группы дизайнеров UI / UX.Причин для этого несколько:

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

Что в нем происходит?

В ED мы объединяем функциональные требования и сценарии использования, а также истории пользователей, чтобы получить объединенное ожидание потока проекта и функций в целом.

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

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

FSD Изменения и дополнения

Когда документ доставляется клиенту, клиент должен:

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

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

   Мэри Макферсон, менеджер по цифровому маркетингу @Essential Designs

   Мэри — популярный диджей Ванкувера, работающая в сфере высоких технологий с момента своего основания в качестве веб-разработчика в Newbridge Networks в 1996 году.

   Как писать документы для проектирования программного обеспечения: с примерами

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

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

   * Примечание. * Здесь я описываю небольших клиентов, которые хотят получить от своего разработчика единоличную армию. Это не единственный путь, по которому может пойти фрилансер, и это не единственные клиенты, с которыми мы работаем в Toptal, но это тот путь, который мне нравится больше всего.Конечно, если вы работаете в команде, а не в одиночку, некоторые из перечисленных ниже не применимы. Например, если вы используете методологии Agile или Scrum, вы, вероятно, захотите немного по-другому структурировать свои этапы.

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

   Вы все слышали о первостепенной важности общения.Вы не сможете работать, получив по Skype несколько предложений с кратким описанием и сказав : «Увидимся через три месяца, когда я закончу». Вы должны поддерживать связь со своим клиентом и на каждом этапе своей работы удостовериться, что у вас есть согласованные представления о цели, потому что действительно редко, когда клиент отправляет вам макеты и подробную функциональную спецификацию. Вы получите очень общее представление о том, что программное обеспечение должно делать, как должно выглядеть и работать. Если вы напишете приложение на основе беглого описания, с которого обычно начинаете, почти нет шансов, что ваш клиент будет доволен результатом.На каждом этапе вы должны приближаться к соглашению.

   Вы не можете работать, получив по Skype несколько предложений с кратким описанием и сказав: «Увидимся через три месяца, когда я закончу».

   Работая в течение многих лет в компаниях, которые сами занимались разработкой программного обеспечения, где все члены команды принадлежали к одной культуре, говорили на одном родном языке, работали в одном коридоре, ежедневно встречались и т. Д., Было примечательно, что компания по-прежнему не получала то, что хотела, в половине случаев.Не заблуждайтесь: задача здесь огромна.

   Почему документы для разработки программного обеспечения имеют значение

   Итак, когда вы беретесь за новый проект , прежде чем даже откроете Xcode или Visual Studio, вам необходимо иметь четкие и согласованные цели дизайна . И эти цели должны быть установлены в документе спецификации. Если клиент еще не написал его, вам следует написать его и отправить ему на рассмотрение, прежде чем вы даже откроете свою среду IDE. И , если вы встречаетесь с клиентом, который откровенно говорит: «У нас нет времени на проектную документацию», вам следует отказаться от проекта , потому что впереди вас ждут проблемы.Спецификация не должна быть особенно длинной; это может быть всего несколько страниц, но, по крайней мере, он должен содержать макет пользовательского интерфейса, включать каркасы (если есть компонент пользовательского интерфейса) и устанавливать этапы завершения.

   Без этого документа вы попадете в петлю язвительных двусмысленностей: клиенты будут оспаривать то, что они рассказали вам или то, что вы им сказали, сердито посылая вырезки из предыдущих сообщений, интерпретируя и спорив до тех пор, пока не придет время, когда клиент требует, чтобы вы внесли изменения, чтобы приложение соответствовало «тому, что он действительно просил», и ожидает, что вы внесете эти изменения бесплатно.

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

   Мы все хотим довольных клиентов.Мы все хотим дружеских рабочих отношений. И все мы хотим гордиться хорошо выполненной работой. Но этого невозможно достичь, если есть хоть какая-то неясность в том, что на самом деле — это . Если ваш клиент говорит, что проектный документ — это слишком много лишней работы, ваша работа — объяснить им, что настоящая дополнительная работа появится, когда потребуется внести исправления из-за какого-то недоразумения. Если клиент по-прежнему настаивает на том, чтобы вы продвигались без такого документа, вы должны принять тот факт, что у вас неработающие отношения, и уйти.

   Что на самом деле должно указывать в спецификации разработки программного обеспечения?

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

   Пользовательский интерфейс

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

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

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

   1. Всегда ли элементы управления видны и / или включены? При каких условиях меняются их состояния?
   2. Похоже на растровое изображение — это кнопка?
   3. Какие переходы происходят между этими состояниями и представлениями? А как их анимировать?

   Если вам нужно создать пользовательский интерфейс для согласования с клиентом, сделайте то же самое в обратном порядке: используйте инструмент каркаса и создайте полный набор макетов экрана, включая любые варианты, которые представления отображаются в разных состояниях приложения.Это может быть исчерпывающая и утомительная работа, но вы не пожалеете об этом — она ​​может избавить вас от переписывания огромных объемов кода и воссоздания интерфейсов из-за небольшого недоразумения с серьезными последствиями. Если вы создаете двойное приложение (например, для iPhone и iPad), создайте отдельные каркасы для обоих.

   Размеры экрана тоже важны. Есть (на момент написания) три размера экранов iPhone. Отдельные каркасы для экранов 3,5 и 4 дюйма, вероятно, излишни, но вам, возможно, придется их сделать; в большинстве случаев можно просто изменить пропорции.

   Если ваш клиент предоставляет вам графику, убедитесь, что у нее правильный размер и правильное соотношение сторон; преобразование любого растрового изображения, содержащего текст или объекты (например, круги), приведет к искажениям. Если они не совпадают, попросите клиента воссоздать их с соответствующими размерами. Не думайте, что вы можете растянуть экран-заставку размером 3,5 дюйма до заставки размером 4 дюйма и просто кататься вместе с ним.

   Функциональность

   Ключевые вопросы, которые следует задать в проектном документе приложения:

   • Что делает приложение и как быстро оно это делает?
   • Каковы возможные состояния отказа и как они обрабатываются?
   • Какие разовые операции выполняются при первом выполнении (т.е., после установки)?
   • Если пользователь создает какие-либо записи (например, закладки), каковы ограничения?

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

   Вехи

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

   Пример спецификации проектирования программного обеспечения

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

   Заявление о целях

   Включите короткий абзац с описанием проекта и его целевой аудитории.

   Функциональное описание

   Что делает приложение ? С какими состояниями приложения (высокоуровневыми описаниями основных пользовательских сценариев) столкнется пользователь?

   Например, ваше функциональное описание может выглядеть так:

   • Первый запуск
   • Создание нового _____ (игра, поиск и т. Д.)
   • Операции
   • Поведение фона и переднего плана

   Пользовательский интерфейс

   Включите каркасы для каждой страницы с подробным описанием:

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

   Вот макеты, относящиеся к моему последнему приложению для iOS, NotifEye:

   Если вам интересно, я сделал эти макеты с помощью инструмента каркасного моделирования Balsamiq.

   Например, описание вашего пользовательского интерфейса может выглядеть так:

   • Панель навигации
     • Левый элемент управления: возврат на главную страницу
     • Строка заголовка: текущий экран или название операции
     • Новая кнопка: создать новую вещь
   • Просмотр таблицы
     • Раздел 0: Название раздела
     • Секция 0 рядов:
       • Контроль ряда 0 (e.г., изображение)
       • Текстовая строка 0
       • Текстовая строка 2

   Вехи

   Как описано выше, сроки завершения и ожидаемые результаты.

   Например, раздел этапов в шаблоне дизайнерского документа может выглядеть так:

   1. Фасадное приложение с изображением экрана и с временными переходами и примерами изображений / текста
   2. Протокол связи: приложение подключается к сети / серверу
   3. Функциональная веха 1:…
   4. Альфа-приложение (с полной функциональностью)
   5. Стабильность
   6. Выпуск

   Убедитесь, что документация по программному обеспечению остается актуальной

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

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

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

   1. Над чем только что работал разработчик?
   2. Над чем сейчас работает разработчик?
   3. Над чем разработчик будет работать дальше?

   Как задокументировать спецификацию в Поваренной книге данных

   Примеры типов объектов данных для документирования со спецификацией:

   • Отчет Cognos или Tableau
   • Канал данных
   • Таблица Excel
   • Процесс ETL
   • Пакет Cognos

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

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

   • Запись цели, описания и структуры объекта данных позволяет другим быстро понять объект
   • Позволяет другим самосовершенствоваться в понимании объекта — сокращение количества писем и обучения
   • Упрощает повторное использование объектов данных. Повторное использование способствует согласованности и ускорению разработки будущих объектов данных.

   Эти уровни доступа потребуются для создания Спецификации:

   • Чтобы просмотреть свои уровни доступа: На вкладке «Организация»> «Пользователи»> ваше имя. Свяжитесь с Синтией Карлтон, чтобы изменить уровни доступа.
   • Отчетная роль = работник. Без статуса рабочей роли вы не увидите «Создать спецификацию» на вкладке «Спецификации».
   • Роль функциональной области = редактор или модератор для каждой функциональной области, содержащей термины для спецификации, которую вы документируете.
   1. Войдите в поваренную книгу данных со своим NetID.
   2. Щелкните «Технические характеристики»> «Создать спецификацию».
   3. Заполните поля, обратите внимание на обязательные. Вы можете отредактировать все это содержимое позже.
      • Имя — идентичное каталогизируемому товару
      • Тип спецификации — выберите один
      Функциональная зона
      • — выберите одну
      • Назначение — почему существует этот предмет? Какие решения принимаются на основе контента? Кто их делает? Как часто
      • Описание — Опишите физические характеристики предмета.На что это похоже? Что в нем содержится?
   4. Назначьте себе или другому сотруднику.

   Запишите метаданные на 8 вкладках в процессе создания спецификации.

   Вкладка обзора

   • Щелкните «Изменить», чтобы изменить содержимое, введенное на этапе «Создание спецификации».
   • Назначение: Почему существует этот предмет? Какие решения принимаются на основе контента? Кто их делает? Как часто?
   • Описание: введите краткое описание физических характеристик предмета.
   • Владелец: используйте названия должностей или отдел вместо личного имени.
   • Data System: выберите один или свяжитесь с Синтией Карлтон, чтобы добавить свой.
   • Тип спецификации: Выберите один или свяжитесь с Синтией Карлтон, чтобы добавить свой.
   • Сведения о доступе: укажите URL-адрес формы заявки или напрямую сообщите, если она общедоступна. Опишите, кто имеет право на доступ.
   • Дополнительные сведения: необязательное поле. Некоторые составители спецификаций используют его как блокнот, чтобы отслеживать вещи, которые они хотят обработать, включая, но еще не решили, как лечить.Примечания могут быть удалены, поскольку они указаны в спецификации.

   ---

   Вкладка «Определения»

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

   ---

   Вкладка «Выборы (или фильтры)»

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

   ---

   Вкладка критериев сортировки

   • Запишите термины, используемые для сортировки данных в отчете.
   • В некоторых спецификациях нет критериев сортировки.

   ---

   Вкладка «Технические»

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

   ---

   Вкладка «Показать подробности»

   • Оценивайте уровень детализации на этой вкладке. Все поля Display Details являются необязательными.
   • Описание выхода. Используйте полные предложения, чтобы описать результат. Например, для каналов данных укажите формат файла.
   • Тип спецификации — выберите один. Свяжитесь с Синтией Карлтон, чтобы добавить новый шрифт.
   • Заголовок — описывает заголовок.
   • Отображение макета — опишите основную часть спецификации или отчета.
   • Нижний колонтитул — опишите нижний колонтитул.

   ---

   Вкладка для насадок

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

   ---

   Вкладка «Совместная работа»

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

   Эти образцы спецификаций написаны особенно хорошо. Обратитесь к ним, если вы новичок в написании спецификаций.

   • Спонсируемые проекты — подробный отчет о награде
   • Любой из отчетов Cumsal
   • Проректор Распределительный список всех факультетов

   Как написать и использовать документ с техническими спецификациями

   Зачем нужна техническая спецификация (TSD)?

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

   Написание и использование TSD

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

   TSD

   TSD — это формальный рабочий документ, который используется обеими сторонами и обычно следует определенной структуре таким образом, чтобы определения сервисного продукта были понятны обеим сторонам.

   Стиль письма

   Поскольку TSD является документом спецификаций, его будут использовать разные пользователи. Нет ничего проще, чем легко читаемый документ. По возможности следует использовать простой язык с короткими и прямыми предложениями.Технический жаргон и сокращения должны быть четко определены без каких-либо предположений. Раздел определений и глоссарий терминов должны быть созданы в начале спецификации для удобства использования.

   Структура / формат

   Это официальный документ с титульным листом, включая дату, участвующие стороны и ссылочный номер.

   Он также должен включать:

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

   Краткое содержание урока

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

   7 убийственных советов по созданию спецификации веб-сайта для поддержки ваших усилий по маркетингу в поисковых системах

   Опытный архитектор скажет вам: только глупый человек может построить дом, не изложив предварительно некоторые спецификации на бумаге. Процесс создания веб-сайта ничем не отличается.Требуется тщательное планирование и точная информационная архитектура, прежде чем вы сможете забить этот первый гвоздь или, в данном случае… набрать первую строку кода. А поскольку успех поискового маркетинга во многом зависит от наличия веб-сайта с прочной основой, дальнейшие усилия по оптимизации зависят от вашей способности с самого начала разработать целостный план. Успешное развертывание веб-сайта зависит от создания подробного документа с техническими характеристиками, так же как дом, в котором вы живете, начинался на бумаге в виде архитектурных чертежей.Эти «спецификации» помогают разработать четкое представление о том, как должен выглядеть готовый продукт, и об отдельных шагах, которые необходимо предпринять для достижения этой цели.

   Неудача по плану, план к провалу

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

   Эффект снежинки

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

   • Назначение документа
   • Описание проекта
   • Внешняя функциональность
     • Общие черты
     • Карта сайта и структура сайта
     • Описание каждой страницы сайта
     • Каркасы (домашняя страница и как минимум 2 другие важные страницы)
     • Разные функции
   • Внутренняя функциональность
   • Сценарии использования
   • Заключение

   7 убийственных советов для успешной спецификации:

   1.Время имеет существенное значение. . Оцените количество времени, которое вкладывается в общий проект, а затем определите, какая часть этого времени должна быть сосредоточена на спецификации. Для краткого документа может быть достаточно от 15 до 30 часов (15 страниц и от 3 до 4 каркасов), но более подробный лист занимает не менее 50 часов. Время, затраченное на документ, должно быть пропорционально бюджету. Необходимо обсудить, сколько времени вы можете реально посвятить спецификациям, чтобы остальная часть проекта могла выполняться гладко и быстро.Если на проект выделено всего 400 часов, нет смысла тратить 100 часов на написание спецификаций.

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

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

   4. Понимание кроется в деталях. Допустим, вы планируете редизайн существующего веб-сайта. Убедитесь, что вы нашли время, чтобы узнать, как работают все разделы старого веб-сайта. В конечном итоге вы будете очень счастливы, что сделали. Если старые разделы вырезаны или опущены, соответствующие или заменяющие разделы на новом сайте должны быть обработаны соответствующим образом. Это также важно при перенаправлении старых URL-адресов, на которые могут быть ссылки из внешних источников.

   5.Не принимать решения — это плохое решение. Зачем составлять план, если план неполный? Не оставляйте пустых разделов, которые вы собираетесь подождать и принять решение позже. Убедитесь, что спецификация охватывает все разделы веб-сайта. Если есть что-то неясное, составьте список вопросов для клиента, в котором есть темы, которые вы хотели бы затронуть. Поставленная вами цель должна быть изложена как можно более четко, потому что это сделает вашу работу и участие клиента более гладким процессом.

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

   7. Будьте проще. Большинство клиентов не будут иметь глубоких знаний в области HTML, JavaScript и т. Д., поэтому вам следует постараться сделать этот документ максимально понятным для них. Клиент может полагать, что он понял то, что вы сказали, но часто то, что он слышал, и вы имели в виду, было двумя совершенно разными вещами. Это может показаться утомительным, но поможет избежать возможных недоразумений в будущем.

   Доставка результатов

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