Часто встречаю ТЗ как некий структурированный список требований.

Когда вижу список, всегда возникают вопросы:
А) откуда взялось данное требование?
Б) Насколько оно обосновано?
В) Достижению какой цели оно служит?
Г) А вдруг какие-то требования упущены?

Да, есть ряд методик по выявлению требований, основная из которых - куча мала - мозговой штурм - понакидаем мнения разных людей разных компетенций, thousand lemmings cannot be wrong, collaboration rules и всё такое. Потом этот поток сознания отсортируем по кучам, выявим дубликаты, разрешим противоречия - типа получим что-то более менее целостное и внушительное. Но - devil's in details - не всегда есть возможность привлечь многих людей и самое главное - заданные мной вопросы остались без ответа!

Есть другой хороший подход - сценарии использования, пользовательские истории и т.д. - Они позволяют компактно свернуть требования и связать их по целям в единые цепочки. Это клёво. За это честь и хвала Якобсону с Коберном. НО. Остаются нефункциональные требования, про которые Якобсон что-то неуверенно мямлит в Use-cases Patterns. Остаётся риск того, что какие-то use-case'ы будут невыявлены. Остаётся вопрос о взаимосвязи целей Пользователя с Целями Заказчика.

"Система должна иметь пользовательскую документацию" - это нужно или нет? Чьё это требование, чьи целям служит? Каким именно? Где они обозначены?

"Система должна иметь документацию по внутреннему устройству" - это чьё? Кто сказал? Почему это решается чьим-то волюнтаристским решением, а не исходя из целесообразности (соответствия конкретной цели, которая иначе не будет достигнута)?

Отдельно стоит рассказать про проблемы ГОСТ 34.602 и главное - как их преодолевать. Но об этом позже.

А пока - как выстроить полный, взаимосвязанный набор требований нужной степени детальности, не ограничивая реализацию и не оставляя провалов в связи с целями системы? Как обеспечить целостное видение системы, а не набор утверждений, висящих в воздухе?

NB: в дополнение - мой полугодичной давности пост "Типовые ошибки ТЗ".

Вот, что я думаю по этому поводу.

Любая информационная система включает такие важные элементы как
информационное обеспечение
техническое обеспечение
математическое и программное обеспечение
организационное обеспечение
правовое обеспечение и т.п.

Отсюда следует, что создаваемая ИС должна отвечать требованиям, которые накладываются на эти виды обеспечения.
Скажем откуда взялось требование наличия пользовательской документации? Безусловно оно вытекает из хотя бы такого факта, что система делается для людей, которые будут пользоваться ее. При анализе возможного решения мы изучаем потребности пользователей, но не конкретных Маш И Саш, а их архетипов. Вот и причина такой документации

Система должна иметь документацию о внутреннем устройстве.  Любая система как элемент содержит такую составляющую как персонал. Соотвественно данная документация направлена на обеспечение нормальной работы персонала ИС.

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

Вот, что я думаю по этому поводу.

Любая информационная система включает такие важные элементы как
* информационное обеспечение
* техническое обеспечение
* математическое и программное обеспечение
* организационное обеспечение
* правовое обеспечение и т.п.

Отсюда следует, что создаваемая ИС должна отвечать требованиям, которые накладываются на эти виды обеспечения.

О, ОБЕСПЕЧЕНИЕ - это один из самых дурацких терминов, всё давно хочу пройтись по нему Что такое в данном случае ОБЕСПЕЧЕНИЕ - это ОБЪЕКТ, ПРОЦЕСС, УСЛОВИЕ, ПОДСИСТЕМА? Что-то другое? Что?

По поводу "и т.д." - лингвистическое обеспечение нужно? А технологическое? А где полный перечень? Где-таки ответы на вопросы А-Г? Кто сказал, что люой системе нужно каждое это ОБЕСПЕЧЕНИЕ?

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

ВЫТЕКАЕТ - это хорошо сказано. А если системой будут пользоваться не люди, а она инфраструктурная? Т.е. мы должны иметь перечень правил формирования требований типа:
...
Правило 143.2.а Если систему будут использовать люди, ТО нужна пользовательская документация. ЕСЛИ систему не будут использовать люди, ТО пользовательская документация не нужна.
...

Система должна иметь документацию о внутреннем устройстве. Любая система как элемент содержит такую составляющую как персонал. Соотвественно данная документация направлена на обеспечение нормальной работы персонала ИС.

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

Как я понимаю, ты сам прекрасно видишь ответ на свои вопросы.

У меня есть идея для метода выявления требований, но она никак не "прекрасно видима".

По моему очень скромному мнению, целостное видение системы формируется из различных моделей и артефактов.

Короче, сплошной постмодернизм. Значит, владелец системы, который сформировал концепцию системы, которой созданная система соответствует, целостным видением её не обладает?

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

Я бы даже сказал так, что под определённым углом всё есть требования, как всё есть игра и т.д.

Часто встречаю ТЗ как некий структурированный список требований.
Когда вижу список, всегда возникают вопросы:
А) откуда взялось данное требование?
Б) Насколько оно обосновано?
В) Достижению какой цели оно служит?
Г) А вдруг какие-то требования упущены?

Т.н. "Best practices" в области RDM в какой-то степени призывают давать ответы на эти вопросы. Например, даже в интсрументарии управления требованиями (в том же CaliberRM) есть predefined атриибут source, в котором обычно указывается источник требования -- либо stakeholder, либо некие праврвые акты и т.п. Кроме этого, если формулируются бизнес требования (и в частности бизнес-цели), то приводиться трассировка например пользовательских требований на бизнес-требования, тем самым показывая удовлетворению каких бизнес-требований (в общем случае) служит конкретное пользовательское требование и далее на функциональные требования.
Упущены или нет какие-то требования ... это вопрос можно интерпретировать двояко (в чем его прелесть :-)). С одной стороны это "не упщена ли какя-нить точка зрения на систему или некая характиристика, общая вообще для всех информационных систем". Для того, чтобы не упустить какие-то аспекты в такой постановке вопроса, следует придерживаться некой классификации требований. Классификация по сути дает различные взгляды на то, что из себя должна предствалять система. Некая классификация как правило ложится в основу стандартов на документацию требований, как структура разделов документов или набора документов. Другая интрепретация -- "а не упустили ли мы конткретное потребительское свойство системы", ну например, факт, что все кнопки должны быть зеленого цвета. Тут гарантий нет, и именно поэтому вся надежда на опыт аналитика и основательность заказчика.
Всегда стоит отдавать себе отчет, что требования это все-таки область с достаточно высокой энтропией, которая компенсирукется в т.ч. и за счет компетенций конкретных личностей.

Да, есть ряд методик по выявлению требований, основная из которых - куча мала - мозговой штурм - понакидаем мнения разных людей разных компетенций, thousand lemmings cannot be wrong, collaboration rules и всё такое. Потом этот поток сознания отсортируем по кучам, выявим дубликаты, разрешим противоречия - типа получим что-то более менее целостное и внушительное. Но - devil's in details - не всегда есть возможность привлечь многих людей и самое главное - заданные мной вопросы остались без ответа!

Да, есть такие методоики. Они не дают 100% гарантии, как например использование генетического алгоритма не дает гарантии достижения абсолютного min. А дает good enough решение. Но с другой стороны, лучше иметь хоть какие-то методики, чем вообще никаких.

Есть другой хороший подход - сценарии использования, пользовательские истории и т.д. -
Они позволяют компактно свернуть требования и связать их по целям в единые цепочки. Это клёво. За это честь и хвала Якобсону с Коберном. НО. Остаются нефункциональные требования, про которые Якобсон что-то неуверенно мямлит в Use-cases Patterns. Остаётся риск того, что какие-то use-case'ы будут невыявлены. Остаётся вопрос о взаимосвязи целей Пользователя с Целями Заказчика.

Такой риск он всегда остается. Но рулит принцип Парето, если нам удалось выявить те самые 20% которые обеспечивают удовлетворение 80% потребностей -- честь нам и хвала, и это можно считать заслуженным успехом. Ведь усложнять просто, а упрощать сложно.
Связь целей пользователя и "интересов заказчика" неплохо подает тот же Коберн, и вводит соотсветствующий слов в описание юзкейса. И он незря говорит что нужно помнить про защиту интересов стейкхолдеров в каждом юзкейсе. Другой вопрос что на практике не всегда удается "защитить интересы" ибо ИХ ПРОСТО МОГУТ НЕ ОСОЗНАВАТЬ или просто их не хотят по какой-то причине озвучивать (например политической).

"Система должна иметь пользовательскую документацию" - это нужно или нет? Чьё это требование, чьи целям служит? Каким именно? Где они обозначены?

Это может оказать влияние на требования supportability или на требование что некий усредненный пользователь должен затратить на освоение системы не более какого-то времени (usability)

"Система должна иметь документацию по внутреннему устройству" - это чьё? Кто сказал? Почему это решается чьим-то волюнтаристским решением, а не исходя из целесообразности (соответствия конкретной цели, которая иначе не будет достигнута)?

Явно может повлиять на то же supportability наличие или отсутствие документации ... а если не дай бог эксплуатирующая организация/подразделение имеет SLA с бизнес-заказчиком? То уж точно потребуют схему БД и т.п. ...

О, ОБЕСПЕЧЕНИЕ - это один из самых дурацких терминов, всё давно хочу пройтись по нему Что такое в данном случае ОБЕСПЕЧЕНИЕ - это ОБЪЕКТ, ПРОЦЕСС, УСЛОВИЕ, ПОДСИСТЕМА? Что-то другое? Что?

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

По поводу "и т.д." - лингвистическое обеспечение нужно? А технологическое? А где полный перечень? Где-таки ответы на вопросы А-Г? Кто сказал, что люой системе нужно каждое это ОБЕСПЕЧЕНИЕ?

Читай основы информационных систем. Нужно или нет любой ИС каждое из обеспечений вопрос, конечно, спорный. Однако мы можем точно сказать исходя из определения ИС, что требуются технические, программные средства, информационная составляющая и персонал. Без этого нет ИС, а остается например приложение. Можно ли назвать систему Гарант информационной - и да, и нет. Если это отчуждаемый продукт - то мы знаем для его работу нужен компьютер и приложение. Однако кто-то занимается наполнением Гаранта, его обновлением и прочее. Так или иначе я бы не стал называть гарант ИС - есть предоставление информации, но нет ввода, обновления и изменения ее, кроме как общее обновления релиза.
А вот скажем систему управления контентом Joomla, Drupal и т.п. можно смело называть ИС - присутствуют все необходимые ее компоненты. Не будет администратора - система превратится в простую справочную...

ВЫТЕКАЕТ - это хорошо сказано. А если системой будут пользоваться не люди, а она инфраструктурная?

Что значит инфраструктурная? Корпоротивная сеть? Но разве там нет пользователей, админперсонала? ресурсов хранения? аппаратных и программных средств?

Т.е. мы должны иметь перечень правил формирования требований типа:
...
Правило 143.2.а Если систему будут использовать люди, ТО нужна пользовательская документация. ЕСЛИ систему не будут использовать люди, ТО пользовательская документация не нужна.
...

есть понятие ручная информационная система
автоматизированная ИС
автоматическая ИС

Нужнали пользовательская документация? Весь вопрос в том кто пользуется. Ясно что если система делается для реализации функций людей - нужна однозначно (справка или документация не важно)
Если система полностью автоматическая - нужна документация ориентированная на обслуживающий персонал - читай теже пользователи

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

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

У меня есть идея для метода выявления требований, но она никак не "прекрасно видима".
Короче, сплошной постмодернизм. Значит, владелец системы, который сформировал концепцию системы, которой созданная система соответствует, целостным видением её не обладает?
Я бы даже сказал так, что под определённым углом всё есть требования, как всё есть игра и т.д.

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

Модератор: подкорректировал отображение цитат

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

Обеспечивающих что?

Среди обеспечивающих подсистем обычно выделяют информационное, техническое, математическое, программное, организационное и правовое обеспечение

А какая подсистема обеспечивает функциональность? Можешь дать ссылку, откуда ты взял, что обеспечение - это подсистема? Как эти подсистемы взаимосвязаны, например правовое обеспечение и лингвистическое?

Читай основы информационных систем.

А такие есть? Дай пожалуйста ссылки.

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

А я о чём? Нужна методика определения того, какие обеспечения нужны, а какие нет.

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

Кстати, ГОСТ, описывающий виды обеспечения, существует для АС, а не для ИС. Тебя не смущает термин "информационное обеспечение информационной системы"?

Что значит инфраструктурная? Корпоротивная сеть? Но разве там нет пользователей, админ персонала? ресурсов хранения? аппаратных и программных средств?

Например, интеграционная подсистема, построенная на основе BizTalk. Её пользователями являются другие системы, а не люди.

есть понятие ручная информационная система
автоматизированная ИС
автоматическая ИС

Нужна ли пользовательская документация? Весь вопрос в том кто пользуется. Ясно что если система делается для реализации функций людей - нужна однозначно (справка или документация не важно)
Если система полностью автоматическая - нужна документация ориентированная на обслуживающий персонал - читай теже пользователи

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

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

В том-то и дело, что требования должны не из опыта "вытекать", а из необходимости обеспечения достижения комплекса целей. Причём желательно максимально логичным и наглядным способом.

Обеспечивающих что?

Общее устройство информационной системы, я полагаю.

А какая подсистема обеспечивает функциональность? Можешь дать ссылку, откуда ты взял, что обеспечение - это подсистема? Как эти подсистемы взаимосвязаны, например правовое обеспечение и лингвистическое?

Ссылки дать не могу, книги к сожалению не распространненые, возможно спорные. Прицеплю выдержку из этих книги скомпилированных у меня в лекциях.

А такие есть? Дай пожалуйста ссылки.

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

А я о чём? Нужна методика определения того, какие обеспечения нужны, а какие нет.

Так она и есть, это стандарты, ГОСТ, приказы, положения, требования наконец. Они и определяют потребности в том или ином обеспечении.

Кстати, ГОСТ, описывающий виды обеспечения, существует для АС, а не для ИС. Тебя не смущает термин "информационное обеспечение информационной системы"?

О кей а что такое автоматизированная система? Или информационная система? Все ГОСТ еще советские. Понятия те же. В Книгах прошлого века, вообще не выделяют явно понятия ИС (как мы его понимаем нынче), а определяют его как например информационная обеспечивающая подсистема АСУ, т.е. подсистема обеспечивающая АСУ информацией...

Например, интеграционная подсистема, построенная на основе BizTalk. Её пользователями являются другие системы, а не люди.

Ну и что, ты хочешь меня убедить, что данная система существует независимо от воли и желания людей, сама по себе, самодостаточна и гомеостатична? Она сама справляется с энтропией, сама себя подпитывает, думает о продолжении рода и т.д.?

"Значит нужна". Понимаешь, я хочу, чтобы были не ad-hoc рассуждения, а методика определения того, какие работы и артефакты должны быть сделаны в зависимости от того, какая система создаётся (а это может быть бизнес, приложение, АС, ИС и т.д.)

Денис, во-первых, может не будем коверкать русский? что за ad-hoc? Мне этот термин не понятен, ты меня типа послал? Так понимать? Или таким образом, высказался об моем уме? Так я и сам знаю, что далеко не вундеркинд.
А насчет методики: так сотни трудов написаны, приэтом мне так кажется, ты свою можешь выдвинуть и представить общественности. Поддержат - значит и твоя методика будет пользоваться уважением. Понимаешь все это очень и очень субъективно. Ты же сам отругал примерно Рамбо с Блахой, но они как раз и есть родители этого самого RUP, которого ты в их книге не увидел.

Сколько таких вопросов про нужность ты задашь сам себе при определении требований и работ?

К сожалению, нет у меня практических проектов, только учебные. А ты понимаешь, что все это игра. Но думаю все определяется как не странно суммой, которой тебе согласятся заплатить. Если тебе предложать 30000 баксов и ты в соглашении не утвердишь вопросы связанные с документацией, а заказчик подпишет, то понятно, что это будет другая работа.
Но описание работы системы - это строго необходимый артефакт, и почему это вызывает у тебя потребность обоснованности мне не очень понятно.
Ты изготовил прибор, ты же обязан написать как им пользоваться? Как иначе? Ты хочешь получать за свой прибор деньги? Выбиваешь авторсоке свидетельство, патент, другой документ, доказывающий что ты его сделал. Твой прибор безопасен для окружающих? А что значит безопасен, значит сотвествует некоторым санитарным нормам, нормам безопасности и т.п. Чем они определяются: научными обоснованиями, социальными нормами, политическими требованиями и т.д. Т.е. одно действительно определяется естественно-научными законами, а другое неестесвенно научными:-)) часто субъективными, такими как мораль...

В том-то и дело, что требования должны не из опыта "вытекать", а из необходимости обеспечения достижения комплекса целей. Причём желательно максимально логичным и наглядным способом.

держись контекста, у меня вообще там сказано как третье. А из опыта вот почему. Да я хочу что-то получить, но мои требования зачастую неопределены, противоречивы и т.д.
Разве ты не слышал такое, ну ты сам подумай. Вот тебе пожалуйста и опыт. Требования же не тобою лично выдвигаются, а заказчиком, разве его опыт не важен?
А насчет максимально логичном - это идеал. Данная наука пока слишком субъективна, задачи слабоформализованны, их мы строго решать пока не умеем...

Кстати, в теме роль бизнес-аналитика, я предложил местным бизнес-аналитикам рассказать о своей роли бизнес-аналитика, задачах которые вы конкретно делаете

Да еще могу посоветовать: Когаловский М.Р. Перспективные технологии ИС. М.: ДМК Пресс; М.: Компания АйТи, 2003 г. (Лекции МГУ)
Там правда про обеспечение не говорится, но говорится о том, а что же есть такое ИС

Во-первых, не отклоняемся от темы дискуссии - Требования, а Вы пошли уже спорить про ИС, АС, подсистемы и обеспечение. Это сейчас не так важно.

Мне еще кажется, что, Денис, ты путаешь требования к продукту и требования к составу работ. Требования к составу работ - это документация пользователя в НУЖНОМ формате, это документы по требованиям и их качеству и т.д.
Про взаимосвязь наиболее полно ответил Юра, и главная идея в том, что нельзя все уж так систематизировать. Сначала этим болел Эд, сейчас ты
Да есть цели, да есть бизнес требования, да есть требования к ПО. Они естесвенно трасируются, но т.к. порой очень важно выяснить ключевые вещи (детали), то все равно что-то будет всплывать как-бы из неоткуда. Тем более не функциональные требования, как ты их протассируешь к БТ?