Требования в области проблем и в области решения

из "Разработка и управление требованиями "

Целью системного проектирования является выработка эффективных решений определенных проблем. Как обсуждалось выше, этот поэтапный процесс является жизненно важным в обеспечении для бизнеса возможности выхода на рынок с правильным продуктом в приемлемые сроки и с допустимыми затратами. [c.20]
В начале процесса разработки самым важным являются требования к разрабатываемому продукту. Как с точки зрения руководства, так и точки зрения системных инженеров необходимо сделать четкое разделение между областью проблем и областью решения . Необходимо, чтобы к проблемной области были отнесены формулировка проблем, модели использования (прецеденты), пользовательские требования. [c.20]
Начиная с системных требований, все должно быть, отнесено к области решения. [c.21]
В таблице 1.4. показано идеальное разделение между проблемной областью и областью решения, а также сформулированы цели, которым должны удовлетворять требования трех верхних уровней. [c.21]
Системные требования Область решения Аналитик Абстрактно определяет - как система будет удовлетворять пользовательским требованиям. Следует избегать точных описаний реализации предлагаемых решений. [c.21]
Системные спецификации (архитектура системы) Область решения Архитектор Определяет - как конкретная архитектура системы будет удовлетворять системным требованиям. [c.21]
Здесь необходимо обратить внимание на принцип абстракции, которому нужно следовать, описывая проблемную область. [c.21]
Первоначальная формулировка возможностей системы должна содержать только то, что необходимо для определения (описания) проблемы, и не должна содержать ничего, что определяет конкретные решения. Это дает свободу системным инженерам для выполнения своей работы, которая как раз и заключается в нахождении наилучшего решения проблемы, что выполняется только при условии, что инженер не связан заранее никакими определенными идеями. [c.21]
Моделирование, помогая переходить от уровня к уровню, тоже может привносить элементы конкретных решений, уже даже на верхнем уровне. Для того чтобы избежать уклона в плоскость решения, на ранних этапах лучше применять моделирование только для описания включающей системы (подсистемы). Например, при разработке системы связи для судна моделирование, на первых порах, должно быть сосредоточено на описании корабля, а не самих средств связи. Это приводит к формулировке именно проблем в контексте включающей системы, а не описания их возможного решения. [c.21]
Тот же принцип применим и к системным инженерам (аналитикам), которые должны оставлять свободу архитекторам для выполнения их работы, которая заключается в нахождении лучшего системного решения для абстрактных системных требований. Элементы реализации, создаваемые на этапе функционального моделирования на верхнем уровне требований, не должны содержать деталей, которые будут и должны определяться на последующих стадиях. [c.21]
Очень часто заинтересованные стороны выражают проблему уже в терминах предопределенного решения. Это привносит дополнительную работу аналитику, поскольку теперь ему необходимо анализировать является ли предлагаемое (а фактически, -требуемое) решение наилучшим или это всего лишь лишнее ограничение (недоразумение). Например, заказчики, формулируя проблемы, начинают с того, что им необходимы светофоры. Исполнитель же, в свою очередь, задавая вопросы, лишь потом выясняет истинные цели - необходимо увеличение пропускной способности транспортного потока при минимизации риска для водителей и пешеходов, что и является формулировкой проблемы независимой от ее конкретной реализации. После получения такой формулировки проблемы становятся понятными причины выбора последующих решений, которые, возможно, будут подтверждены при помощи моделирования, которое, в свою очередь, будет являться основанием для более детальных спецификаций абстрактного описания решения. [c.22]
В случае покупки готовой системы необходимо принять решение, что использовать в качестве критерия оценки систем - область проблем (пользовательские требования) или область решения (системные требования). Зачастую решение известно заранее и тогда имеет смысл покупать систему, удовлетворяющую системным требованиям. Однако формулировка проблем в чистом виде дает большие преимущества, даже если основой для выбора приобретаемой системы являются системные требования. [c.22]
По этим причинам в книге разграничиваются пользовательские и системные требования с точки зрения того, как эти разные требования собираются, как они формулируются, как они моделируются. [c.23]

Вернуться к основной статье