Немного встряну в разговор... У Владимир Сидоров - типичный Agile со всеми вытекающими. А у Ndochp - типичный водопад (или "хочется, чтобы бы водопад"). Два разных подхода - и что конкретно нужно в вашей ситуации - решать только вам.
sim3x: Неверный ответ. Хотелки пользователя - материал для написания только того, что входит в п.1 (см. мой ответ). В этот момент они могут быть: изменены, доработаны, полностью отменены, как нереализуемые. Все, начиная с п.2 до п.6 - создается внутри компании, поэтому хотелки пользователя не являются базой все документации.
kiru: Это не ТЗ - это именно концепт. В ТЗ много таких вещей, при осознании которых у обычного пользователя обычно появляется грусть в глазах. Обратите внимание, что я вам дал структуру, а уж ее наполнение - полностью в вашей ответственности (можно и две страницы соорудить под эту стуктуру). Тем более, в ваших словах есть нестыковочка: вы говорите сначала о презентации (т.е. интерактиве), а затем говорите о страницах (т.е. печатном представлении). Вы определитесь для начала, какой способ представления вы хотите получить.
Список вопросов, которые надо задать самому себе перед тем, как что-то предпринимать. Смотрим сюда: Какой инструмент документирования подойдет?
затем отвечаем на эти вопросы. Тогда можно будет что-то посоветовать.
kiru: скажу лишь за содержание. Как делать именно представление (т.е. графическую выкладку) - думаю, вам лучше подскажут UX-люди.
Кратко:
- Назначение презентации
- Цель создания системы
- Потребности пользователей (расписать)
- Общее представление о продукте (расписать)
- Ограничения продукта
- Schedule разработки (не в смысле времени, а в смысле порядок реализации функционала)
- Дополнительные требования (например, стандарты, требования со стороны гос. органов и т.п.).
Если кратко, то внутри обоих docbook-документов с общим содержимым надо сделать нечто подобное:
Т.е. идет ссылка на общий документ included_common_doc.xml. Он изменятся - изменяется раздел в каждом из документов.
Если надо подробно (про установку, настройку и т.п.), я вам предлагаю переместиться вот сюда ( forum.singlesourcing.ru ). Там такие темы более уместны (потом просто можно будет сделать ссылку отсюда).
Проблема в том, что по моим сведениям правообладатель Syntext Serna приостановил ее распространение аж в 2013 году. Так что простого ответа на ваш вопрос нет. Я знаю, что отделы техдокументирования Яндекса пользуется Серной для своих целей (там она используется в связке с DITA). Если есть там знакомые - можете поспрашивать. Лично я для docbook документов пользуюсь вот этим: www.xmlmind.com/xmleditor Стоит денег (только для opensource проектов вряд ли подойдет), но оно того стоит. Еще есть вариант - OxygenXML, но он еще дороже.
Mike Evstropov: Прошу прощения, но я специлизируюсь только на сложных вещах :)
Попроще... https://readthedocs.org/ ? Что-нибудь из разряда: .rst, .md, .adoc Но здесь, конечно, речь идет о "ручном" написании, а не генерации из кода.
Дело в том, что если вы стартап - то да, сложные решения сложны для вас. НО, ведь каждый стартап хочет перерасти посевную фазу и вырасти во что-то приличное. Значит при выборе нужного средства (даже простого на первом этапе) вам в любом случае надо думать о возможном масштабировании вопроса.
Да, и еще, можете попробовать посмотреть на какой-нибудь бундесбирже фрилансеров. Немчики хорошо делают дизайн - не знаю, почему. Наверное, у них развито направление Visual Art.
"Дело в том, что есть ощущение, цитата: "весь дизайн сделали сами - проще, быстрее, дешевле." — что так и выйдет. Только времени жалко на такую лабуду."
Дело в том, что это не лабуда. Если вы сделаете сами, то вы НЕ получите:
1. Головняка при взаимодействии со фрилансером.
2. Срывов сроков работ.
3. Неподконтрольный дизайн, который утечет еще хрен знает во сколько компаний.
Да, иногда приходится заниматься неподходящими делами, но это экономит столько нервов и времени, что иногда после завершения думается: "не зря все же взялись" :)
"Дизайн нужен, чтобы гайд выглядел нормально..." - это не ответ :) Ответ это - "чтобы продать подороже". "чтобы нас воспринимали, как крутых чуваков, способных замутить крутую документацию", и т.п.... ну, вы поняли :)
FYI: "Шрифты тоже не интересно, есть корпоративный стандарт" - кстати, это часть дизайна. Кроме того, учтите, что многие шрифты нельзя поставлять на внешний рынок, если они не куплены! Имейте в виду, что может возникнуть ситуация, когда дизайнер вам скажет - такие шрифты использовать не будем.
Что касается минимализма, что самый что ни на есть минимализм - у DAPS (гуглите: DAPS opensuse print manual в поисках по картинкам).
Насчет остального, то варианта два:
1. Вбить в гугле: user manual system requirements filetype:pdf и пройтись по десятку существующих. Вторая фраза нужна для того, чтобы отсечь все руководства по хардверным штукам. Там в смысле дизайна бывает иногда такая жесть, что ...
2. фрилансеров, как подсказывают ниже. Но, как показывает личная практика, все зависит от исполнителя. У нас было так, что в итоге весь дизайн сделали сами - проще, быстрее, дешевле.