mcureenab
Ещё один аргумент в пользу разделения требований и модели.
Положим клиент заказал нам поставку некоторой системы и предоставил ТЗ, которое разработала для него третья фирма. Мы смотрим на требования и понимаем, что мы когда-то для кого-то сделали Мегасистему, которая удовлетворяет почти всем требованиям и предоставляет ещё кучу ненужной клиенту функциональности.
Естественно, мы не будем кастрировать модель нашей системы, а только дополним её новыми частями и требованиями. В итоге имеем модель Мегасистемы с множеством требований, которое включает подмножеством требования из ТЗ заказчика.
В общем случае на здоровье. Но в ТЗ или вы пишете, что разработка новой системы будет произведена пудем модификации имеющейся. Или не пишете, тогда ДЛЯ ЗАКАЗЧИКА вы должны представить полную картину, что у него будет в результате. А то при сдаче системы могут начаться недоразумения.

mcureenabЗаказчику побарабану есть у нас Мегасистема или мы создаём её с 0. У заказчика нет никакой системы, ему не нужно ничего дорабатывать. Он заключает договор на поставку системы, исполнитель сам решает использовать Мегасистему в качестве прототипа, или создавать новую систему.
Если система удовлетворяет требованиям заказчика, то что ещё нужно? Зачем ему знать о ненужных и, возможно, непонятных ему функциях?
Вот в ТЗ должны быть полные и непротиворечивые ТРЕБОВАНИЯ ЗАКАЗЧИКА и именно по тому, что ему побарабану, что там есть еще, избыточных требований там быть не должно.
Про побарабану можно долго спорить, но не в этой ветке.

byur
Нет, ТЗ не ОПИСЫВАЕТ разрабатываемую систему, а предъявляет требования к ней. Описывать систему будет ДИЗАЙН -- например на UML диаграммах.

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

byur
Понятие viewpoint и view в большей степени отождествляется с архитектурным описанием системы (см. например "IEEE - 1471 Recommended practice for software Architecture description", и http://www.almportal.ru/public/so/book/3-2-software_engineering_design.pdf)

Давайте определимся один раз: не надо путать страты, как системноаналитическое понятие и viewpoint, как его специализацию в конкретном наборе методологий. Дело в том, что системы исследовали и разрабатывали тогда, когда в России не были известны (и не были еще написаны) документы, на которые Вы ссылаетесь. Чтобы нам понять, что в разных методологиях является общим, а что различным мне приходится прибегать к идентификации понятий на языке системного анализа, в противном случае в этом топике будет священная война методологий.
В свете вышенаписанного повторяю еще раз: система имеет множество слоев, их так же называют стратами. При описании системы мы сами выбираем те, которые для нас важны. Ни одна система не может быть описана с абсолютной точностью, то есть мы сознательно огранирчиваем глубину стратификации. ТЗ и пакет архитектурных документов суть модели, отражающие разные слои (страты, а не viewpoints) системы.

byur
Имелось ввиду, что при таком подходе есть риск прийти к такому выводу о технике юзкейсов, что лично наблюдал :-).

Вы хотите поговорить об этом? ;)

byur
Мне не приходилось встречать такую формулировку требований (sys должна поддерживать след. варианты использования). Боюсь. что это не лучший способ. В частности, потому что однозначность требований будет сильно зависить от качества написания юзкейсов и их подробности.

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

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