Техническое задание на разработку интерфейса программы

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Спойлер
Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.

3.2 Как составить техническое задание (тз) (бриф) на проектирование (дизайн) сайта приложения

Жутко правда? Бюджет уже потрачен и срок истек.

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

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве

Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.

Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ

Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:

• Концептуальная модель
• Функциональная карта
• Путь пользователя
• Пользовательский интерфейс
• Программные интерфейсы
• Нефункциональные требования

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

Как составить техническое задание для разработки мобильного приложения?

Концептуальная модель

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

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

Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.

Стоит рассказать о типах пользователей и их ключевых отличиях.

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

И в завершении расскажите о компонентах вашего продукта.

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

Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.

Функциональная карта

Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.

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

Путь пользователя

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

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

Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.

Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.

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

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

• ukraine.craigslist.org
• www.theworldsworstwebsiteever.com (предупреждение, если вы страдаете приступами эпилепсии то не переходите по ссылке
• www.art.yale.edu

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например 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 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

• техническое задание
• тз
• srs
• prd
• техническое задание для разработки
• проектный менеджемент
• аналитика требований
• требования к разработке
• ТЗ для приложения

Источник: habr.com

Принципы создания графического пользовательского интерфейса.. техническое задание Зеушев Адам. Техническое задание На разработку модуля Принципы создания графического пользовательского интерфейса. проектирование ис

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма

Скачать 130.5 Kb.

Частное учреждение

«СТОЛИЧНЫЙ БИЗНЕС КОЛЛЕДЖ»

Техническое задание

На разработку модуля « Принципы создания графического пользовательского интерфейса.»

«проектирование ИС»

Выполнил: студент 2-го курса группы ПК-23

Зеушев Адам Рустамович

Оглавление

1. Разработка UI-интерфейсов 3

3. Создание мокапа 4

4.Утверждение структуры 5

5.Выбор стиля UI 5

6.Согласование стиля 5

1. Разработка UI-интерфейсов

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

Грань между UX (User Experience) и UI (User Interface) очень тонка, но если разобраться, то становится ясно, что UX помогает понять пользователя. В UX-дизайне больше психологического аспекта, нежели технологического. UX изучает пользователя: как пользователь живёт, что он думает, как и что делает и что его окружает. Перед дизайнером ставится задача — помочь обычному человеку легко разобраться с вашим программным продуктом и получить при этом удовлетворение от работы с ним.

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

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

2. Концепция

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

3. Создание мокапа

Этот этап позволяет быстро понять видение клиента и внести уйму изменений до начала разработки интерфейса пользователя. Мы намечаем расположение кнопок, форм и других нужных элементов, а уже потом подбираем цветовую палитру, шрифты, изображения, преобразуя всё это в удобный и красивый макет. То есть начинаем с варфрейма (план расположения элементов на странице), а заканчиваем созданием из этого плана красивой картинки. В случае разработки приложений под Android и iOS труд дизайнера облегчается гайдлайнами — правилами оформления и расположения элементов интерфейса, регламентом UX/UI, который был создан непосредственно экспертами по дизайну из Google и Apple.

User Flow Diagram (карта экранов)

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

4.Утверждение структуры

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

5.Выбор стиля UI

Skeuomorphic design и flat design. Источник: obsid.se
Существует множество различных концепций, например: material design, metro, skeuomorphism и т. д. При выборе стиля интерфейса следует учесть текущие тенденции в дизайне, адаптивность, время на разработку и внедрение дизайна, и много других не менее важных моментов.

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

6.Согласование стиля

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

Источник: topuch.com

Проектирование интерфейса как часть разработки ТЗ

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

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

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

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

Предлагаемый подход позволяет решить следующие проблемы:

• Устранить различия во взглядах на постановку задачи заказчика и исполнителя. Спецификации на сколько-нибудь сложные системы слишком абстрактны. Их с трудом удерживают в голове даже авторы, а до конца не понимает никто, в особенности ключевое лицо — заказчик. Для него эта спецификация ничем не отличается от сакральных письмен (многие даже предполагают, что непонятные ТЗ предназначены для того, чтобы произвести на них впечатление и содрать побольше денег). Нет разницы, что подсунут ему разработчики, реальное ТЗ или инструкцию к газонокосилке на фарси — все одинаково непонятно. Наивно предполагать, что заказчик, легко подписавший такое ТЗ, также легко примет разработанную систему. Прототипы интерфейса являются тем единственным документом, который заказчик может понять и оценить. А поняв и оценив — сознательно подписать.
• Облегчить процесс внедрения системы. Весомая часть проблем внедрения в качественно выполненном проекте приходится на интерфейс, созданный формально правильно, но неадекватно представлениям заказчика. Не существует вида ТЗ, кроме собственно прототипа интерфейса, который бы мог интегрировать такого рода требования. Наглядный пример: в любом ТЗ можно прописать, что «в системе есть адресная книга, которая состоит из таких-то данных и таких-то функций». Но невозможно формализовать уже в ТЗ, как эта адресная книга должна реально работать (какие-то функции нужно «вытащить» наверх, какие-то можно «задвинуть»), как, в конце концов, эта адресная книга должна выглядеть. При этом апелляции исполнителя к подписанному техническому заданию – дескать, вот же перечисленные функции. вот они все налицо — как правило, не срабатывают, поскольку при известной изворотливости в контексте пользовательского интерфейса проинтерпретировать ТЗ всегда можно очень по-разному. Только заранее спроектированный интерфейс позволяет застраховаться от такого рода претензий.
• Сократить число доработок системы, вызванных несоответствием ее функциональности ожиданиям клиента. Только увидев саму систему, заказчик может реально понять ее возможности, равно как и оценить собственные потребности. Для заказчика программный продукт и его интерфейс совершенно тождественны. Следовательно, показав заказчику интерфейс на стадии подготовки ТЗ, можно снизить количество и объем переделок, потребность в которых возникает из-за расхождений ожиданий заказчика с запланированной в ТЗ функциональностью системы. (Нужно, впрочем, отметить, что такие переделки чаще всего не проблематичны для разработчиков, которые обычно настаивают на дополнительной оплате этих услуг.)
• Снять риск необходимости доработки функциональности системы, из-за неудовлетворенности заказчика предложенным интерфейсом. При разработке интерфейса нет решительно никакой гарантии того, что он будет принят заказчиком. Описание функций системы бинарно, функция может быть, может не быть. Доказательство её наличия редко требует аргументации. Интерфейс же может быть либо достаточно хорошим, либо недостаточно хорошим. Когда в дело вступают относительные термины, все усложняется, что может приводить в возникновению конфликтных ситуаций. Нечего и говорить, что при переделке недостаточно хорошего интерфейса функциональность системы, которая уже есть, меняется тоже, причем без оплаты труда разработчика.

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

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

Однако практика показывает, что промежуточные наглядные результаты работы над системой, а именно прототипы интерфейса, продемонстрированные уже на второй день работы, а не через несколько недель, приводят клиента в благодушество. В отличие от обычного ТЗ, работа над которым заказчику реально не видна («ну что там, пара пунктов добавилась») прототипы интерфейса легко понятны и прогресс в работе явно заметен. Вторая организационная проблема связана с необходимостью подписывать два договора: на создание ТЗ (читай — интерфейса) и на разработку функциональности системы. Причем подписание второго договора откладывается на определенный срок, необходимый для разработки интерфейса, что растягивает проект во времени. В принципе, эта проблема неразрешима, но, с другой стороны, здесь многое зависит от её восприятия: да, договора два, но зато второй договор получается значительно более точным (уже имея интерфейс, легче оценить трудозатраты).

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

Сравнительно недавно появились специальные средства для прототипирования интерфейса (например, Norpath Studio), но пока они довольно сырые. Выход — использование неспециализированных графических редакторов. Ещё несколько лет назад основным таким редактором являлся MS PowerPoint, сейчас же наиболее удобным следует признать MS Visio. Сложные экранные формы, впрочем, до сих пор удобнее просто рисовать на бумаге.

И, наконец, главная проблема. Удлинение процесса разработки ТЗ часто воспринимается самими разработчиками как безусловное зло — привычка сначала делать, а уж потом думать, традиционно сильна в российском IT-бизнесе. Увы, изменить этот обычай может только «опыт, сын ошибок трудных». Пока, во всяком случае…

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

Интерфейс сложной системы невозможно с самого начала спроектировать полностью: придется сначала делать работающую бета-версию и окончательно править интерфейс уже на её основе. Кроме того, во многих проектах из-за не зависящих ни от кого причин не получается растягивать процесс создания ТЗ (заказчик хочет увидеть какие-нибудь результаты уже завтра). Однако, учитывая низкие «входные» требования к применению предложенного метода (несравнимые, например, с волокитой и бюрократией, обусловленной использованием UML), проектирование интерфейсов на стадии подготовки спецификаций почти всегда является крайне успешным методом решения проблем внедрения.

Изначально опубликовано в журнале Intelligent Enterprise/Корпоративные системы (12/77, 2003).

Источник: studfile.net