Описывает то что должна сделать программа

Чтобы команда разработки оценила срок и стоимость проекта, ей нужно ТЗ — техническое задание. Его сложно написать так, чтобы разработчики сразу поняли суть и могли безошибочно оценить работу.

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

Когда клиент без ТЗ обращается в Skipp, мы изучаем его материалы, собираем команду по проектированию и помогаем провести предпроектную подготовку. Итог этой работы — описание задачи, которое потом отправится на оценку разработчикам.

Что такое требования и зачем они нужны

Требования – это точно сформулированное описание совокупности полезных для пользователя характеристик, ожидаемых им от продукта. Продуктом в данном случае может являться предмет, используемый человеком в быту и на производстве (например: автомобиль, компьютер, дом), услуга (стрижка, перевозка груза), работа или результат работ (строительство или ремонт объекта).

Станислав Капулкин, Владислав Цендровский «Теория категорий для описания архитектуры программ»

Примером требования, предъявляемого к автомобилю, может являться максимальный расход топлива – не более 11 литров на 100 км пробега по городу.

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

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

Зачем нужно записывать требования

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

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

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

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

02 Описание работы программы в одном видео.

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

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

Чуть подробнее о том, какие бывают требования

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

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

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

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

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

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

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

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

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

Различные модели поведения, или сценарии, развертываются в зависимости от определенных запросов и условий, при которых делались эти запросы. Вариант использования собирает вместе эти сценарии.[1].

В качестве примера приведу вариант использования «Сохранение проекта» для системы управления требованиями:

Предусловия

Проект открыт в программе управления требованиями

Результат

Создан файл XML с описанием проекта

Основной поток

1. Пользователь запускает сохранение файла с новым имененм
2. Система запрашивает путь и имя файла, в который необходимо сохранить проект
3. Пользователь задает путь и имя файла
4. Система выдает сообщение «Проект сохранен»

Альтернативный поток

3.1. Если файл с заданным именем уже существует
3.2. Система выдает сообщение «Файл [путь и имя файла] уже существует. Заменить его?»
3.3. Пользователь подтверждает сохранение проекта
3.4. Выполнение варианта использования продолжается с шага 4
3.3.а. Если пользователь отказывается от сохранения файла, то система выдает сообщение «Проект не сохранен» и выполнение варианта использования прекращается
3.3.б. Если пользователь задает другие путь и имя файла, то выполнение варианта использования продолжается с шага 3.

Исключения

Возможна ошибка операционной системы при сохранении файла. В этом случа система выдает сообщение «Ошибка при сохранении проекта в файл [путь и имя файла]» и выдает сообщение о причинах ошибки.

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

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

Примечание
Разные разработчики могут использовать разные шаблоны вариантов использования. Также разные шаблоны вариантов использования могут применяться в разных проектах одного и того же разработчика. Более подробно о вариантах использования читайте в книге Алистера Коберна «Современные методы описания функциональных требований к системам».

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

Помимо описания функционирования системы, требования могут включать такие ожидания пользователей, как удобство интерфейса, надежность, быстродействие. Такие требования называют атрибутами качества [2]. Атрибуты качества должны учитываться при выборе архитектуры и средств реализации проекта.

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

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

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

• Вигерс К. Разработка требований к программному обеспечению.
• Коберн А. Современные методы описания функциональных требований к системам.

Зачем нужны системы управления требованиями

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

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

Литература

1. Коберн А. «Современные методы описания функциональных требований к системам» — М.: Издательство «Лори», 2002.
2. Вигерс К. «Разработка требований к программному обеспечению» — М.: Издательско-торговый дом «Русская Редакция», 2004.

Источник: www.am-programs.ru

Как сделать описание проекта: пошаговая инструкция

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

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

Как разрабатывается проект?

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

1. Первый шаг. Подрядчик принимает от корреспондента техническое задание. Они согласовывают условия – сроки, бюджет, величину и схематику исполнения (текстовая, графическая, презентационная). Для этого нужно чёткое описание проекта и его понимание в целом. И далее наступает черёд умелого внедрения и начертания всех аспектов до самых мелких деталей.
2. Второй шаг. Утвердив бриф, приёмщик передаёт задание менеджерам-цеховикам или офисным работникам на проработку проекта.
3. Третий шаг. Составляется полная технологическая схема с указанием периодов, в каждом из которых выполняются последовательно определенные мероприятия.
4. Четвёртый шаг. Проработав основную часть плана для выверки схемы, все дальнейшие действия согласуют с заказчиком. Более подробно и наглядно обговариваются дополнения, добавляются задачи, прогнозируются реальные цели и подытоживается окончательная оплата.
5. Пятый шаг. Укомплектовав весь проект и завершив работу над ним, подрядчик передаёт клиенту готовое решение. Тот, в свою очередь, проводит заключительный расчёт.

Первоначальный план описания проекта

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

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

Поэтапное формирование проекта

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

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

Цель – то, без чего не бывает проекта

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

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

Составление брифа по созданию сайтов и лендингов

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

1. Фамилия, имя, отчество управляющего порталом, лендингом, ресурсом.
2. Название компании, сообщества или фирмы.
3. Контактные данные заказчика.
4. Область работы – вид деятельности.
5. Название запланированного проекта.
6. Бренд и фирменный стиль проекта.
7. Логотип (если имеется).
8. Предпочтительные цветовые тона.
9. Дизайн для отдельных частей и страниц.
10. Количество страниц внешних и внутренних у сайта.
11. Услуги размещения проекта у хостинг-провайдера.
12. Составление и приобретение доменного имени.
13. Наполнение статьями – копирайтинг.
14. Продвижение, раскрутка и реклама.
15. Сопровождение и забота о ресурсе в дальнейшем.
16. Функциональная составляющая проекта:

• административная панель портала;
• внедрение кодов php, css, javascript;
• базы данных Mysql;
• раздел новостей;
• раздел статей и блогов;
• раздел «фотогалерея»;
• встроенные рассылки;
• формы контактов и связи;
• регистрация и скрытие отдельного контента;
• поиск и карта сайта;
• seo-оптимизация страниц и проекта в целом;
• мобильная версия сайта;
• добавочные блоки рекламы и преимуществ;
• модули для видео, аудио и других фишек;
• изготовление баннеров, флеш, анимации;
• переключение многоязыковых версий сайта;
• магазин и корзина покупателя;
• каталоги товаров и ресурсов;
• подключение платёжных процессингов;
• раздел помощи и базы знаний.

Разработка проекта по созданию сайтов и лендингов

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

Как описать проект в разработке

Взяв в работу тему о создании сайтов и лендингов, необходимо сделать записи всех мероприятий. Приведём пример описания проекта:

Этап № 1 – изготовление макета, программирование платформы CMS системы с разбиением сайта на отделы: админку и публичную часть, подключение модулей. Закреплено за менеджером (Ф. И. О.).

• соорудить макет – дата/время;
• подготовить cms-платформу – дата/время;
• привязать модули и блоки – дата/время;
• протестировать работоспособность и функциональность – дата/время;
• отчёт о проделанной работе – дата/время;
• всё время, затраченное на осуществление этапа;
• бюджет, выделенный на проработку действий.

• что сделано, какие недоработки, ошибки;
• что сделать, когда, срочно или нет;
• интересная идея – предложить;
• ещё что-то инновационное.

Для выполнения такой сложной работы нужно выделить из бюджета ещё 100000 рублей для приобретения и привязки дополнительных компонентов.

Цель: Изготовить и сдать к определённому сроку готовый рабочий каркас проекта.

Этап № 2 – изготовление дизайна, логотипа, баннеров. Закреплено за менеджером (Ф. И. О.).

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

• что не сделано, какие недоработки, ошибки;
• что надо делать, когда, срочно или нет;
• интересная идея – предложить;
• ещё что-то инновационное.

Предложить в правой колонке сделать ещё 2 статических баннера.

Цель: Изготовить и сдать к определённому сроку готовый дизайн и элементы графики.

Этап № 3 – наполнение лендинга текстовым контентом, вставка видео и аудио. Закреплено за менеджером (Ф. И. О.).

• написать 5 страниц текста – дата/время;
• подготовить и разместить 5 видео и 10 аудиозаписей – дата/время;
• отчёт о проделанной работе – дата/время;
• всё время, затраченное на осуществление этапа;
• бюджет, выделенный на проработку действий.

• что сделано, какие недоделки, ошибки;
• что сделать, срочно или нет, когда-нибудь потом;
• супермысль – предложить;
• ещё что-то новенькое.

Обновить программу для записи видео.

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

Этап № 4 – сдача проекта заказчику. Ответственный Строгов П.Г.

• согласовать проделанные этапы – дата/время;
• выделить ресурсы на доработку – дата/время;
• отчёт о проделанной работе – дата/время;
• всё время, затраченное на осуществление этапа;
• бюджет, выделенный на проработку действий.

• что сделано, какие недоделки, ошибки;
• что сделать, срочно или нет, записать доработки;
• идея Х – предложить;
• ещё что-то новенькое.

Добавить в базу клиента и сдать в архив мероприятие. Подумать, что ещё сделать.

Цель: Сдать готовый проект.

Ведём проекты и задачи в профессиональных системах

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

Проект закончен: что дальше?

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

Источник: fb.ru