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

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

Техническое задание содержит следующие разделы:

1. Общие сведения. Данный раздел включает в себя: полное название разработки, полное название и реквизиты заказчика и исполнителя, перечень документов, являющихся основанием для разработки, возможные сроки начала и окончания работ, порядок оформления и предъявления заказчику результатов работ по созданию системы или её частей.

2. Основания и назначения разработки. Под назначением

   разработки понимается вид автоматизируемых процессов деятельности.

3. Требования к системе. Содержит подразделы с требованиями к системе в целом и функциям, выполняемых системой.

4. Состав и содержание работ по созданию системы. Перечень работ и их содержание, которые предполагается выполнить в рамках данного проекта

5. Порядок контроля и приемки системы. Содержит ориентировочные даты промежуточного контроля и ориентировочную дату сдачи заказчику.

6. Требования к составу и содержанию работ по подготовке объекта разработки к вводу системы в действие. Описываются подготовительные работы по вводу системы в действие.

7. Требования к документации. Содержит перечень и состав документации системы.

8. Источники разработки. Содержит список документации, литературы, которая будет использована при разработке системы.

Существуют три стандарта, описывающих техническое задание на проектирование ИС: ГОСТ 34.602-89, ГОСТ 19.201-78, ГОСТ 19.102-77.

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

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

17. Пользовательский интерфейс информационных систем. Общие принципы построения. Стили пользовательского интерфейса. Критерии эффективности пользовательского интерфейса. Руководящие принципы построения пользовательского интерфейса. Правила проектирования.

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

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

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

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

— Модель программиста– рождается в голове программиста, основывается на его профессиональной деятельности.

Стили пользовательского интерфейса. Можно выделить четыре основных стиля пользовательского интерфейса:

— Графический пользовательский интерфейс (Graphical User Interface, GUI)– в основе данного интерфейса лежат четыре фундаментальных элемента: окна, указателя (мыши), меню и пиктограммы. Используются и другие элементы: кнопки, переключатели, поля ввода и др. Особенностью данного интерфейса является развитые возможности оформления экрана и управление с помощью указателя мыши.

— Web-интерфейс (Web User Interface, WUI)– интерфейс напоминаетGUIинтерфейс, но изначально был беднее его. В нём, в частности, использовался режим одного окна и не было возможности «перетаскивания» объектов. С развитиемJavaScriptиAjaxон становится более похожим на интерфейсGUI.

— Интерфейс HUI (Human User Interface)– это пользовательский интерфейс карманных устройств. Обычно подобные устройства обладают очень маленьким экраном. В нём содержатся некоторые элементы графического интерфейса, например элементы меню и пиктограммы.

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

Рассмотрим набор критериев качества пользовательского интерфейса:

— Понимание пользователей – насколько потребности пользователей отражены в интерфейсе программы.

— Эффективность процесса проектирования– определяет является ли продукт тщательно продуман и спроектирован.

— Необходимость проекта– имеет ли продукт экономическую и общественную значимость.

— Пригодность к изучению и использованию– насколько сложен продукт для изучения и использования.

— Соответствие – соответствует ли дизайн продукта решению поставленных проблем.

— Эстетические чувства– насколько использование продукта эстетически приятно.

— Изменяемость– насколько дизайн может изменяться в соответствии с требованиями пользователя.

— Управляемость– в какой мере реализована функция управляемости продуктом: управлением инсталляцией, тренировкой, сопровождением.

Общие принципы построения графического интерфейса:

— использование единой среды пользователя в виде так называемого рабочего стола;

— использование графических окон для отображения данных;

— применение средств неклавиатурного ввода (с помощью мыши).

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

— Контроль пользователя — разработчики должны дать пользователю наиболее полный контроль над ИС (на сколько это позволяет безопасность). Рассмотрим несколько частных реализаций данного принципа:

1) уменьшение нагрузки на память – память пользователя не столь велика и не столь быстра.

2) совместимость интерфейса – возможность пользователей переносить свой опыт и знания на работу с новым программным обеспечением.

17. Моделирования информационных систем. Необходимость в языках моделирования. Язык UML. Принципы объектно-ориентированного проектирования. Обзор диаграмм языка UML. Диаграммы прецедентов и диаграммы классов.

Моделирование– это замещение исследуемого объекта (оригинала) его условным образом или другим объектом (моделью) и изучение свойств оригинала путём исследования свойств модели.

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

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

UML (Unified Modelling Language – унифицированный язык моделирования)– язык графического описания для объектного моделирования в области разработки программного обеспечения.UMLиспользует графические обозначения для представления абстрактной модели системы, называемойUML-моделью. Данный язык был разработан для моделирования ИС.UMLне является язык программирования, но на основеUML-модели производится генерация кода.

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

Диаграмма UML– это графическое представление набора элементов, изображаемое чаще всего в виде графа с вершинами (сущностями) и рёбрами (отношениями).

studfile.net

ТЗ высокой четкости / Habr

Я аналитик, который пишет непонятные ТЗ. Т.е. я пытаюсь писать очень понятные ТЗ. В целом, я слушаю клиентов, потом я слушаю разработчиков, потом голоса в своей голове. Зачем я говорю с ними? В общем, получается то, что получается. Ну вы поняли.

Написать идеальное ТЗ проще простого:

1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.

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

Скан салфетки (Что это мы нарисовали на встречке?)

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

Лайфхак: “Как ты к этому пришел, приятель?”

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

Извращенная логика

Открываем ТЗ и видим, что бы вы думали? Портал с виртуальным кладбищем:

* поднять захоронение в топ 100;
* поделиться захоронением с другом;
* отправить захоронение на главную;
* добавить в некрополь;
* добавить захоронение в черный список;
* активировать карту вип-пользователя;
* установить антивирус;
* кастинг;
* групповые склепы со знаменитостями.

Лайфхак: “Правильно ли я вас понял?”

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

А всего-то, ему нужно услышать свои мысли немного другими словами:

— Правильно ли я понимаю, что вы хотите сделать кастинг захоронений?
— Правильно ли я понимаю, что пользователи будут выводить склепы в ТОП-100?
— Я правильно вас услышал, что пользователи будут приглашать друзей в братские могилы?
— Правильно ли я понимаю, что пользователи будут добавлять могилки в “черный список”?
— Правильно ли я понимаю, что знаменитости мечтают вписать в групповые склепы?
Т.е. вы не критикуете, не сопротивляетесь, не спорите, просто уточняете.

Все и так понятно (прочитайте мои мысли)

— Зарегистрируйся в нашей системе и стань известным и успешным.
— А что нужно делать, дальше?
— Ну вот ты зарегистрировался первый шаг уже сделан!
— ОК, а какой второй шаг?
— Ну активируй карту и подними свою анкету в топ-100.

Иии? Очень хочется услышать рецепт до конца!

Лайфхак: “А что если?”

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

— А что, если пользователь зарегистрировался, активировал карту, поднял анкету, но не стал известным и успешным?

Описание математики рисунком

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

Лайфхак: “А давайте посчитаем это в XLS”

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

При этом просто попросить контрольный пример не получается. Если бы заказчик мог сделать контрольный пример, он бы его сделал и не занимался бы изобразительным искусством. Поэтому контрольный пример придется делать вам как минимум в “Экселе”. Не всегда хватает “Экселя” — возможно, потребуется MathLab или же полноценный исследовательский этап, если у вас внезапно нарисовался DSP, или 3D расчеты, или же распознавание образов с блэк-джеком и нейросетями.
Результатом этой работы должен быть набор тестов, который дает однозначные с точки зрения математики результаты.

Не грузи меня деталями

— Хотим стримить порно через приложение в AppStore.
— Но нас же заблокируют!
— Не грузи меня деталями!

— Хотим стримить по wi-fi аквалангистов с кораллового рифа
— А wi-fi работает под водой?
— Не грузи меня деталями!

— Хотим раздавать 4G wi-fi с автономного роутера, но только тем, кто зарегистрировался в нашей базе.
— То есть придется колхозить прошивку для роутера и ехать в Китай?
— Не грузи меня деталями!

— Хотим подключиться к базе общественного транспорта Москвы
— А вы уже договорились с DIT?
— Не грузи меня деталями!

Лайфхак: “Был тут один случай!”

Перед нами стратег, у которого свой vision, и ничто не способно остановить его движение к успеху! Какие-то мелкие детали (законы физики, современные технологии, политики платформ) их не волнуют — это все только для технических специалистов.

Однако способ достучаться до “негрузидетальных” заказчиков есть — это нарратив. Они вполне смогут услышать историю, про то как:

* На AppStore недавно забанили вашего дружбана за порнушку.
* Мужик на YouTube пытался заняться зимней рыбалкой с wi-fi экшн камерой, чтобы посмотреть как рыба реагирует на наживку (черт, я ведь не шучу сейчас!).
* Как другой ваш дружбан колхозил прошивку для роутера, а в Гуанчжоу его киданул гид.
* Как вы уже полтора года ждете ответа от DIT Москвы.

Казалось бы, что это же частные случаи, и “у нас-то все будет по-другому!” Но, как не удивительно, заказчик-стратег верит байкам, особенно тем, которые травят их друзья. Отсюда вытекает другая проблема.

Д — Дичь! (так никто не делает)

— Давайте спарсим выдачу “Яндекса”!
— ЧТОА? Эээ… Мммм… Как? Заачееем?
— Чтобы сэкономить на поисковом движке!

— Давайте для iPhone напишем три приложения которые будут внутри iPhone друг с другом взаимодействовать!
— Заааааачеееееем???
— Для повышенной безопасности: одно будет шифровать трафик, другое будет следить за обновлениями, а третье будет чатом.

Лайфхак: “Без нас”

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

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

В целом, метод такой:

* Задать вопросы.
* Определить ценности и потребности.
* Предложить несколько альтернативных вариантов заказчику, о которых он не знал или не думал.

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

С — Схема! (как хотелось бы, но не работает)

Сэйлз выцепил клиенток из Tinder’а.

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

Лайфхак: “А все остальное идеально?”

Обычно, когда разработчики видят такое, то они цепляются за это мозгом и спорят с заказчиком. А нужно задать себе вопрос: “ОК, тут затык, а все остальное в этом проекте — идеально?”
Конечно же нет! Ведь причуды не ходят поодиночке. Выясняется, например, что: между соучередительницами не улажены юридические вопросы, они находятся в разных странах и ненавидят друг друга, какая-то несчастная команда уже начинала это пилить, теперь проект покоится на компакт-диске, который не читается, и нужно заняться полировкой царапин…
И тут вы сразу расслабляетесь, перестанете спорить и предлагаете заказчику вернуться к обсуждению после улаживания всех остальных вопросов.

Коллективное творчество (правка в правке в режиме правки, “Ворд” — в лоскуты)

Представьте себе миленькую международную компанию-гигантика. В ней ТЗ нужно согласовать со всеми департаментами. Нами предложены три варианта реализации. Ну, знаете, как в крупных компаниях говорят с подрядчиками? А вот так: “Предложите нам вариааанты!” (обязательно с оттяжечкой и “н” так в носик). Так вот, одним отделам понравился один вариант, вторым — второй, третьим — третий. И все так чатятся в режиме правки. Смогу ли я узнать ТЗ, которое получу на выходе после правок?

Лайфхак: “Жрем слона по частям”

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

У меня в почте есть 18-ая, а есть даже и 23-я версия ТЗ из 6-ти страничек. Все уже настолько задолбались, что никто уже не хочет сводить это все вместе… Нестерпимо хочется в производство!

Заключение

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

habr.com

Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Работаем над ошибками

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

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

Уточнения:

1. Технические задания не пишут (составляют, подготавливают, оформляют и пр.), а разрабатывают, см. хотя бы п. 1.2 ГОСТ 34.602-89;
2. Если заказчик и исполнитель руководствуются требованиями ГОСТов, то совершенно противоположных мнений у них в принципе быть не может и не должно. Если же взаимодействие осуществляется «по понятиям» — как сейчас принято — то без «плюрализЬма мнений» тут, конечно, никак не обойтись.

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

Палка о трех концах:

1. Чрезмерно детализированное техзадание становится техническим проектом, что, в общем-то, и неплохо, но кто даст исполнителю столько времени и денег на разработку излишне подробного ТЗ?
2. Вменяемый исполнитель всегда стремится сократить объем технического задания, поскольку «меньше слов — меньше вопросов». И меньше работы. Более того, на стадии технического задания очень трудно предугадать технический облик изделия, программы или автоматизированной системы в целом, поэтому существует типовая отмазка «то-то и то-то должно уточняться на стадии технического проекта»;
3. Исполнитель не должен забывать, что он несет обязательства не только в части реализации функциональных требований, но и общих требований — требований к надежности, безопасности и т.д. Нет смысла перечислять, поскольку их довольно много и все они подробно изложены в том же ГОСТ 34.602-89.

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

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

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

По сути правильно, только это будет не ТЗ, а нечто вроде оперативно-технической записки, ТТЗ, заявки, письма с хотелками — общими функциональными требованиями. Теперь о неточностях: нельзя смешивать понятия модулей и подсистем, поскольку подсистема — это та же система, только маленькая. Подсистема, как и система, включает в себя все виды обеспечения, все те же общие требования, а модуль есть всего лишь «Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память [из п. 15 Таблицы 1 ГОСТ 19781-90]»

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

Что касается «основных понятий», то существует громадное количество ГОСТов, содержащих в своих названиях строчку «… Термины и определения». Их и следует применять в работе, чтобы быстрее освоить новую предметную область, но ни в коем случае не ссылаться на всяческие «… педии», поскольку это не только несолидно, но еще и «чревато боком» в части последствий. По четвертому абзацу:

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

За долгосрочное сотрудничество исполнитель будет цепляться всеми конечностями, если, конечно, заказчик вменяем… Спиральную модель заменим п. 1.7 ГОСТ 34.602-89 и уточним п. 11 Приложения 1 того же стандарта. По седьмому абзацу:

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

Смешаны понятия этапов и очередей. Применительно к автоматизированным системам: Этап — Часть стадии создания АС, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей [из п. 4.4 ГОСТ 34.003-90] Очередь — Часть АС, для которой в техническом задании на создание АС в целом установлены отдельные сроки ввода и набор реализуемых функций [из п. 4.5 ГОСТ 34.003-90] По девятому абзацу:

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

Зачем вся эта самодеятельность с составлением страниц с содержанием ТЗ? Есть ГОСТ 19.201, есть ГОСТ 34.602 и другие стандарты, в которых структура и содержание технических заданий расписана четко и строго, узаконена государством, не содержит практически ничего лишнего, при этом допускается вводить дополнительные разделы, подразделы, пункты и подпункты на усмотрение заказчика и исполнителя? По десятому абзацу:

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

Вот тут совсем непонятно: ведь заказывает музыку тот, кто платит, а платит заказчик. Как исполнитель может хоть что-то ему навязывать? Тут возможно лишь взаимное «согласие как продукт при полном непротивлении сторон»… По одиннадцатому абзацу:

В настоящее время в РФ действует ГОСТ 34.602-89 «Техническое задание на создание автоматизируемой системы», который, не смотря на 89-й год своего создания, неплохо отражает общую структуру ТЗ. Тем не менее, для многих случаев, он является недостаточно детальным и хорошо описывающим специфику разработки современных программных продуктов.

Слезы потекли ручьем:

1. Плохо или неплохо — судить не нам, поскольку все существующие зарубежные стандарты, включая MIL, даже близко к ГОСТ 34-й системы не стояли в части детализации и полноты охвата;
2. ГОСТ 34.602 к программным продуктам вообще никакого отношения не имеет, ибо «Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее — ТЗ на АС)».

Правда, отдельные требования ГОСТ 34.602 целесообразно присовокуплять к ТЗ, разработанным по ГОСТ 19.201, чтобы компенсировать некоторые его огрехи, что не возбраняется самим ГОСТ 19.201 — «В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]». По четырнадцатому большому абзацу:

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

Все это не предусмотрено как ГОСТ 19.201, так и ГОСТ 34.602, но имеется подраздел «Требования к численности и квалификации персонала системы и режиму его работы», который разумно добавить в ТЗ на ПО и детально расписать в нем категории персонала. И даже роли… А еще в ГОСТ 34.602 предусмотрены требования к организационному обеспечению — в них можно отлично развернуться и дать волю фантазии.Все, что перечислено ниже, детально расписано в РД 50-34.698-90. Если интересны подробности — задавайте вопросы в комментариях. По заключению:

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

И, наконец:

1. «Законодательно» ТЗ разрабатывается самим заказчиком только в том случае, если он представляет Министерство обороны или иное силовое ведомство;
2. Тендерную документацию разрабатывает именно тот подрядчик, который заведомо должен выиграть конкурс. Простите, но это жизненные реалии…

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

habr.com

Структура технического задания / Habr

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

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

1. Разделы сайта. Здесь необходимо перечислить все разделы и подразделы сайта, которые будут доступны на сайте. не обязательно подробно расписывать, что в каждом разделе (подразделе), этим мы займемся позже, сейчас нам надо просто их перечислить.
2. Типовые страницы. Здесь необходимо перечислить все типы страниц, которые у вас будут доступны на сайте. Например: титульная страница, вывод результатов поиска, вид дял печати и т.д.
3. Дизайн-макеты типовых страниц. Не стоит лениться и упускать данный пункт. Здесь просто необходимо визуально (или в тектовом виде) обозначить где и какие элементы сайта будут отображаться на странице. Данный пункт можно готовить вместе с дизайнером, решить все концептуальные вопросы. Не надо прикладывать уже готовые макеты достаточно схематично все разметить. Это необходимо для того, чтобы в последствии у заказчика не возникло желания переместить или подвинуть тот или иной элемент.
4. Программная часть проекта. Не полениться и расписать все технологии что будут использоваться на данном сайте, например, серверная технология — PHP или перечислить все клиентские технологии. Этот пункт нужен для того, чтобы обезапасить себя от выбора заказчикам хостинга, который не поддерживает, например, PHP, ну и так, на всякий случай. Думаю не лишнее…
5. Содержание и функционал сайта. Здесь можно вставить табличку с названием раздела (подраздела), его описанием и его свойствами (закрытй раздел, динамический, отображается в дополнительном окне, пункт в главном меню…).
6. Дополнительная информация. Здесь необходимо указать, те вещи которые по той или иной причине не улажились в предыдущие пункты. Их должно быть не много. Например: нарисовать тизеры для следующих разделов и перечисление этих разделов, разработать кредитный калькулятор (тут же его описание). Некоторые моменты этого раздела можно разбить на под разделы, например, кредитный калькулятор: функционал, внешний вид, техническую составляющую и т.д.

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

P.S. В будущем планирую написать еще материалы по разработке ТЗ: способу представления, формированию и проведению брифа с заказчиком.

habr.com

Из чего состоит ТЗ? Структура технического задания

21.11.2013

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

Сначала немного о требованиях

Наш опыт сотрудничества с разными заказчиками дал возможность понять, что хорошее ТЗ отвечает таким критериям:

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

А теперь о структуре ТЗ

Структуру технического задания можно представить в таком виде:

1.  Общие сведения
2.  Эксплуатационные характеристики
3.  Функциональные характеристики
4.  Термины и определения
5.  Структура сайта, описание его страниц
6.  Требования безопасности
7.  Требования к хостингу
8.  Контент
9.  Передача сайта заказчику

1. Общие сведения. Здесь заказчик и исполнитель «представляются» друг другу. Также приводится перечень документов (если они есть), на основании которых создается сайт, описывается общее назначение будущего сайта.

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

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

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

5. Структура сайта и описание его страниц. Один из наиболее важных разделов ТЗ. Здесь подробно, насколько это возможно, описываются структура, навигация, страницы ресурса (что и как будет на них расположено).

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

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

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

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

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

---

---

astratest.ru

Документирование в разработке ПО / Habr

INTRO

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

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

1. Документация обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о стрёмном баге в той фигне, которую Вася месяц назад делал».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость. «Наколенные записки» — прямой и очень быстрый путь к тому, что границы проекта расползутся резвыми тараканами, а функционал, задуманный вначале, не будет монтироваться с возникающими в процессе «хотелками» заказчика.

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

1. Документация не должна быть избыточной и объемной. Мы пишем документы не за-ради приятного процесса постукивания по клавишам, а для того, чтобы их использовать в работе. Избыточное количество текста – раздражает и затрудняет восприятие.
2. Вся схема документирования проекта должна быть взаимоувязанной и логичной. Если в схеме существует документ, который не связан ссылкой с каким бы то ни было другим документом, то его можно безболезненно из схемы исключить.
3. Вся оценка трудозатрат должна производиться только на основании описанных атомарных задач. Сложно оценить разработку «функционала подсистемы ввода данных», гораздо проще оценить задачи «разработка формы ввода данных марсиан» и «разработка фильтра списка марсиан». Чем мельче оцениваемый элемент – тем точнее будет агрегированная оценка.
4. Всегда необходимо формировать списки оповещения заинтересованных участников. Разработчик, узнающий о необходимости доработки за три дня до релиза – это зло и подлейшая подлость, аналитик, втихаря поменявший требования и не уведомивший всех заинтересованных участников о необходимости доработки – последняя свинья, а РП, допустивший такую ситуацию – чума, холера и неприятный человек, который не справляется со своими обязанностями.

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

Итак, какие типы документов используются в схеме.

1. Техническое задание.
2. Частное техническое задание (опционально).
3. Сценарий использования (Use Case).
4. Сценарий тестирования (Test Case).
5. Отчет об ошибке (Bug Report).
6. Руководство пользователя.
7. Руководство администратора (опционально).

На рисунке ниже — схема связи между этими документами.

Как это работает?

ТЗ

Изначально, при обследовании, формируется Большое Техническое задание.
Оно включает в себя:
• словарь терминов предметной области;
• описание предметной области;
• описание ролевой системы;
• описание функциональных требований;
• описание нефункциональных требований.
Описание требований в этом документе фиксируется на «верхнем уровне», то есть мы описываем не конкретные действия, а только необходимые функции. Требования оптимально разбивать на смысловые группы по подсистемам.
Например, мы описываем подсистему «Администрирование» с функциями «Создание карточки пользователя», «Удаление карточки пользователя», «Редактирование карточки пользователя». Это требования верхнего уровня, ниже в ТЗ опускаться смысла нет.

ЧТЗ

В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.
ЧТЗ должны содержать:
• ссылку на пункт ТЗ;
• максимально подробную информацию по каждой функции;
• список UseCases для функции.
Таким образом реализуется преемственность документов, что позволяет, во-первых, унифицировать их форму, во-вторых – частично реализовать повторное использование, то есть снизить затраты времени на «писанину».
Например, мы формируем ЧТЗ на всё ту же подсистему «Администрирование». Оно будет содержать описание функции: «Создание карточки. Необходимо реализовать следующий функционал: вызов карточки посредством кнопки «Создать», интерфейс карточки, содержащий следующий набор полей, сохранение карточки посредством кнопки «Сохранить», отмену сохранения посредством кнопки «Отмена»».

Use Case

Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.
Каждый Use Case должен быть привязан к пункту ЧТЗ.
Наиболее оптимальным, на мой взгляд, является формат описания, включающий в себя:
• Макет экрана. Макеты можно делать и сложные, «кликабельные», но, по опыту, хватает «проволочной диаграммы», сделанной с помощью Visio или аналогичного инструмента. Если на форме предполагается использование модальных окон, то они тоже должны быть прорисованы, нижеописанные таблицы для них должны дублироваться.
• Диаграмму действий экрана, в графическом виде описывающую алгоритм работы функции.
• Таблицу с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
• Таблицу с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
Также возможно небольшое общее описание функционала но, как правило, оно просто не нужно.

Test Case

Test Case, что вполне самоочевидно, должен содержать описание тестовых сценариев.
В идеале, каждый такой документ привязывается к соответствующему Use Case, но бывает так, что логично объединить несколько Use Cases в один Test Case.
Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей ответное действие системы, во втором – описание правильной реакции системы. Описывать, к примеру, процесс ввода текста в текстовое поле не нужно, а вот проверку валидности данных при сохранении (щелчке по кнопке «Сохранить») – обязательно.

Bug Report

Ещё немного побуду кэпом: Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.
Содержать документ должен:
• скриншот возникшей ошибки;
• описание предшествующих действий. Лучше всего разработать удобный для всех шаблон такого описания – это сильно экономит время разработчикам при воспроизведении бага;
• текстовое описание самой ошибки.

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

Самые занудные в написании, но, тем не менее, жизненно необходимые документы.
По сути, их формирование можно даже автоматизировать, если все Test Cases и Use Cases были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.

Заключение

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

habr.com