В виду того что на данный момент не все теории и практики охвачены моим познанием хотел бы структурировать имеющиеся методологии, теории, стандарты и иже с ними.
Правильно ли я понимаю, что:
Следует разделять «сущности» (не исключено что я их перемешал)
1.   Нотация  (Методология?) сбора/анализа/моделирования (или это три разных подразделения)
SADT, UseCase, UML, есть еще популярные ?
2.   Методологию разработки ПО
RUP, Iconix, Agile, XP, и т.п.
3.   Стандарты представление документации
ГОСТ, IEEE, есть еще популярные ?

В итоге
1. мы используем методологию моделирования для сбора/моделирования/представления/хранения данных
2. с помощью методологии разработки мы управляем процессом создания продукта
3. с помощью стандарта представления документации мы передаем заказчику информацию о данных и о продукте

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

Как следствие:
1.   Понятие о «Спецификации требований» у каждой компании может быть свое, как и состав документов, но если это ГОС проект то смотрим соответствующий 34-ый стандарт и никаких вам спецификаций.
2.   По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем. Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?

Kavalsky, за несколько лет я пришёл к тому, что слово методология — вредное.
В большинстве случаев его спокойно можно заменить на «правила работы».

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

RUP предполагает использование UML для моделирования и определённые виды документов (Vision, Use Case Model, Supplementary Specification), которые являются стандартами в его рамках.

Если перечитать Коберна с его «каждому проекту — своя методология», станет понятно, что набор правил не сводится к вектору из (нотация моделирования, стандарт документирования, процессный фреймворк).

2.   По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем.
Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ?
Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?

хороший вопрос, про который есть отдельные темы.

Под ФТ понимаются функциональные требования 3-х уровней — бизнесового, пользовательского и технического.
Отсюда и всё месиво.

Способ применения (use case) — это структура, содержащая 1 пользовательское ФТ и N технических.

В виду того что на данный момент не все теории и практики охвачены моим познанием хотел бы структурировать имеющиеся методологии, теории, стандарты и иже с ними.
Правильно ли я понимаю, что:
Следует разделять «сущности» (не исключено что я их перемешал)
1.   Нотация  (Методология?) сбора/анализа/моделирования (или это три разных подразделения)
SADT, UseCase, UML, есть еще популярные ?
2.   Методологию разработки ПО
RUP, Iconix, Agile, XP, и т.п.
3.   Стандарты представление документации
ГОСТ, IEEE, есть еще популярные ?

Посмотрите тут http://yurybuluy.blogspot.ru/2013/03/blog-post.html на эту тему сделал некоторое рассуждение. Может поможет структурировать мысли.

Как следствие:
1.   Понятие о «Спецификации требований» у каждой компании может быть свое, как и состав документов, но если это ГОС проект то смотрим соответствующий 34-ый стандарт и никаких вам спецификаций.
2.   По большому счету ВИ есть ФТ и наоборот. Т.е. одно порождает другое и уже от нас и проекта зависит от чего мы пляшем. Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?

Более корректно (если мы принимаем классификацию Вигерса) говорить, что ВИ - это формат/нотация описания пользовательских требований. И если говорить про то, что под ФТ Вигерс понимает два разных уровня классификации (но с одинаковым названием), т.е. у него все требования делятся на функциональные и нефункциональные требования. Функциональные в свою очередь делятся на бизнес-, пользовательские и (да, да) функциональные. Исходя из этого, ВИ <> ФТ. Но входят в состав ФТ как классификационной единицы :-).

О разнице м/у ВИ и функциями можно почитать тут http://yurybuluy.blogspot.ru/2010/12/use-cases.html.

хороший вопрос, про который есть отдельные темы.

Под ФТ понимаются функциональные требования 3-х уровней — бизнесового, пользовательского и технического.
Отсюда и всё месиво.

Способ применения (use case) — это структура, содержащая 1 пользовательское ФТ и N технических.

Денис, поясни пож-та что понимается под "техническими" требованиями?

Денис, поясни пож-та что понимается под "техническими" требованиями?

Требования, которые не относятся напрямую к цели пользователя, а только помогают в её реализации.
Например, «Система должна показать список контактов под полем ввода адреса» как шаг сценария реализации требования «Система должна позволять Пользователю отправлять письма».

Посмотрите тут http://yurybuluy.blogspot.ru/2013/03/blog-post.html на эту тему сделал некоторое рассуждение. Может поможет структурировать мысли.

Юра, если уж ты упомянул SWEBOK, спрошу — вы будете с Орликом обновлять перевод по результатам выхода SWEBOK v3?
http://computer.centraldesktop.com/swebokv3review/

Тогда учитывая, что ВИ более подробная картина ФТ зачем описывать ФТ? Или мы описываем ФТ высокого уровня для полноты картины а в ВИ описываем глубокую декомпозицию?

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

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

Юра, если уж ты упомянул SWEBOK, спрошу — вы будете с Орликом обновлять перевод по результатам выхода SWEBOK v3?
http://computer.centraldesktop.com/swebokv3review/

Пока не обсуждали, Сергей сильно загружен работой.

Коллеги спасибо!

Юрий, я нашел еще один Ваш документ, еще не прочел, но думаю он "в тему" -
http://2006.secr.ru/upload/files/63.pdf

Что касается понятия "методология". Может будет интересно http://www.methodolog.ru/.

[Сначала несколько уточнений.]
Уравнение в заголовке подвергается сильной критике довольно давно. Например, в agile manifesto. Можно добавить слева как минимум ещё три слагаемых: навыки + знания + коллектив.
Нотация -- система обозначений -- не всегда жестко привязана к методике или методологии. Т. е. UML -- не методология моделирования. И не часть методологии RUP (многие участники OMG приложили достаточно усилий, чтобы это не было так). UML создавался как общая нотация для нескольких методов разработки.
Методология RUP содержит в себе техники моделирования. Методология разработки ПО может включать в себя методики моделирования, и чаще всего включает.

[Теперь по существу.]
Нотации дают возможность участникам проекта невербально обмениваться идеями и принятыми решениями.
Стандарты фиксируют соглашения, которых придерживаются участники проекта.
Методологии упорядочивают работу участников проекта.

Мне нравится такая штука:

Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.

Этой нотации поболее полусотни лет, но она, на мой взгляд, лучше и RUP-а, и PMBoK, и прочих. Нестареющая классика.

А это нотация?