В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?

Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.
Плюсы такого подхода:
1. Учитываются все требования
2. Наиболее понятны и детализированы для программиста
3. Наиболее понятны для заказчика, можно дать почитать

Хотелось услышать другие мнения и минусы моего подхода, если они есть.

Самым "сложным" случаем с т.з. процесса документирования требований будет такой, когда есть заказчик который трубует документацию требований в определенном формате (например по ГОСТ 34.602) а у компании-разработчика свои стаднарты (например те же UC и иже с ним). В этом случае нужно формировать документацию требований по ГОСТ из тех требований, которые создаются самими аналитиками компании-разработчика. Тут вариантов 2 либо делать требования в классическом иерархическом виде, что маппится 1 в 1 на ТЗ по ГОСТ, либо впихывать в ТЗ по ГОСТ (или в разные наборы документов по ГОСТ) юзкейсы и иже с ним. При всем при этом крайне желательно пользоваться каким-либо инструментарием и поддерживать синхронизацию изменений в обоих артефактах. Идеальный случай, когда требования ведуться в неком репозитории и документация создается автоматически.
Что касается использования юзкейсов -- то формально говоря, это пользовательские требования (по тому же Вигерсу). С другой стороны, в них содержится и собственно информация о том, какая функциональность должна быть в системе. Но формально говоря, (с т.з. формального определения из глоссария IEEE что есть требование) это <> функциональным требования. Т.е. UC это контейнер для функц. требований по большому счету. Да, можно описать достаточно подробно юзкейсы с дополнительными слотами, где учесть и некоторые нефункциональные требования, которые "привязаны" к данному UC. И для целого ряда систем этого будет достаточно для проектирования системы. Но следует помнить и тот факт, что не всегда удается описать юзкейсами всю нужную ФУНКЦИОАЛЬНОСТЬ системы. И это одна из причин почему их относят таки к ПОЛЬЗОВАТЕЛЬСКИМ требованиям. И даже если взглянуть на RUP, то там в Supplementary Spec. есть отдельные слоты для описания ФУНКЦИОНАЛЬНЫХ требований, которые не были охвачены юзкейсамы.

В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?

Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.

Саша, "мы добавляем к сценариям ВИ нефункциональные требования и бизнес-правила" - это не ответ на вопрос КАК мы описываем требования и с КАКОЙ детализациией

Мы стараемся выделять фунциональные требования, нефункциональные и ограничения.

Стремимся к такой модели по функциональным требованиям - 1-5 бизнес-задач, из них 10-20 бизнес-требований, из них 50-100 пользовательских требований. Проработка каждого следующего уровня выполняется при наличии ресурсов/критичности системы. Бизнес-задачи формулируются в виде утверждений, привязанных к целям системы. Бизнес-требования - как условия выполнимости этих бизнес-задач. Пользовательские требования, нефункциональные и ограничения начинают формулироваться примерно одновременно. Первоначально пользовательские требования формулируются в виде утверждений-целей пользователя. Затем по возможности описываются одним абзацем текста в виде краткого описания основного сценария прецедента. По возможности детализируются пошагово и снабжаются описаниями исключений.

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

Денис, согласен, описал как-то скомкано, но было поздно, а хотелось дать пищу для размышления.

И так, требования именно к ПО мы описываем в виде единого документа (шаблон взят из SRS) :
1. Функциональные требования - в виде ВИ, т.е. пользовательских требований. На первом этапе только сами ВИ и их краткое описание, далее заполняем всю спецификацию
2. Не функциональные требования и ограничения описываем в виде одного-двух предложений
3. Дополняем диаграммой ВИ, которая называется "функциональная модель Системы"
4. Дополняем диаграммой бизнес сущностей - "Структурная модель Системы"
5. Каждый ВИ может быть дополнителнен макетом формы
6. БПравила описываем либо отдельно в каждом ВИ, либо (и) в отдельной секции.
7. После рекомендации Юрия, добавлю еще секцию - "Доп. функц. требования"

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

Саша, нужно смотреть конкретно что за проект и что за юзкейсы, чтобы можно было действительно рекмендовать добавить дополнительную секцию.

Это понятно, что если надо, то добавляем, если нет, то не добавляем. В принципе, у меня все функц. требования укладываются в ВИ и БПравила. Просто взял твою рекомендацию на заметку.

Вполне разумный подход -- не описанные требования (функц. и нефункц.)  описывать в другом артефакте (как это в RUP сделано) и трассировать на UC, в случае связки.

Это да, но не прижилось у нас как-то использование RMS (requirements management system), т.к. бОльшая часть людей пишут спеки как попало ...

Если нет контрактных ограничений на формат документации требований, то я предпочитаю для нового проекта сначала написать Vision, где явно сформулировать какие бизнес-проблемы будут решены этим проектом (суть бизнес-требования), описать стейкхолдеров и софрмулировать основные фичи системы. При "идеальном" проекте, провязываются фичи с бизнес-требованиями. Рисуем контекстную диаграмму, чтобы определить опять-таки общие границы. И озвучиваем предположения которые делаем, вместе с ограничениями и обещаниями (по срокам, например)
Далее -- юзкейсы (если они применимы). Степень детализации зависит от конкретного проекта. Когда очень поверхностно, просто чтобы зафиксировать concept of operations, но тогда в SRS делаем более детальную проработку на уровне функциональных требований. А когда и достаточно детально, тогда имеет смысл использовать Supplementary Spec. а не SRS. А иногда, если и так все понятно ;-), ограничиваемся только юзкейсами. Повторюсь, что зависит от конкретного проекта.

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

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

anastazya, а Вы в какой области работаете? Адаптируете и внедряете какие-то бизнес-системы других производителей, или работаете аналитиком в компании, разрабатывающей собственный софт?

greesha, разрабатывающей собственный софт

ida, а как спец по функ. дизайну поймет какие реквизиты на форму надо помещать, если я их не укажу? Если для заполнения определенных реквизитов нужны определенные правила заполнения? Вот что мне хотелось бы знать

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

Можно описать не поля форм, а структуры данных в виде словаря данных (по Вигерсу), где описывается некая сущность и ее "информационный состав" - суть ее свойства (в терминах OOP). Например:
Клиент = ФИО {текст; required}
+ Адрес {текст; required}
+ Год рождения {текст; required}
+ Паспорт {текст; required}
+ Девичья фамилия матери {текст;}
+ Кличка собаки {текст;}
+ ...

тем самым вы четко даете понять на раннем этапе, какая информация о Клиенте в контексте вашего домена важна ...

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

В более типовой ситуации дизайн форм является все-таки предметом какого-то отдельного внутреннего документа разработки, а в согласуемом с заказчиком ТЗ эти сведения даются в более общем виде.

Можно в ТЗ описывать и данные, как сказал Юра, и формы, как Михаил, главное их разнести по разным документам или хотя бы по разделам, и из основных ФТ ссылаться на них

Можно в ТЗ описывать и данные, как сказал Юра, и формы, как Михаил, главное их разнести по разным документам или хотя бы по разделам, и из основных ФТ ссылаться на них

Мы на проекте пишем ВИ, далее все сущности описываем как сказал Юрий, с атрибутами и ограничениями, выдирая сущности из бизнеса или ВИ.
Далее на основе все тех же ВИ рисуем прототипы GUI - в описании полей даем ссылки на атрибуты сущностей.
+ трассировка от ВИ к сущностям и от ВИ к гуям.