Анализ предметной области и требования к ПО. Усачев А.А._XP. Лекция 4 План лекции Варианты использования, действующие лица, диаграммы вариантов использования
 Скачать 1.22 Mb.
|
Анализ предметной области и требования к ПОЛекция 4План лекции:Варианты использования, действующие лица, диаграммы вариантов использования. 4 Требования к ПО . Схема Захмана. 1 Модели предметной области. Диаграммы потоков данных. 2 Диаграммы сущностей и связей. Функции и требования к ПО. 3 Требования к ПОТребования к ПО определяют, какие свойства и характеристики оно должно иметь для удовлетворения потребностей пользователей и других заинтересованных лиц.Чтобы ПО было действительно полезным, важно, чтобы оно удовлетворяло реальные потребности людей и организаций, которые часто отличаются от непосредственно выражаемых пользователями желаний.Для выявления этих потребностей, а также для выяснения смысла высказанных требований приходится проводить достаточно большую дополнительную работу, которая называется анализом предметной области или бизнес-моделированием, если речь идет о потребностях коммерческой организации.Схема ЗахманаВ основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы — зачем, кто, что, как, где и когда — и разные уровни рассмотрения. Схема ЗахманаОбозначенные 6 вопросов определяют 6 аспектов рассмотрения.Цели организации и базовые правила, по которым она работает. Персонал, подразделения и другие элементы организационной структуры, связи между ними. Сущности и данные, с которыми имеет дело организация. Выполняемые организацией и различными ее подразделениями функции и операции над данными. Географическое распределение элементов организации и связи между географически разделенными ее частями. Временные характеристики и ограничения на деятельность организации, значимые для ее деятельности события. Схема деятельности компании, управляющей магазином, в нотации Йордана-ДеМарко.Детализация процесса "Управление персоналом"Модель сущностей и связейВыделение и анализ требованийПотребности определяются на основе наиболее актуальных проблем и задач, которые пользователи и заказчики видят перед собой.Формулировка потребностей может быть разбита на следующие этапы:Выделить одну-две-три основных проблемы. Определить причины возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущие появление остальных. Определить ограничения на возможные решения. Формулировка потребностей не должна накладывать лишних ограничений на возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что именно является проблемой, а не предлагать сразу возможные решения. Соотношение между проблемами, потребностями, функциями и требованиямиIEEE 830-1998 Recommended Practice for Software Requirements Specifications. Описывает структуру документов для фиксации требований к ПО. Кроме того, он определяет характеристики, которыми должен обладать правильно составленный набор требований:Корректность или адекватность (соответствие реальным потребностям).Недвусмысленность (однозначность понимания). Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, в которых придется работать системе). Непротиворечивость (согласованность между различными элементами). Упорядоченность по важности и стабильности. Проверяемость (выполнение каждого требования нужно уметь проверять некоторым достаточно эффективным способом — непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам). Модифицируемость (оформление в удобных для внесения изменений структуре и стилях). Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами, модулями и операциями, ответственными за его выполнение, и с тестами, проверяющими его выполнение). 2. IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications(руководство по разработке спецификаций требований к системам).Описывает правила построения требований для программно-аппаратных систем в целом. Он выделяет следующие необходимые свойства набора требований:Однократное упоминание отдельных требований. Отсутствие пересечений между требованиями. Явное указание связей между требованиями. Полнота. Непротиворечивость. Определение ограничений, области действия и контекста для каждого требования. Модифицируемость. Конфигурируемость, удобство поддержки. Подходящий для определения системы уровень абстракции. Варианты использованияВариантом использования (use case) называют некоторый сценарий действий системы, который обеспечивает ощутимый и значимый для ее пользователей результат. На практике в виде одного варианта использования оформляется сценарий действий системы, который будет, скорее всего, неоднократно возникать во время ее работы и имеет достаточно четко определенные условия начала выполнения и завершения. Действующие лица также могут быть связаны друг с другом с помощью связей обобщения (generalization).Набросок диаграммы вариантов использования для Интернет-магазина Доработанная диаграмма вариантов использования для Интернет-магазина Имя, ясно говорящее о назначении варианта использования. Описание. Несколько предложений, описывающих этот вариант использования. Частота. Насколько часто данный вариант использования возникает. Предусловия. Все условия запуска варианта использования. Постусловия. Все условия, которые должны быть выполнены после успешного выполнения варианта использования. Основной сценарий работы, который используется в большинстве случаев. Альтернативные сценарии, возникающие иногда. Для каждого альтернативного сценария указываются условия его запуска. (Необязательно) Задействованные действующие лица. (Необязательно) Расширяемые варианты использования. (Необязательно) Включаемые варианты использования. (Необязательно) Статус: "в разработке", "готов к проверке", "в процессе проверки", "подтвержден", "отвергнут". (Необязательно) Допущения об окружении и ходе работы системы, использованные при разработке данного варианта. В полностью готовом варианте эти допущения либо должны быть подтверждены и стать ограничениями системы, либо должны давать начало различным сценариям работы. |