И. Соммервилл - Инженерия программного обеспечения (1133538), страница 34
Текст из файла (страница 34)
3. Лица, участвующие в формировании требований, имеют различные предпочтения и мокнут выражать их разными способами. Разработчики должны определить все потенцнальныс источники требований и выделить общие и противорсчивые требования. 4. На требования к системс могут влиять политические факторы. Они могут исходить от руководитслсй, которые предъявляют требования только для того, чтобы усилить свое влияние в организации. 5. Экономнчсская и бизнес-обстановка, в которой происходит формирование трс. бований, нсизбсжно будст мсняться в ходе выполнсния этого процесса. Следовательно, и важность отдельных требований может изменяться.
Новые требования могут быть выдвинуты новым лицом, с которым первоначально не консультировались. Обобвгснная модель процесса формирования и анализа требований показана на рис. 5.2. Каждая организация использует собственный вариант этой модсли, зависящий от "местных" факторов: опыта работы коллектива разработчиков, типа разрабатываемой системы, используемых стандартов и т.д.
йзчзпо процесса Рис. 6.2. Щоуессформировпняя к пяплкзя зфебовпний Процесс формирования и анализа требований проходит через ряд этапов. 1. 4кплиз и~едзктяной обяяоли Аналитики должны изучить предметную область, где бу- дст эксплуатпроватьсз система. 2. Иор глргоованви. Это процесс взаимодействия с лицами, формирующими требова. ния. Во время этого процесса продолжастсл анализ прсдмстпой области. 3. Клпссифихауия згрейеяний. На этом этапе бесформенный набор трсбований прсоб- разустсл в логически свлзанныс группы требований.
6. Разработка требований 131 4. Разрешение проживоречиц Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода. 5. Назначение ггриорижеэмв. В любои наборе требований одни иэ них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. 6. Проверка жрейваний. На этом этапе определяетсл их полнота, последовательность и непротиворечивость. Как показано на рис. 6.2, процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому.
Цикл начинается с анализа предметной области и заканчивается проверкой требований. Понимание требований предметной области увеличивается в каждом цикле процесса формирования требований. В этом разделе описаны три подхода к формированию требований: метод, основанный на множестве опорных точек зрения, сценарии и этнографический метод. Другис подходы, когорые могут использоваться в процессе разработки требований, — это методы структурного ана. лиза, рассматриваемые в главе 7, и методы прототипирования, описываемые в главе 8. Не су. ществует универсального подхода к формированию и анализу требований. Обычно для разработки требований одновременно используется несколько подходов.
6.2.1. Опорные точки зрения Любая средняя или больв~ая систекга ПО обычно имеет различные типы конечных пользователей. Многие лица, участвующие в формировании требований, в своих требава. ниах к системе выражают собственные интересы. Например, в процессе формировании требований для системы банкоматов участвуют следующие лица.
1. Ойгчньмхгкенжы банка, пользующихся услугами банкоматов. 2. Предгэгавиэмли других банков, имеющих взаимные соглашения с данным банком о совместном использовании банкоматов. 3. МгнеджгРы угилиолов йгнха, получающих информацию из системы управления банкоматами. 4. Сотрудники угилиагов йгиха, вовлеченные в повседневную работу системы банкоматов, обрабатывающие рекламации клиентов и т.д. 5. Админипярапоры йм данных, ответственные за связь банкоматов с базой данных клиентов. 6. Е~ководимели сгужбы йполагногаи банка, обеспечивающей защиту системы башгоматов. 7.
Ождымархгжиига бенка, использующий систему банкоматов как средство маркетинга. 8. Рограйхачихи алларавгиых и ярограимных гредгэм, отвстствснныс эа сопровождение н модернизацию аппаратных и программных средств. Этот список показывает, что даже для относительно простой системы существует много различных точек зрения, которые должны быть рассмотрены. Раэличпыс точки зрения на проблему позволяют увидеть ес с разных сторон. Однако этн взгляды не являются пол. пастью независимыми и обычно перекрывают друг друга, а потому могут служить основой общих требований. Подход с использованием различных опорных точек зрения к разработке требований признает эти различные (опорные) точки зрения и использует нх в качестве ос- 132 х1асть 11.
Требования новы построения и организации как процесса формирования требований, так и непосредственно самих требований. Сильная сторона анализа, ориентированного на различные опорные точки зрения, в том, что он признает множество взглядов и обеспечивает основу для обнаружения противоречий в требованиях, предложенных различными лицами.
Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом'. 1. Как иеиюниих инфоуьчпции о системных данных, В этом случае на основе опорных точек зрения строится модель создания и использования даннык в системс. В процессе формирования требований отбираются все такие точки зрения„на их основе определлются данные, которые будут созданы или использованы при работе системы, и способы обработки этик данных. Методы ЯА[УТ [299, 900, 7о] и СОВЕ [242[ используют эту интерпретацию точек зрения. 2.
Кпх етРухтуфп гзредтггпвлений В этом случае точки зрения рассматриваются как особая часть модели системы [115, 260[. Например, на основе различных точек зрения могут разрабатываться подели "сущность-связь", модели конечного автомата и т.д. 3. Кпк яалунптаеи системных ефвшов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов [202, 203). Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления. Каждая из этих интерпретаций точек зрения имеет сильные и слабые стороны.
Опорные точки зрения как источники информации о системных данных и как представления имеют ценность для обнаружения противоречий в.требованиях [10Ц. Но испольэовать нх в процессе структурного анализа требований затруднительно, поскольку здесь не фиксируются связи между точками зрения и типами участников формирования требований.
Интерактивные системы поставляют сервисы конечным пользователям. Поэтому наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. Зти точки зрения взаимодействуют с системой, получая от нее сервисы и продуцнруя данные и управляющие сигналы. Зтот тип точек зрения имеет ряд преимуществ.
1. Точки зрения, внешние к системе, — естественный способ структурирования процесса формирования требований. 2. Сравнительно просто решить, какие точки зрения следует оставить в качестве опорных: они должны отображать какой-либо способ взаимодействия с системой. 3. Данный подход полезен для создания нефункциональных требований, с которыми можно связать какой-либо сервис. Многократно повторяющиеся разные точки зрения позволяют сформировать для сервисов различные нефункциональные требования. Длл понимание дальиейтего зттеаиала аеедует и)занять ео вниманью, нню автоу ивето отождттвллет тониуфеиил и фшннеехоеливо-наеиатт знюй тачхи зуеизт. Позвзому он адуаиютет тонхн фения и гово. унзвь иаи)нииед о взошюдпдееюии тонел з)гение е системой или о точна» здания — тиунататх еиетемних еедвзз аю зон. дает).
Д/зупгзиз словами, здеъ~ тфнззн "тонха зугпзил" озна юет го)лидо йиьии, нем нуннню мнение от. дельиогонезоеееа о юмлибо, -Прни. Рея. 6. Разработка требований 1Зз На основе этого подхода разработан метод ЧОК1) (Ч(сиро!пьОПепсед Кег)гйгетепи Оебпп(оп — определение требований на основе точек зрения) для формирования и анази. за требований (203, 2041. Основные этапы метода ЧОК11 показаны на рис. 6З. 1.
Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения. 2. Структурирование точек зрения — создание иерархии сгруппированных точек зрения. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня. 3. Документирование опорных точек зрения, которое заключается в точном описа- нии идентифицированных точек зрения и сервисов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
