kn0ckn0ck

Используйте РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов ссылка

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

Что касается языков для описания/моделирования отчетных форм, то общеизвестных стандартов нет. Все это всегда привязано к конкретному BI-инструменту и встроено в его графическую IDE, при помощи которой эти отчеты создаются: MS SSRS, Crystal Reports, Cogons BI, Oracle BI и т.п.

В простых случаях можно было бы обойтись обычным UML с добавлением OCL, но разве вам этого будет достаточно?

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

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

1. просто - это User Story
2. чуть сложнее - UseCases, IEEE 830-1998
3. совсем тяжелый случай - ГОСТ 34, ГОСТ 19 или ГОСТ Р 51904-2002

Для эксплуатационной документации посмотрите РД 50-34.698-90

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

Учтите, что если разработчик требует ТЗ, то у него есть какое-то представление об этом и если вы ему не угодите, то он скажет, что ТЗ плохое. С этим ничего не поделаешь. Хорошее ТЗ писать могут не многие, этому учатся годами. Если у вас нет столько времени, измените стратегию. Замените качественную формализацию общением. Так и скажите разработчику: "у нас есть вся нужная постановка, а детали, конкретика и вопросы при личном общении".

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

Спрашиваешь... так делают процентов 90. Другое дело - правильно ли они поступают при этом? Часто документацию путают с проектированием. Это разные вещи и у них разные цели.

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

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

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

1. Зависит от сложности/объема задачи. Если все помещается в голове, то для чего тогда документация? Любая, UML или текст, не важно. Если что-то нужно продумать, то можно записать на доске/бумаге, сфоткать, потом выбросить.

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

3. Уважительной причиной чего-то не делать будет четкое понимание того, как связанные с этим риски минимизируются. Долой догмы. Если в среднесрочной перспективе мы четко осознаем, что фиксация/документирование требований не принесет пользы, то зачем тратить на это время/ресурсы?