Разработка системных моделей для получения системных требований

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

На рис. 6.3 проиллюстрировано взаимодействие перечисленных функциональностей между собой и с элементами внешнего окружения. [c.133]
На практике приходится использовать несколько различных типов моделей для описания всех требуемых аспектов функциональности системы. А поскольку каждая модель содержит информацию определенного типа, а каждая технология моделирования использует свою собственную семантику, то информация в одной модели может быть отделена от информации в другой модели. Но с другой стороны, одна и та же информация может появляться в нескольких моделях. В последнем случае очень важно быть уверенным, что если информации меняется в одной из моделей, то это изменение отражается и во всех остальных моделях, в которых эта информация встречается. В идеальном варианте это может происходить автоматически с помощью сопряжения (интеграции) моделирующих инструментов. Если же это по каким-то причинам не может быть организовано, то необходимо проявлять исключительную педантичность и аккуратность, чтобы удостовериться в том, что любое изменение информации в одном месте идентично отражается в других связанных моделях. Диаграмма Венна (рис. 6.4) иллюстрирует, что некоторые модели могут быть представлены в виде отдельных островков информации, в то время как другие модели могут иметь общую информацию, возможно представленную в разных формах. Диаграмма также демонстрирует тот факт, что часть информации о системе не отражена ни в одной из моделей. [c.134]
Внутренняя функциональность является исходным элементом для разработки системных требований, потому что определяет то, что система должна делать. Для того чтобы получить системные требования, необходимо разработать функциональную структуру или модель системы, которые будут являться основой для дальнейшей работы. Такая модель должна предполагать возможности декомпозиции системы и позволять выделение модулей или высокоуровневых компонентов, например, подсистем. Конечно, термины модуль или подсистема провоцируют проектировщиков и разработчиков мыслить больше в категориях реализации, нежели чем в направлении конкретизации и спецификации, поэтому употребление этих терминов является не очень хорошей практикой (особенно в области разработки программного обеспечения). В большинстве систем, сползание в область физических моделей не рассматривается, как некая чрезвычайная ситуация, поскольку сама по себе область применения систем может иметь физическую природу. [c.134]
Как альтернатива этой терминологии, стимулирующей появление преждевременных решений, существует тенденция (можно даже сказать мода ) употреблять термин объект , говоря о декомпозиции. Особенно это популярно в области разработки ПО, поскольку объект, в этом случае, может описывать реальный предмет из области проблем. Такой подход помогает предотвратить попытки мышления проектировщиков в терминах решений. В соответствии с этим подходом функциональность системы может быть представлена как совокупность методов и операций над объектами, а также в виде описания взаимодействия объектов между собой. [c.135]
Использование такого объектно-ориентированного подхода позволяет также упростить задачу установления связей от системных требований к пользовательским, поскольку зачастую некоторые объекты проявляют тенденцию просматриваться , как в области проблем, так и в области решений. [c.135]
Помимо описания того, что система должна делать, от системной модели требуется также обозначить подразумеваемое поведение системы. Эта информация может быть представлена разными способами. Достаточно вспомнить, что модели в этой области обычно отражают тот факт, как несколько ролей (актеров) могут одновременно взаимодействовать друг с другом. [c.135]
Для любой системы необходимо также определить то, какую именно информацию и как необходимо обрабатывать и хранить. [c.135]
В некоторых системах, например, в системах учета страховых компаний, необходимо, чтобы информация собиралась и хранилась в течение многих лет. В других системах, например, в системе обработки данных, полученных с помощью радара, для обеспечения управления воздушным движением, часть информации должна храниться достаточно долго, например, планы полетов, а другая информация, например, текущее положение самолета, не актуальна уже в следующую секунду, поскольку самолет переместился. [c.135]
Очень важно также знать и объем информации, который будет обрабатываться системой. Этот показатель может оказать существенное влияние на архитектуру системы. [c.136]
Здесь необходимо определить характер будущего взаимодействия системы с любыми другими внешними системами. [c.136]
Это взаимодействие может быть связано и с передачей информации, и с перемещением вещественного материала между системами. Эта передача может носить только однонаправленный характер или же функционировать в обоих направлениях причем при наличии или отсутствии ограничений, налагаемых на такую передачу. В некоторых случаях необходимо даже организовать временное хранение передаваемых принимаемых объемов информации или материалов (например, буфер, или склад), если они не могут быть обработаны сразу. Могут существовать и определенные требования относительно времени реакции системы на внешние воздействия со стороны других систем. [c.136]
Обычно выполнение рекомендаций документов, описывающий интерфейс, контролируются той организацией, которая отвечает за разработку системы, предполагающей взаимодействие с другими системами. Однако в том случае, когда разрабатывается совершенно новая система, найти организацию, которая взяла бы на себя ответственность за контроль такого рода, является большой проблемой. Очень часто бывает так, что для ранее разработанных систем документации, описывающей интерфейс нет или она очень плохая. Более того, возможно, что разработчик системы уже и не поддерживает ее или передал ее на обслуживание своему клиенту или другой организации. Это порождает свои трудности при определении интерфейсов. [c.136]
Необходимо уделять большое внимание тому, чтобы у вас была полная уверенность, что все обязательства по соблюдению интерфейсов отражены в производных требованиях на всех соответствующих уровнях, и что четко, насколько это возможно, определена организация, которая будет осуществлять контроль за соблюдением интерфейса. [c.137]
Основным вопросом в области общения системы с человеком является определение того, какое именно взаимодействие им может потребоваться. Здесь не следует забывать про условия, в которых человек взаимодействует с системой, поскольку они оказывают влияние на то, как именно человек будет работать с системой. [c.137]
Например, человек, работающий в кабинетных условиях, находится в тепле и может работать с данной системой без перчаток а вот другие люди вынуждены работать с этой системой в экстремальных условиях, скажем, при низких температурах или других вредных условиях, поэтому им может потребоваться защитная одежда. Тогда конструкция, например, дисплея и клавиатуры должна учитывать и эти факторы. [c.137]
Внешняя среда, в которой должна функционировать система, существенным образом влияет на требования по безопасности и защите системы. [c.137]

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