Мой комментарий был в том ключе, что у вас обоих разные подходы. И, судя по логике, у вас используется именно водопад (м.б. это требование заказчика, не знаю). А что вы в итоге выберете - это уже вам решать.
Немного встряну в разговор... У Владимир Сидоров - типичный 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. Неподконтрольный дизайн, который утечет еще хрен знает во сколько компаний.
Да, иногда приходится заниматься неподходящими делами, но это экономит столько нервов и времени, что иногда после завершения думается: "не зря все же взялись" :)
