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

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

Целью системного проектирования является выработка эффективных решений определенных проблем. Как обсуждалось выше, этот поэтапный процесс является жизненно важным в обеспечении для бизнеса возможности выхода на рынок с «правильным» продуктом в приемлемые сроки и с допустимыми затратами.
В начале процесса разработки самым важным являются требования к разрабатываемому продукту. Как с точки зрения руководства, так и точки зрения системных инженеров необходимо сделать четкое разделение между «областью проблем» и «областью решения». Необходимо, чтобы к проблемной области были отнесены: формулировка проблем, модели использования (прецеденты), пользовательские требования.
Начиная с системных требований, все должно быть, отнесено к области решения.
В таблице 1.4. показано «идеальное» разделение между проблемной областью и областью решения, а также сформулированы цели, которым должны удовлетворять требования трех верхних уровней.
Таблица 1.4 Область проблем и область решения
Уровень.
требований
Область
Точка зрения
Цель
Пользовательские.
требования
Область проблем
Пользователь.
(представитель.
заинтересованной.
стороны)
Определяет - что пользователь желает достичь с помощью создаваемой системы. Следует избегать формулировки конкретных решений.
Системные.
требования
Область решения
Аналитик
Абстрактно определяет - как система будет удовлетворять пользовательским требованиям. Следует избегать точных описаний реализации предлагаемых решений.
Системные.
спецификации.
(архитектура.
системы)
Область решения
Архитектор
Определяет - как конкретная архитектура системы будет удовлетворять системным требованиям.
Здесь необходимо обратить внимание на принцип абстракции, которому нужно следовать, описывая проблемную область.
Первоначальная формулировка возможностей системы должна содержать только то, что необходимо для определения (описания) проблемы, и не должна содержать ничего, что определяет конкретные решения. Это дает свободу системным инженерам для выполнения своей работы, которая как раз и заключается в нахождении наилучшего решения проблемы, что выполняется только при условии, что инженер не связан заранее никакими определенными идеями.
Моделирование, помогая переходить от уровня к уровню, тоже может привносить элементы конкретных решений, уже даже на верхнем уровне. Для того чтобы избежать уклона в плоскость решения, на ранних этапах лучше применять моделирование только для описания включающей системы (подсистемы). Например, при разработке системы связи для судна моделирование, на первых порах, должно быть сосредоточено на описании корабля, а не самих средств связи. Это приводит к формулировке именно проблем в контексте включающей системы, а не описания их возможного решения.
Тот же принцип применим и к системным инженерам (аналитикам), которые должны оставлять свободу архитекторам для выполнения их работы, которая заключается в нахождении лучшего системного решения для абстрактных системных требований. Элементы реализации, создаваемые на этапе функционального моделирования на верхнем уровне требований, не должны содержать деталей, которые будут и должны определяться на последующих стадиях.
Например, в системе управления автомобильным движением:.
• Заинтересованные стороны (stakeholders) могут выразить проблему следующим образом: максимизация транспортного потока, при минимизации риска возникновения дорожных происшествий на пересечении дорог при минимизации стоимости обслуживания решения.
• Системные инженеры (system engineers) могут предложить различные решения этой проблемы: разного рода светофоры; организация кругового движения на определенных участках дороги; а может быть и мост в качестве наиболее подходящего решения в рамках существующих ограничений, стоимости разработки и последующего обслуживания.
• Архитекторы (designers) будут разрабатывать проект моста с учетом существующих физических ограничений, налагаемых окружающей средой.
Очень часто заинтересованные стороны выражают проблему уже в терминах предопределенного решения. Это привносит дополнительную работу аналитику, поскольку теперь ему необходимо анализировать является ли предлагаемое (а фактически, требуемое) решение наилучшим или это всего лишь лишнее ограничение (недоразумение). Например, заказчики, формулируя проблемы, начинают с того, что им необходимы светофоры. Исполнитель же, в свою очередь, задавая вопросы, лишь потом выясняет истинные цели - необходимо увеличение пропускной способности транспортного потока при минимизации риска для водителей и пешеходов, что и является формулировкой проблемы независимой от ее конкретной реализации. После получения такой формулировки проблемы становятся понятными причины выбора последующих решений, которые, возможно, будут подтверждены при помощи моделирования, которое, в свою очередь, будет являться основанием для более детальных спецификаций абстрактного описания решения.
В случае покупки готовой системы необходимо принять решение, что использовать в качестве критерия оценки систем - область проблем (пользовательские требования) или область решения (системные требования). Зачастую решение известно заранее и тогда имеет смысл покупать систему, удовлетворяющую системным требованиям. Однако формулировка проблем в чистом виде дает большие преимущества, даже если основой для выбора приобретаемой системы являются системные требования.
Отсутствие четкого разделения между проблемами и решениями, может привести к следующим негативным последствиям:.
• недостаточное понимание существующих проблем;.
• невозможность определить границы (масштаб) системы и понять какой функционал должен в нее входить, а какой нет;.
• доминирование разработчиков и исполнителей в дискуссиях о системе, поскольку единственное описание, существующее для системы, описывает ее в терминах реализации, а не в формулировках проблем;.
• невозможность нахождения наилучшего решения из-за ограничений свободы в выборе решения.
По этим причинам в книге разграничиваются пользовательские и системные требования с точки зрения того, как эти разные требования собираются, как они формулируются, как они моделируются.
Как читать эту книгу.
Книга посвящена процессу разработки требований и призвана помочь системным инженерам, работающим в любой области, и, в частности, инженерам по разработке программного обеспечения, лучше разрабатывать требования.
В Главе 1 обсуждалась важность требований и раскрывалась роль и нюансы процесса разработки требований в процессе создания системы.
В связи с большим количеством информативных связей между главами порядок следования материала был выбран таким, чтобы минимизировать количество ссылок на другие главы. Наилучшим способом чтения этой книги является последовательное прочтение всех глав. Однако для того, чтобы сделать эту книгу более полезной и сократить время на поиски нужной информации для тех читателей, которые заглянули сюда, имея конкретную цель, мы приводим краткое описание последующих глав.
Глава 2 - «Общий процесс разработки требований» - описывает общий подход к разработке требований, применяющийся на всех этапах разработки системы. Хотя этот подход и поможет читателям получить хорошее понимание сущности процесса разработки требований, он, тем не менее, остается достаточно абстрактным. В главах 5 и 6 общий процесс описан более детально, с помощью примеров, применительно к пользовательским и системным требованиям.
Глава 3 - «Системное моделирование для разработки требований» - рассказывает о различных методах системного моделирования и их широком использовании. Эта глава также служит для подготовки читателя к материалам глав 5 и 6, где различные методы моделирования на уровне пользовательских и системных требований рассмотрены на примерах.
Глава 4 - «Написание и анализ требований» - посвящена структуризации документов, связанных с требованиями, и формулировке изложения самих требований. В этой главе рассмотрен подход к «языку», с помощью которого формулируются различные типы требований.
Глава 5 - «Разработка требований в области проблем» - описывает основной процесс анализа проблемной области и сбора пользовательских требований.
Глава 6 - «Разработка требований в области решения» - описывает основной процесс получения требований в области решения: от системных требований до требований к подсистемам и компонентам.
Глава 7 - «Расширенные связи и их анализ» - знакомит с дополнительными методами анализа связей, которые направлены на улучшение процесса работы с требованиями. В главе также обсуждаются метрики, которые можно получить с помощью анализа связей.
Глава 8 - «Аспекты управления разработкой требований» - посвящена вопросам управления проектами в организациях различных типов, в контексте управления требованиями.
На рис. 1.12 изображена структура глав книги и связи между ними.
Рис. 1.12 Структура книги.
В заключение, Глава 9 - «DOORS: Средство управления требованиями» - описывает DOORS, как конкретный пример программного средства поддержки разработки и управления требованиями.
Процесс, описанный в книге, проиллюстрирован на конкретных примерах, так же как и возможности DOORS.