Всегда задачался вопросом, работая на стыке БА и СА - писать требования одним документом, или же отдельными постановками, подумал над этим вопросом, мысли записал...
Надеюсь на конструктивную критику

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

Один большой документ на всем протяжении проекта
Изначально при работе с заказчиком мы собираем требования, формируем ТЗ (которые в моей практике зачастую выглядят как требования разработчикам, так что тут ТЗ=постановки на реализацию), а после чего нам необходимо этот документ подписать.
В каком случае мы можем работать с одним документом? Такая ситуация может возникнуть, если над проектом работает один аналитик, а так же один или множество заказчиков. При работе с множеством заказчиков в одном документе потребуется хорошо планировать работу, чтобы проверку требований и реализации заказчики осуществляли поочередно. Это очень тяжело, так что я всегда вел требования каждого заказчика в отдельном документе, а после согласований их объединял. В данном случае, если заказчиков множество, то придётся распараллелить их работу по согласованию документа, что скажется на сроках проекта.
В написании требований одним документом есть следующие преимущества:
Сквозная нумерация разделов (которая, правда, может поехать при обновлении формул, но ведь гораздо удобнее написать - делай ФТ12.1.13, чем делать ФТ*************** ******* ******** ****** (****** ******)
- Сквозная нумерация полей (и формул), требований в системе.
- Описание формул при помощи ссылок на их уникальные номера. Согласимся, что написать в формуле расчета: 546/32, если 96>12 будет гораздо быстрее, чем писать, что итог  =поле  *** справочника ***, деленное на поле *** справочника ***, вкладки ***, при условии, что поле *** документа *** больше поля *** справочника ***. И это ещё не самая изощрённая формула...
- Удобство поиска (ищем в одном документе, а не перебираем множество существующих)

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

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

Много документов и мы можем эти документы по отдельности подписать
Если проект автоматизирует какую-либо большую область, то тут уже требуется работа нескольких аналитиков, особенно, если объемный проект следует выполнить за более короткий срок, чем если его будет вести один аналитик.
Мне, например, гораздо эффективнее и комфортнее работать как минимум в паре, постоянно критикуя каждое требование и идею друг друга, а потом фиксируя решение. При такой организации работы можно осуществлять тестирование требований, обсуждать их и спокойно уходить в отпуск, не боясь звонков и вопросов. Однако работа в команде сразу говорит о том, что у вас не получится писать ТЗ в одном документе.
Значит, такое случается, если аналитиков много, а каждый из них пишет свою часть (либо аналитик не сумел распараллелить заказчиков). Либо одна часть будет равна тому объему работы, который взял на себя аналитик, либо, документ будет реализован на каждую фичу (я так никогда не работал, рассмотрю это в следующий раз), либо на каждый объект в системе. В итоге все это нам подписывает один человек и он согласен на кучу документов.
Подход
Кучу мелких доков писать несколько дольше с той точки зрения, что мы не можем использовать нумерацию полей, либо же потребуется использовать префикс в каждом документе (кстати, читай - интерфейсе), а формула будет выглядеть например так “=БС13/(ПС42 - КОП56)”. Можно писать все текстом, здесь есть плюсы и минусы - с одной стороны, при переименовании поля - не надо его же переименовывать во всех документах, с другой, без открытия дополнительных файлов можно узнать что считает формула, а так же нет трудностей при изменении местоположения поля, если их номера соответствуют порядку отображения (что логично).
Большим минусом могу выделить поиск по документам и необходимость держать в голове все формулы, где используется данное поле, чтобы апдейтить другие документы. Возможно, проблему решит матрица трассировки, но в ней будет мало конкретики, если привязывать документ к документу.
Опять же можно выделить отдельно ексельник с формулами (можно вообще пойти по пути создания прототипов в каком-нибудь Axure и екселе с формулами на него).
Либо мы можем объединить все мелкие доки в один большой, а писать его в  3 руки в гугл доках (пока всемирное торможение гугл дока не поглотит проект странице к 30-й).

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

Большой пост не лезет и тормозит... выложил на блоге:
http://akiselev87.wordpress.com/2011/02/16/%d1%82%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%be%d0%b4%d0%b8%d0%bd-%d0%b4%d0%be%d0%ba%d1%83%d0%bc%d0%b5%d0%bd%d1%82-%d0%b8%d0%bb%d0%b8-%d0%bc%d0%bd%d0%be%d0%b3%d0%be/

Основное сюда сумел впихнуть...

А Вы никогда не пытались посмотреть, что по этому поводу рекомендует RUP?
Или, например, Коберн?

Читал, но лично для меня на этом вопрос снят не был. RUP и, можно сказать, госзаказчик с водопадом (которому бегом нужен итог с прототипами, а не юз-кейсы, которые он не хочет читать) у меня вообще не стыковались, как не крутить.
Тут мне больше Леффингуелл помог, но на текущий вопрос однозначного ответа все равно у меня нет.

А "для работы" Вы use cases моделируете? На каком инструменте?

А "для работы" Вы use cases моделируете? На каком инструменте?

Это смотря что понимать под "моделировать use cases". В 80% случаев достаточно нарисовать общую UC диаграмму, а дальше все текст. До сторибоардинга у меня лично дело доходило только 2 раза в жизни :-).

У каждого из тех, кто долго работает в какой-то сфере, вырабатываются свои приемы и стиль.

Я, например, давно не пишу документов, а думаю в терминах модели. И пишу шаблоны генератора отчетов (редко, т.к. наработал структуры моделей и шаблоны для них).
Мне легче рисовать на UML, чем писать, даже во время интервью.

Из одной общей модели можно "нагенерить" множество отчетов самого разного вида, размера и содержания.

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

Ты, Юра, редко доходил до "сторибоарда"? А зря!

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

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

Важно различать проблемы:
*декомпозиции системы и декомпозиции документа.
*совмещения в одном документе описания требований Заказчика и постановок на их реализацию для разработчика.

О декомпозиции

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

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

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

Касательно совмещения требований и постановок: если Заказчик требует ТЗ по ГОСТ, то стоит ли описывать в ТЗ детали реализации, которые важны разработчикам, но не очень важны Заказчику (полагая, что Заказчику нужен результат - выход функции)?

О декомпозиции при объектном подходе

Исторически так сложилось, что бизнес, как правило, мыслит в терминах функциональной модели, а разработка ведется в объектных подходах. Ориентированные на RUP и UML методологии (см.например, G.Overgaard, UML blueprints),  предполагают декомпозицию системы, прежде всего по вариантам использования. Декомпозиция по документам для Заказчика, по идее, может идти по вариантам использования. Но опять же, пока мы описываем систему в терминах вариантов использования. Если же мы начинаем рисовать диаграмму классов системы, причем на уровне, необходимом разработчикам системы, то её декомпозиция (особенно по вариантам использования) и поддержание её в консистентом и актуальном виде представляется вообще весьма трудоемкой и даже проблематичной задачей.

Опять же касательно совмещения требований и постановок:
Стоит ли включать детальные требования в ТЗ для Заказчика? Стоит ли вообще пытаться оформлять детальные требования (постановки) в рамках объектного подхода в виде официального документа - ведь не на зря были предложены Agile-подходы ?

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

А вы пробовали рассылать документ одновременно на согласование разным заказчикам (распараллеливать)? Хотя бы в электронном виде?  Если речь идет о согласовании с Заказчиками - специалистами различных подразделений, то, они же, как правило, смотрят документ под разными углами зрения и "технически" свести их требования в одном документе, как правило, можно очень быстро. Если этапу согласования требований предшествовал этап сбора требований, то чем качественнее удалось выявить требования при обсуждении с заказчиками, тем меньше должно быть проблем при согласовании.
И опять же вопрос - насколько детально нужно описывать реализацию, чтобы её проверял Заказчик?

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

Если система декомпозирована на взаимодействующие элементы и каждый аналитик отвечает за требования к элементу (компоненту, ВИ, фиче) то "взаимодействие" аналитиков (возможно, с перекрытием зон ответственности) неизбежно, хотя описанное Вами полное дублирование функций вряд ли разумно с точки зрения затрат на проект.

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

В описанной ситуации угадывается практика ведения документов по ГОСТ в режиме изменения. Если у Вас поехала нумерация (даже страниц) заменяете весь текст начиная с первого изменения в режиме "Лист 23-54 заменить на прилагаемые листы 23-54" "Добавить новые листы 55-57" если количество листов увеличилось или "Изъять листы 55-57", если количество листов уменьшилось. Описываете это в извещении на изменении (Excel ГОСТом не предусмотрен:) с общим указанием, что именно изменили в документе (3-5 предложений).

 Номер страницы такой же важный параметр документа, как и номер формулы. Если у Вас в листе хоть что-то изменилось, да еще если в тексте есть ссылки на номер страницы, рисунка формулы и хоть какой-то номер сместился - заменяйте все страницы (по крайней мере до начала очередного раздела), не мучайтесь .

У каждого из тех, кто долго работает в какой-то сфере, вырабатываются свои приемы и стиль.

Я, например, давно не пишу документов, а думаю в терминах модели. И пишу шаблоны генератора отчетов (редко, т.к. наработал структуры моделей и шаблоны для них).
Мне легче рисовать на UML, чем писать, даже во время интервью.

Из одной общей модели можно "нагенерить" множество отчетов самого разного вида, размера и содержания.

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

Ты, Юра, редко доходил до "сторибоарда"? А зря!

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

Ну, меня "не надо агитировать за советскую власть", я это прекрасно понимаю, но ...  дело не в гос. заказчиках или коммерческих структурах. А дело скорее в:
 а) усилиях в соотношении с результатом
 б) готовности заказчика к восприятию результатов в предложенном формате (даже с использованием синонимов)
 в) адекватности использования инструмента (не инструментария!)/подхода для конкретного проекта.

Например, у меня в одном из проектов проектов с негосударственным, российским заказчиком (их департаментом ИТ) возникла ситуация, когда они наотрез отказались от юзкейсов, считая что в спецификациях, "многа букфф" (делалось близко к Коберну, причем для упрощения были только "user goal" и один несчастный "subfunction", всего 10 юзкейсов), а диаграммы "это просто картинки". Им в ТЗ текст нужен был по классике - нумерация пунктов и утверждения типа "система должна ...". Другой вопрос, что цели создания системы от задач отличить не могут, и с ГОСТами не в ладах, но терминами из ГОСТа пытаются оперировать, вкладывая иногда в них такое ... ... но это сплошь и рядом :-). А собственно проект - по внедрению и настройке под нужды заказчика готового решения. В данном случае, использование юзкейсов (в виде общей диаграммы и спецификаций) было вполне оправдано - очевидно, что из них было бы очень удобно сделать тест-кейсы потом для ПМИ и все бы от этого выиграли (это к вопросу об адекватности инструмента/подхода для конкретного проекта да и об увеличение продуктивности), но налицо  несоответствие п. б). Пытаться "лечить" - бесполезно (да и мне не за это платят).

Иметь единую модель и из нее генерить документацию - идея очень хорошая, но как правило затратная, особенно для проектов "fire and foget". Именно поэтому ни один из российских офшорщиков, (да и западных тоже) ее не внедрил в полном объеме. И именно по этому так популярна тема agile. А вот для продуктовой разработки, особенно если это некая ERP или просто отраслевая масштабная система, с насыщенной бизнес-логикой и перспективой доработок на 5-7 лет вперед и хорошим бюджетом - очень даже (особенно на деньги инвесторов :-)) ... но таких в России крайне мало. Но даже это не будет гарантией, что заказчик в конечном итоге получит хороший продукт. Так что идея классная, но продается она с трудом :-). А вот agile - как горячие пирожки расходился до недавнего времени :-) - ибо достаточно адекватный инструмент для российской (и не только) действительности.

Shur, спасибо большое за развернутый ответ и пищу для размышлений. Один нюанс - предаставитель заказчика отчасти выступал как БА, то есть он формулировал свой бизнес процесс, но ещё и интересовался СА - сам, например, описывал формулы расчета некоторых полей.
Не могу сказать, что проект был не по ГОСТу...
А вот про разработку систему от функций я наслышан, но практических примеров не видел.. Нет ничего такого, прочитать или хотя бы на пример посмотреть?

Shur, спасибо большое за развернутый ответ и пищу для размышлений. Один нюанс - предаставитель заказчика отчасти выступал как БА, то есть он формулировал свой бизнес процесс, но ещё и интересовался СА - сам, например, описывал формулы расчета некоторых полей.
Не могу сказать, что проект был не по ГОСТу...

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

Нужно ли указывать в требованиях (ТЗ) в каком поле какой интерфейсной формы эти расчетные показатели  должны отображаться? И если да, то не должно ли описание интерфейса с приложением интерфейсных форм отнесено в документы технического проекта (если он документируется по ГОСТ)? У Вас тогда будет время продумать дизайн интерфейса и согласовать его с Заказчиком позже, при утверждении  (технической) проектной документации.
Если же Заказчику важен, например, размер полей печатной формы отчета в зависимости от объема и содержания представленной в отчете информации - то это компетенция СА. Но это, наверное, не Ваш случай?

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

Вы, наверное, знакомы с методологией SADT, IDEF0? Требования к документам ГОСТ очень удобно воспринимать под углом зрения этой методологии и соответствующей нотации. Единственно, что ГОСТ не выделяет явно входы "управление" и "ресурсы". Принципиально важно исходить из того, что функция задается описанием входов и выходов (с указанием соответствия выходов выходам). "Задача" по ГОСТ - это функция или часть функции. А документ "Описание постановки задачи" как раз предполагает описание этих входов и выходов, его можно использовать для того, чтобы расписать каждую функцию из ТЗ.

Если Вы имеете в виду под разработкой реализацию системы в коде, то важно учитывать, что методологию SADT изначально не предполагалось использовать для низкоуровневого описания системы. Авторы самой известной книги по SADT "МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ" Дэвид А. Марка и Клемент МакГоуэн писали во введении к книге:

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

Поскольку методология SADT создавалась в 60-80-е годы и предназначалась для описания системы на бизнес-уровне, она не учитывает особенности современных средств программной реализации. ГОСТ 34 (да и ГОСТ 19) - стандарты эпохи SADT, в силу этого не очень приспособлены, да, видимо, и не предназначались для описания  детальных требований к программной реализации (разработке) системы, что может создавать проблемы при проектировании системы с использованием SADT.

Например, IDEF0 предполагает, что выход и выход системы - это "данные", "сигналы". Причем на выходе и выходе - разные данные. Если же (на бизнес уровне) на входе и выходе одни и те же объекты (системный уровень), но в разных состояниях, то получается скорее диаграмма состояний, которую лучше тогда рисовать с использованием соответствующей нотации (например, в UML).
Описание с помощью ВИ функциональных требований к системе, разрабатываемой в объектной парадигме,  проблемы такого рода снимает, поскольку концепция use cases развивалсь в рамках ООП и акцентирует ИМХО скорее процесс, алгоритм, а не входы и выходы (с оговоркой важности указания предусловия и постусловия ВИ и наличия полезного для пользователя результата ВИ).

Нужно ли указывать в требованиях (ТЗ) в каком поле какой интерфейсной формы эти расчетные показатели  должны отображаться? И если да, то не должно ли описание интерфейса с приложением интерфейсных форм отнесено в документы технического проекта (если он документируется по ГОСТ)? У Вас тогда будет время продумать дизайн интерфейса и согласовать его с Заказчиком позже, при утверждении  (технической) проектной документации.
Если же Заказчику важен, например, размер полей печатной формы отчета в зависимости от объема и содержания представленной в отчете информации - то это компетенция СА. Но это, наверное, не Ваш случай?
/quote]

Да, нужно.
И это как раз мой случай из предыдущего проекта - заказчику было интересно юзабилити, причем зачастую он принимал решения по реализации интерфейса, считал лишнии клики и тп. Ещё, например, сколько строк делать в поле -1 или 5..

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

Только вот всё равно волнует - один документ или много...?

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

Вы уже, кажется, описывали этот проект здесь  в ответах 17 и 19 на форуме. Немного странно показалось, что описание структуры данных хранилось в "файле атрибутов". Использовалась ли в проекте диаграмма(ы) классов (с отображением на ней показателей, которые надо отображать в интерфейсе)?

Только вот всё равно волнует - один документ или много...?

Вряд ли можно дать ответ на этот вопрос до решения, как именно (и на что) декомпозируется система. Иначе есть риск написать полтора документа на две с половиной подсистемы .

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

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

В feature driven development (FDD), которая рассматривает доменную модель в качестве одного из основных артефактов, эта модель как раз используется для декомпозиции всей области на предметы (subject areas). Тоже способ декомпозиции.