Интересно отметить разницу между ограничениями на уровне пользовательских и системных требований. Ограничения на уровне пользовательских требований скорее относятся к результату, который должен быть получен. Системные же ограничения носят в большей степени профессиональный (более технический) характер и затрагивают скорее качество конечного продукта. Все пользовательские ограничения должны быть отражены в системных ограничениях. Иногда для этого необходимо изменить формулировку [c.124]
Здесь уместно также привести пример из телекоммуникационной индустрии, где применяемые стандарты зачастую предписывают архитектуру решения. Опять же встает чисто теоретический вопрос, являются ли требования, предъявляемые к системе, на самом деле пользовательскими или они, по сути своей, являются уже системными требованиями. Какой бы ответ ни был бы получен, это вполне обычная практика - транслировать входящие требования на уровень производных (требований к подсистемам). Получается это благодаря тому, что стандарты, сами по себе, достаточно детализированы. [c.153]
Характер полученных требований будет зависеть от типа клиентской организации, которая прислала приглашение к участию в тендере. Если клиентская организация является конечным потребителем, заказывающим систему для собственных нужд, то, вероятнее всего, полученные требования будут являться пользовательскими. В другом случае клиентская организация может быть сама поставщиком (разработчиком), желающим найти субподрядчика для выполнения части работ, например, для разработки подсистем и или компонентов системы. Тогда, вероятнее всего, организация-поставщик получит на входе системные требования и определенные ограничения относительно их реализации. Для того, чтобы избежать путаницы и сделать дальнейшее изложение более понятным и наглядным, мы будем называть требования, полученные от клиентской организации, входящими, независимо от их реального характера. [c.190]
На верхнем уровне очень важно знание предметной области, которая соответствует области проблем. На системном уровне важно получить общее представление о системе, чтобы избежать слишком узкого (чересчур детализированного) понимания пользовательских требований. На этом уровне неизбежно появляется уклон в сторону определенного решения. На этой стадии целесообразно и необходимо привлекать людей (организации), которые до этого имели опыт успешной реализации аналогичных систем. Аналогичным образом, разработчики подсистем должны привносить свои знания и опыт, ранее полученные при разработке похожих подсистем. [c.28]
Смотреть страницы где упоминается термин Получение системных требований из пользовательских
: [c.48]Смотреть главы в:
Разработка и управление требованиями -> Получение системных требований из пользовательских