Системная инженерия ЛЕКЦИЯ 5. 5 Техники извлечения требований (Elicitation Techniques). Процесс разработки требований
 Скачать 0.53 Mb.
|
|
ЛЕКЦИЯ 5 РАЗРАБОТКА ТРЕБОВАНИЙ Из рабочей учебной программы (тема 4). Анализ осуществимости требований к системе. Разработка требований. Методика формирования требований, основанная на сценариях. 5.1. Техники извлечения требований (Elicitation Techniques). 5.2. Процесс разработки требований. 5.3. Составляющие потока анализа требований. 5.4. Анализ осуществимости требований. 5.5. Модель процесса формирования и анализа требований. 5.6. Определение требований на основе точек зрения (метод VORD). 5.7. Методика формирования требований, основанная на сценариях. 5.8. Этнографический подход к формированию системных требований. 5.1. ТЕХНИКИ ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ (ELICITATION TECHNIQUES) Идентифицировав источники требований мы не должны “покоится на лаврах”. Даже обладая пониманием того, кто владеет необходимой информацией, мы далеко не застрахованы от проблем, связанных с получением требований, необходимых для дальнейшей работы. Осуществление своей профессиональной деятельности пользователями далеко не гарантирует, к сожалению, способность ясно, четко и однозначно сформулировать то, что они делают и что именно им необходимо для решения их задач сегодня и завтра. Во многом, поэтому, сбор требований, зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс действительно извлечения, “вытаскивания” информации, без которой невозможно переходить к дальнейшим проектным работам. Недопонимание между аналитиком и пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся второстепенными, неоднозначность или тем более некорректность интерпретации информации, полученных от пользователей – все это наиболее типичные причины “сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов. Существует множество практик и подходов, позволяющих добиться действительно стройной системы требований, отвечающих реальным потребностям и приоритетам заказчиков. Среди них можно выделить следующие:
5.2. ПРОЦЕСС РАЗРАБОТКИ ТРЕБОВАНИЙ Сложные программные средства имеют различное назначение, содержание и относятся к разным областям применения. Поэтому существует потребность в четко организованном процессе, методах формализации и управления требованиями к конкретным программным продуктам. Чаще всего проблемами, с которыми встретились не достигшие своих целей проекты программных продуктов, являются: недостаток информации от пользователя или заказчика о функциях проекта, неполные, некорректные требования, а также многочисленные изменения требований и спецификаций. Это происходит потому, что зачастую разработчики и заказчики считают, что «даже если мы не очень точно знаем, чего хотим достичь, лучше быстрее приступить к реализации проекта, так как мы и так выбились из графика и нам некогда размышлять. Мы можем уточнить требования позднее». Подобный подход приводит к хаотическим, неупорядоченным действиям при разработке ПС, когда никто не знает, что на самом деле хочет заказчик и пользователь и как в действительности функционирует созданная на данный момент система и/или программный продукт. Формализация и управление требованиями — это систематический метод выявления, организации и документирования требований к системе и/или ПС а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющими проект специалистами, в условиях меняющихся требований к системе Разработка требований — это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований:
На рис. 5.1 показаны взаимосвязи между этими этапами и документы, сопровождающие каждый этап процесса разработки системных требований.  Рис. 5.1. Процесс разработки требований 5.3. СОСТАВЛЯЮЩИЕ ПОТОКА АНАЛИЗА ТРЕБОВАНИЙ. На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе. Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей, а это, в свою очередь, поможет сэкономить бюджет и не даст расползтись рамкам проекта. Анализ требований – один из основных рабочих потоков (workflow) программной инженерии, наряду, с такими, как проектирование интерфейса пользователя, либо программирование. Для обозначения термина «анализ требований» в англоязычной литературе, как правило, используется понятие «Requirement Process». В отечественной практике, наряду с обобщающим термином «анализ требований», принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как «поток работ «требования», «работа с требованиями», «определение требований» и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK. SWEBOK предлагает выделить в Requirement Process следующие основные составляющие: Requirements Elicitation (Извлечение требований), Requirements Analysis (Анализ требований в узком смысле), Requirements Specification (Специфицирование требований), Requirements Validation (Проверка требований). В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP (Rational Unified Process) — методология разработки программного обеспечения, созданная компанией Rational Software. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как: Analyze the Problem (Анализ проблемы), Understand Stakeholder Needs (Понимание потребностей совладельцев), Define the System (Определение системы), Manage the Scope of the System (Управление контекстом системы), Refine the System Definition (Уточнение определения системы). Обобщая указанные выше декомпозиции далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ «Работа с требованиями»: Формирование видения; Выявление требований; Классификация и спецификация требований; Расширенный анализ требований (моделирование и прототипирование); Документирование требований; Проверка требований; Управление требованиями; Совершенствование процесса работы с требованиями.
5.4. АНАЛИЗ ОСУЩЕСТВИМОСТИ ТРЕБОВАНИЙ Для новых программных систем процесс разработки требований должен начинаться с анализа осуществимости. Началом такого анализа является общее описание системы и ее назначения, а результатом анализа — отчет, в котором должна быть четкая рекомендация, продолжать или нет процесс разработки требований проектируемой системы. Другими словами, анализ осуществимости должен осветить следующие вопросы. Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика? Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости? Можно ли объединить систему с другими системами, которые уже эксплуатируются? Критическим является вопрос, будет ли система соответствовать целям бизнеса. Если система не соответствует этим целям, она не представляет никакой ценности для бизнеса. В то же время многие организации разрабатывают системы, не соответствующие их целям, либо не совсем ясно понимая эти цели, либо под влиянием политических или общественных факторов. Выполнение анализа осуществимости включает сбор и анализ информации о будущей системе и написание соответствующего отчета. Сначала следует определить, какая именно информация необходима, чтобы ответить на поставленные выше вопросы. Например, эту информацию можно получить, ответив на следующие вопросы. Что произойдет с организацией, если система не будет введена в эксплуатацию? Какие текущие проблемы существуют в организации и как новая система поможет их решить? Каким образом система будет способствовать целям бизнеса? Требует ли разработка системы технологии, которая до этого не использовалась в организации? Как только будут сформулированы подобные вопросы, необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы, технологи, конечные пользователи и т.д. После обработки собранной информации готовится отчет по анализу осуществимости создания системы. В нем должны быть даны рекомендации относительно продолжения разработки системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе. 5.5. МОДЕЛЬ ПРОЦЕССА ФОРМИРОВАНИЯ И АНАЛИЗА ТРЕБОВАНИЙ. После выполнения анализа осуществимости следующим этапом процесса разработки требований является формирование (определение) и анализ требований. На этом этапе команда разработчиков ПО работает с заказчиком и конечными пользователями системы для выяснения области применения, описания системных сервисов, определения режимов работы системы и ее характеристик выполнения, аппаратных ограничений и т.д. В процесс формирования требований могут быть вовлечены люди разных профессий. В нем принимают участие конечные пользователи, которые будут работать с системой, инженеры, которые разрабатывают и эксплуатируют подобные системы, бизнес-менеджеры, специалисты по предметной области, где будет эксплуатироваться система, и даже представители профсоюзов. Процесс формирования и анализа требований достаточно сложен по ряду причин. 1. Лица, участвующие в формировании требований, часто не знают конкретно, чего они хотят от компьютерной системы, за исключением наиболее общих положений; им трудно сформулировать, что они ожидают от системы; они могут предъявлять нереальные требования, так как не подозревают, какова стоимость их реализации. Лица, участвующие в формировании требований, выражают в этих требованиях собственные точки зрения, основываясь на личном опыте работы. Лица, участвующие в формировании требований, имеют различные предпочтения и могут выражать их разными способами. Разработчики должны определить все потенциальные источники требований и выделить общие и противоречивые требования. На требования к системе могут влиять политические факторы. Они могут исходить от руководителей, которые предъявляют требования только для того, чтобы усилить свое влияние в организации. Экономическая и бизнес-обстановка, в которой происходит формирование требований, неизбежно будет меняться в ходе выполнения этого процесса. Следовательно, и важность отдельных требований может изменяться. Новые требования могут быть выдвинуты новым лицом, с которым первоначально не консультировались. Обобщенная модель процесса формирования и анализа требований показана на рис. 5.2. Каждая организация использует собственный вариант этой модели, зависящий от "местных" факторов: опыта работы коллектива разработчиков, типа разрабатываемой системы, используемых стандартов и т.д.  Рис. 5.2. Процесс формирования и анализа требований Этапы процесса анализа и формирования требований.
Как показано на рис. 5.2, процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому. Цикл начинается с анализа предметной области и заканчивается проверкой требований. Понимание требований предметной области увеличивается в каждом цикле процесса формирования требований. В данном лекционном курсе рассмотрены три подхода к формированию требований:
Не существует универсального подхода к формированию и анализу требований. Обычно для разработки требований одновременно используется несколько подходов. 5.6. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ НА ОСНОВЕ ТОЧЕК ЗРЕНИЯ (МЕТОД VORD) Любая средняя или большая система ПО обычно имеет различные типы конечных пользователей. Многие лица, участвующие в формировании требований, в своих требованиях к системе выражают собственные интересы. Например, в процессе формировании требований для системы банкоматов участвуют следующие лица.
Этот список показывает, что даже для относительно простой системы существует много различных точек зрения, которые должны быть рассмотрены. Различные точки зрения на проблему позволяют увидеть ее с разных сторон. Однако эти взгляды не являются полностью независимыми и обычно перекрывают друг друга, а потому могут служить основой общих требований. Подход с использованием различных опорных точек зрения к разработке требований признает эти различные (опорные) точки зрения и использует их в качестве основы построения и организации как процесса формирования требований, так и непосредственно самих требований. Сильная сторона анализа, ориентированного на различные опорные точки зрения, в том, что он признает множество взглядов и обеспечивает основу для обнаружения противоречий в требованиях, предложенных различными лицами. Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом. 1. Как источник информации о системных данных. В этом случае на основе опорных точек зрения строится модель создания и использования данных в системе. В процессе формирования требований отбираются все такие точки зрения, на их основе определяются данные, которые будут созданы или использованы при работе системы, и способы обработки этих данных. Методы SADT и CORE используют эту интерпретацию точек зрения. 2. Как структура представлений. В этом случае точки зрения рассматриваются как особая часть модели системы. Например, на основе различных точек зрения могут разрабатываться модели "сущность-связь", модели конечного автомата и т.д. 3. Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления. Каждая из этих интерпретаций точек зрения имеет сильные и слабые стороны. Опорные точки зрения как источники информации о системных данных и как представления имеют ценность для обнаружения противоречий в требованиях . Но использовать их в процессе структурного анализа требований затруднительно, поскольку здесь не фиксируются связи между точками зрения и типами участников формирования требований. Интерактивные системы поставляют сервисы конечным пользователям. Поэтому наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. Эти точки зрения взаимодействуют с системой, получая от нее сервисы и продуцируя данные и управляющие сигналы. Этот тип точек зрения имеет ряд преимуществ.
Данный подход полезен для создания нефункциональных требований, с которыми можно связать какой-либо сервис. Многократно повторяющиеся разные точки зрения позволяют сформировать для сервисов различные нефункциональные требования На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рис. 5.3.
Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения.  Рис. 5.3. Метод VORD Точки зрения и информация о сервисах в методе VORD собираются с помощью стандартных форм (шаблонов точек зрения и шаблонов описания сервисов). В методе VORD также используются различные графические представления, включая диаграммы иерархии точек зрения и сценарии событий. Рассмотрим использование метода VORD на первых трех шагах анализа требований для системы управления банкоматами. Банкомат имеет встроенное программное обеспечение для управления аппаратными средствами и для связи с центральной базой данных банковских счетов. Банкомат принимает запросы клиента, выдает наличные деньги, информацию о счете, изменяет данные в базе данных банка и т.д. Банкоматы одного банка могут позволить клиентам других банков использовать какую-то часть своих сервисов (обычно это снятие со счета наличных денег и запрос о текущем балансе счета). Первым шагом в формировании требований является идентификация опорных точек зрения. Во всех методах формирования требований, основанных на использовании точек зрения, начальная идентификация является наиболее трудной задачей. Один из подходов к идентификации точек зрения — метод "мозговой атаки", когда определяются потенциальные системные сервисы и организации, взаимодействующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения. Во время "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрения, системные сервисы, входные данные, нефункциональные требования, управляющие события и исключительные ситуации. Источниками информации, которые можно использовать в создании этого начального образа системы, могут служить документы, описывающие назначение системы, знания инженеров-программистов из предыдущих проектов или опыт клиентов банка. Может быть проведен опрос менеджеров банка, обслуживающего персонала, консультантов, инженеров и клиентов. Следующей стадией процесса формирования требований будет идентификация опорных точек зрения и сервисов. Сервисы должны соответствовать опорным точкам зрения (рис. 5.4).  Рис. 5.4. Сервисы, соотнесенные с точками зрения. Точки зрения также определяют входные данные и управляющую информацию для сервисов. Например, банкомат должен определять остаток денег после выдачи наличных. На ранних этапах процесса формирования требований эти данные и управляющая информация идентифицируются просто по имени. На рис. 5.5 представлена управляющая информация для точки зрения владельца счета, сервисы которой показаны на рис. 5.4. Управляющая информация вводится с помощью кнопок на панели банкомата, данные — посредством клиентской карточки или клавиатуры банкомата. Следующая стадия процесса формирования требований — получение более детальной информации относительно сервисов, используемых сервисами данных, и управляющих данных. Эта информация извлекается из мнений лиц, формирующих требования, связанные с каждой опорной точкой зрения. Для этого используются шаблоны точек зрения и описания сервисов в виде сценариев событий. Эти сценарии обсуждаются в следующем разделе. Шаблоны точек зрения, описания сервисов и сценарии событий разрабатываются для всех идентифицированных опорных точек зрения и сервисов.  Рис. 5.5. Данные и управляющая информация 5.7. МЕТОДИКА ФОРМИРОВАНИЯ ТРЕБОВАНИЙ, ОСНОВАННАЯ НА СЦЕНАРИЯХ Люди обычно легче воспринимают примеры из реальной жизни, чем абстрактные описания. Они легко понимают и могут оценить сценарии взаимодействия с программной системой. Специалисты могут использовать информацию, полученную из обсуждения сценариев взаимодействия с системой, для формулирования требований. Сценарии особенно полезны для детализации уже сформулированных требований, поскольку описывают последовательность интерактивной работы пользователя с системой. Каждый сценарий описывает одно или несколько возможных взаимодействий. В настоящее время разработаны многочисленные формы сценариев, которые предоставляют различную информацию на разных уровнях детализации системы. Варианты использования. Варианты использования (use-case) — это методика формирования требований, основанная на сценариях. Они стали основой нотаций в языке моделирования UML при описании объектных моделей систем. В самой простой форме в варианте использования определены действующие лица (в UML они называются актерами), т.е. пользователи, вовлеченные во взаимодействие, и имена типов взаимодействия. Варианты использования в первую очередь предназначены для определения функциональных требований к системе, они управляют всем процессом ее разработки. Все основные виды деятельности, такие как анализ, проектирование, тестирование, выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять, как результаты, которые хочет получить пользователь, влияют на архитектуру системы и как должны себя вести компоненты системы для того, чтобы реализовать нужную для пользователя функциональность. Понятие «вариант использования» впервые ввел А. Якобсон и затем придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта. Варианты использования в языке UML представляют в виде диаграмм прецедентов. Диаграмма прецедентов (Use Case Diagram) – это описание множества действий, которые система может осуществлять в ответ на воздействия, оказываемые на эту систему со стороны внешних по отношению к ней сущностей. 5.7.1 Построение диаграммы прецедентов Целями построения диаграммы прецедентов являются определение границы и контекста моделируемой предметной области на ранних этапах проектирования; формирование общих требований к поведению проектируемой системы; разработка концептуальной модели системы для ее последующей детализации; подготовка документации для взаимодействия с заказчиками и пользователями системы. Базовыми элементами диаграммы вариантов использования являются эктор и вариант использования. Эктор (актер) (Actor) – согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними. Вариант использования (Use Case), или прецедент, – внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с экторами. Таким образом, диаграмма прецедентов – это графическое представление экторов и прецедентов и их взаимодействия в системе. Экторы. Экторы (актеры) – это роли, исполняемыми сущностями, непосредственно взаимодействующими с системой. В литературе очень часто вместо термина «эктор» используется термин «актер», который мы и будем использовать в дальнейшем изложении. В языке UML актеры изображаются в виде пиктограммы «анимационный человечек» или в виде пиктограммы класса (рис. 5.6). Актеры представляют собой роли, а не конкретных людей или наименования работ. Актерами могут быть как люди (пользователи данной системы), так и внешние системы, которым необходима некоторая информация от данной системы. Большинство разработчиков моделей предпочитают использовать пиктограммы «человечек» для тех ролей, которые будут исполняться людьми, а пиктограммы класса – для тех ролей, которые будут играть другие системы.  Актеры не являются частью системы, они представляют собой внешние по отношению к системе сущности (это могут быть люди, программные или аппаратные средства), которые должны взаимодействовать с системой. Рис. 5.6. Варианты изображения актера на диаграмме прецедентов Можно выделить три основных типа актеров: – пользователи системы; – другие системы, взаимодействующие с данной; – время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Примерами актеров являются кассир, клиент банка, банковский служащий, президент, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон. Актера «время» отображают на диаграмме прецедентов, если необходимо смоделировать событие, происходящее с системой в определенный момент времени, но не инициируемое ни одним из других актеров. Примерами событий, которые могут инициироваться актером «время», являются автоматическое сохранение документа каждые 10 мин, создание резервной копии системы, выполняемое ежедневно вечером, закрытие окна-заставки через 5 с, смена изображения рекламного баннера на сайте. В процессе взаимодействия с системой актеры могут выполнять следующие функции: только снабжение информацией системы; только получение информации из системы; снабжение системы информацией и получение информации из нее. Прецеденты. В книге «UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование» Дж. Арлоу и А. Нейштадт определяют прецедент как описание последовательности действий, которые выполняют система, подсистема или класс. Варианты использования в контексте процесса управления требованиями к системе согласно А. Коберну (Коберн А. Современные методы описания функциональных требований к системам : пер. с англ. М. : Лори, 2002. 263 c.) трактуются следующим образом: – вариант использования фиксирует соглашение между участниками проекта относительно поведения системы; – вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одного из участников, называемого основным действующим лицом; – основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Пиктограмма прецедента представляет собой овал (рис. 5.7). Имя прецедента, как правило, записывается внутри овала, хотя может указываться и под ним. Вариант использования описывает типичное взаимодействие между пользователем и системой. Прецеденты всегда инициируются актером и описываются с точки зрения актеров. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.  Рис. 5.7. Пиктограмма прецедента Отношения Отношения – семантические (значимые) связи между элементами модели. На диаграмме прецедентов могут использоваться следующие типы отношений: – ассоциация (Аassociation) – для отношений между актерами и прецедентами; – включение (Include) и расширение (Еxtend) – для отношений между прецедентами и прецедентами; – обобщение (Generalization) – для отношений между актерами и актерами и прецедентами и прецедентами. Отношение ассоциации служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования, отражая связь актера и варианта использования. Ассоциация может быть простой или направленной. Простая ассоциация отражается линией без стрелки, проведенной между актером и вариантом использования (рис. 5.8).  Рис. 5.8. Отношение простой ассоциации Направленная ассоциация обозначается линией со стрелкой. Связь может быть как от актера к прецеденту, так и наоборот. Направление связи показывает, кто является ее инициатором: актер или прецедент (рис. 5.9). Отношение включения применяется, когда для полного осуществления основного (базового) варианта использования необходимо выполнение и включаемого варианта. Это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. Пример отношения включения. Пусть при решении вопроса о предоставлении кредита клиенту в поведение базового прецедента «Предоставление кредита в банке» включается обязательный прецедент «Проверка платежеспособности клиента» (рис. 5.10). Отношение включения отображается пунктирной стрелкой, направленной от основного прецедента к включаемому прецеденту.  Рис. 5.9 Отношения направленной ассоциации на диаграмме прецедентов банкомата  Рис. 5.10. Отношение включения Отношение расширения определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого используется базовым не всегда, а только при выполнении дополнительных условий. Отношение расширения применяется при описании изменений в нормальном поведении системы. Оно позволяет прецеденту использовать функциональные возможности другого прецедента только при необходимости. Например, при решении вопроса о предоставлении кредита клиенту банка базовый вариант использования «Предоставление кредита в банке» может быть расширен посредством необязательного расширяющего прецедента «Предоставление налоговых льгот» (рис. 5.11). Отношение включения отображается пунктирной стрелкой, направленной от расширяющего прецедента к основному прецеденту. Отношение расширения следует использовать для отражения дополнительных режимов, которые запускаются при наступлении кого-либо условия, а также альтернативных потоков, которые запускаются по выбору актера.  Рис. 5.11. Отношение расширения Отношение обобщения между вариантами использования служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом вариант В называется предком, или родителем по отношению к варианту А, а вариант А – потомком по отношению к варианту В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически отношение обобщения обозначается сплошной линией со стрелкой в виде незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 5.12). Эта линия имеет специальное название – стрелка «обобщение».  Рис. 5.12. Отношение обобщения между прецедентами Отношение обобщения между актерами используется, когда несколько актеров могут обладать общими свойствами и поведением, т. е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщенияс другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей (рис. 5.13).  Служащий Временный служащий Служащий с почасовой оплатой Служащий на окладе Рис. 5.13. Отношение обобщения между актерами 5.7.2. Рекомендации по построению диаграмм прецедентов Выявление актеров. Разработку диаграммы прецедентов следует начинать с определения списка актеров. Для выявления актеров могут быть использованы следующие вопросы: – кто заинтересован в определенном системном требовании; – какую роль система будет выполнять в организации; – кто получит преимущества от использования системы; – кто будет снабжать систему информацией, использовать информацию и получать информацию из системы; – кто будет осуществлять поддержку и обслуживание системы; – использует ли система внешние ресурсы; – выступает ли какой-либо участник системы в нескольких ролях; – выступают ли различные участники в одной роли; – будет ли новая система взаимодействовать со старой? Выявление прецедентов. После создания списка актеров необходимо рассмотреть, как каждый актер собирается использовать систему, причем во время идентификации прецедентов могут обнаружиться и новые актеры. Чтобы найти прецедент, необходимо найти ответы на вопросы: «Как каждый из актеров использует систему?» и «Что система делает для каждого актера?». Для того чтобы выделить прецеденты для системы, можно использовать следующие вопросы: – каковы задачи каждого актера; – будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы; – какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию; – должен ли актер информировать систему о внезапных изменениях внешней среды; – должен ли актер быть информирован об изменениях состояния системы? Пример диаграммы прецедентов. Рассмотрим пример разработки диаграммы прецедентов для системы «интернет-магазин» (рис. 5.14). Интернет-магазин должен позволять делать покупки с доставкой на дом. Клиенты этого магазина с помощью программы-браузера имеют доступ к каталогу продаваемых товаров. Для удобства клиентов в каталоге предусмотрена система поиска товаров, в которой все товары распределены по разделам и о каждом товаре предоставлена полная информация (название, вес, цена, изображение, дата изготовления и срок годности). При отборе клиентами товаров поддерживается виртуальная торговая корзина. Любое наименование товара может быть добавлено в корзину или изъято из нее в любой момент по желанию покупателя с последующим пересчетом общей стоимости покупки. Текущее содержимое корзины постоянно показывается клиенту. По окончании выбора товаров производится оформление заказа и регистрация покупателя.  Рис. 5.14 . Диаграмма прецедентов системы «интернет-магазин» На рис. 5.14 в качестве актеров моделируемой системы выделены любой пользователь, покупатель (зарегистрированный пользователь) и администратор. Так как администратор может делать все, что делает покупатель и пользователь, то между этими актерами показано отношение обобщения. Однако ни покупатель, ни пользователь не могут изменять каталог товаров и статус заказов, поэтому отношения ассоциации на диаграмме показаны только между актером «Администратор» и прецедентами «Изменить каталог товаров» и «Изменить статус заказа». 5.8. ЭТНОГРАФИЧЕСКИЙ ПОДХОД К ФОРМИРОВАНИЮ СИСТЕМНЫХ ТРЕБОВАНИЙ Системы программного обеспечения не существуют изолированно от окружающего мира. Они эксплуатируются в определенной социальной и организационной среде, поэтому системные требования должны разрабатываться с учетом этой среды. Учет социальных и организационных требований часто имеет большое значение для успеха системы на рынке программных продуктов. Многие представленные на рынке программные системы практически не имеют спроса именно потому, что не учитывают важности социальных и организационных требований. Этнографический подход к формированию системных требований используется для понимания и формирования социальных и организационных аспектов эксплуатации системы. Разработчик требований погружается в рабочую среду, где будет использоваться система. Его ежедневная работа связана с наблюдением и протоколированием реальных действий, выполняемых пользователями системы. Значение этнографического подхода заключается в том, что он помогает обнаружить неявные требования к системе, которые отражают реальные аспекты ее эксплуатации, а не формальные умозрительные процессы. Обычно людям трудно четко описать все аспекты выполняемой работы, поскольку способ выполнения часто определяется их характером и практическим опытом. Они понимают свою работу, но не могут объяснить ее взаимосвязь с другими видами работ, выполняемых в организации. Социальные и организационные факторы, которые оказывают влияние на работу, но не являются очевидными, могут стать явными, если описаны беспристрастными наблюдателями. В [328] этнографический подход использован для изучения работы офиса. Показано, что фактическая работа, выполняемая в офисе, более сложна и динамична, чем предусматривает простая модель, принятая для системы автоматизации делопроизводства. Это расхождение между реальной работой и моделью послужило причиной того, что офисные системы автоматизации не показывали той эффективности, на которую были рассчитаны. Этнографический подход также применялся при формировании требований для систем управления воздушными перевозками [36, 168], систем управления диспетчерскими службами метрополитена [159], финансовых систем [169] и других [287, 65]. Этнографический подход к формированию требований можно объединить спрототипированием (рис. 5.15). Этнографический подход позволяет получить требования, которые учитываются в разрабатываемом прототипе. Кроме того, этнографический подход используется при решении конкретных проблем прототипирования и при оценивании созданного прототипа. Этнографический подход позволяет детализировать требования для критических систем, чего не всегда можно добиться другими методами разработки требований. Однако, поскольку этот метод ориентирован на конечного пользователя, он не может охватить все требования предметной области и требования организационного характера. Поэтому он не является всеохватывающим подходом в формировании требований и должен использоваться совместно с такими подходами, как анализ вариантов использования.  Рис. 5.15 Использование этнографического подхода и прототипирования для формирования требований ЗАКЛЮЧЕНИЕ Процесс разработки требований включает анализ осуществимости создания системы, формирование и анализ требований, специфицирование требований, аттестацию требований и управление требованиями. Анализ требований является итерационным процессом, который включает анализ предметной области, сбор требований, их классификацию, разрешение противоречий, назначение приоритетов и проверку требований. Лица, участвующие в формировании требований, имеют различные приоритеты при формулировании требований. Поэтому сложные системы ПО необходимо анализировать с различных точек зрения. Социальные и организационные факторы оказывают большое влияние на системные требования. Требования могут выражаться в виде текстовых утверждений и графических моделей. Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять как результаты, которые хочет получить пользователь влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность |