Вот тут улыбнулся.

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

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

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

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

Но это пишется без сроков выполнения, без делайнов или "поддедлайной".

На подготовку и написание документов тоже есть сроки.

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

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

Перейдем к требованиям. Можно разделять два процесса: процесс сбора/создания решения и процесс описания/документирования решения. Вы частенько упоминали про UML и тд, но это всего-лишь нотация оформления (для кого-то и мышления. но не суть). Т.е. для начала Вы должны представлять себе решение, а уже потом оформлять его. У меня бывало, что на поиск решения могли уходить недели (грязного времени), а на документирование 10 минут. За 5 лет работы мне так и не пришлось оформлять требования в UML-нотациях. Это я к тому, что совсем не в обязательном порядке чему-либо следовать (хотя UML/IDEFx/BPMN наверное ближе всех к стандартам отрасли).

Мы работаем с коробочным продуктом, где мои ТЗ это добавление/изменение/удаление некой части возможностей продукта.
Я передаю команде разработчиков документ (MS Word), внутри которого:
1. Тема и идентификатор задачи.
2. Исходная ситуация. Описание как мы докатились до того, что требуется что то программировать.
3. Цель. Описание цели, к чему стремимся на высоком уровне (ответ на вопросы "почему/зачем", а не "что/как"). Желательно, что бы цель не ограничивала решение.  Решение - это лишь конкретный вариант достижения цели.
4. Требования. Тут у меня нумерованный список, где чем выше уровень тем в более общем смысле описана задача. Ну, например, "1. Добавить отчет "Показатель АБВ". 1.1 Параметры/настройки построения. 1.2 Выборка данных. 1.3 Макеты представления" и тд. Чем глубже - тем больше деталей. Там могут встречаться таблицы, схемы, макеты (рисую в пейнте ^^, моделирую в Visio, Excel-е и тд). Т.е. нумерованный иерархический список + материалы. Было время, начальник не принимал ТЗ "без картинок" =)
5. Миграция БД. Как обновлять БД имеющихся клиентов после обновления программы.
6. Сценарии использования/Приемочные критерии. В помощь QA-инженерам.
7. История изменений. Табличка, где вписаны жизненные вехи документа (создание, правки и т.д.).

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

Предварительно необходимо составить vision (главный концепт) вашей игры. Не забывайте ключевые принципы, типа "Разделяй и властвуй". Не можете оценить задачу - дробите на составляющие. Ну и в этом духе, от общего к частному и наоборот. А так же ознакомиться с азами системного подхода. Удачи!

По поводу

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

- я бы порекомендовал автору ознакомиться с ГОСТ34.602.89, не использовать целиком, а именно ознакомиться. Очень хорошо прочищает, позволяет понять сколько может быть неучтенного если подходить к этому вопросу "нахрапом".

Опять же, творчески переработав перечень требований  ГОСТ (что самим ГОСТ не возбраняется) - можно получить неплохой базовый шаблон для основного документа. Выделяйте только те Требования, которые нужны конкретно для Вашего проекта, добавляйте собственные и .. вперёд.
Для конкретных же заданий конкретным специалистам - просто пишите спецификации прямо по пунктам Требований.

... безусловно нужно понимать, что разработка по ГОСТ34 - это реально прошлый век и на данный момент используется только в Гос.структурах, однако использование Scrum и прочих модных технологий неподготовленными людьми может привести к очень даже былинному фэйлу

У автора ИГРОВОЙ проект, какой ГОСТ 34??

Denis Beskov

Я же прямо написал, что рекомендую "ознакомиться". Что именно в этом ГОСТе хорошо - так это избыточный для любого проекта, но очень полный набор типов требований.

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

Приведенный же Вами комплект документов глянул по диагонали - реально хороший пример.

Denis Beskov

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

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

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

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

Как использование ГОСТ 34 помогло бы избежать такой нежелательной (по всей видимости, для вас) ситуации?

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

А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?

А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?

Таки да!

Как использование ГОСТ 34 помогло бы избежать такой нежелательной (по всей видимости, для вас) ситуации?

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

ГОСТ34 в качестве  системы документирования проекта - тяжел и избыточен для подавляющего большинства современных прикладных задач. Мне например не доводилось не то, что использовать его в работе, но даже и готовых примеров документации не видел ни разу.
Но это не уменьшает его ценности в качестве шаблона. Можно очень долго рассуждать о том, что существуют требования "функциональные" и "нефункциональные", приводя при этом пару-тройку простеньких кейсов, но это не отразит всей палитры требований, в первую очередь - нефункциональных. ГОСТ же - отражает. И просто заставляет помнить о них.
ИМХО.

А должны ли разработчики тетрисов об этом думать? Может, это забота разработчиков железа и операционной системы?

Таки да!

Таки нет

Уж сколько раз призывы "поставить сервер помощнее" счастливо заканчивались простой оптимизацией кода.

Денис, еще раз. Не "использование", а "знакомство". Ок, давайте через аналогии.

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

Зачем знакомиться с ГОСТом на АС, если есть стандарты на работу с качеством ПО?

Что сказано в ГОСТ 34.602 про качество ПО и ограничения (о которых речь в приведённом вами кейсе)?

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:
1) к независимости программных средств от используемых СВТ и операционной среды;
2) к качеству программных средств, а также к способам его обеспечения и контроля;

Всё.

Что сказано в
 «ГОСТ 28195-89. Оценка качества программных средств. Общие положения» (того же года, между прочим)?

Там приведены около 20 показателей качества ПО, включая, например:

4.3. Ресурсоемкость. Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС

Что сказано в «IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению»?

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

Что сказано в ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению»?
Там выделено 6 характеристик качества ПО и 30 подхарактеристик, включая:

4.4 Эффективность (Efficiences)
Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
…
А.2.4.2 Характер изменения ресурсов (Resource behavior)
Атрибуты программного обеспечения, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функции.

Что сказано в «ISO 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models» ?
Там приведено уже 8 групп характеристик качества и около 50 конкретных атрибутов качества ПО, среди которых:

4.2.2
performance efficiency
performance relative to the amount of resources used under stated conditions
…
4.2.2.2
resource utilization
degree to which the amounts and types of resources used by a product or system, when performing its functions, meet requirements

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

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

Он отражает НФТ к ИС. Причём это ГОСТ 89-го года. Стандарты на качество ПО и систем серии 250X0 — 2007-2011-го годов, причём, как я показал выше, дают около 50 атрибутов качества ПО против одного абстрактного «качества ПО» в ГОСТ 34.602.

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

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

Таки да!

Разработчики игры должны следовать руководствам по разработке игр от держателя платформы. Но самостоятельно на низком уровне думать о зарядке/разрядке аккумулятора они не должны.

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