Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 18

Более подробно об этомможно узнать по адресу www.mind+map.com.После интервью информация анализируется и формируются некоторые предварительные требования.3.7.3. АнкетыАнкеты не заменяют интервью.Если принято решение использовать анкеты без проведения интервью,можно оказаться в безвыходной ситуации, когда необходимо выбратьсписок вопросов до того, как стало известно, какие вопросы задавать.Анкеты могут быть полезным дополнением к интервью. Они хорошоподходят для получения ответов на конкретные закрытые вопросы.Можно выделить из интервью ключевые вопросы, объединить ихв анкету, а затем распространить ее на более широкую аудиторию.

Этопоможет проверить, правильно ли вы понимаете требования.3.7.4. Семинар по определению требованийСеминар – это один из самых эффективных способов сбора информации, относящейся к требованиям. Для выявления ключевых требований организуется семинар и основные заинтересованные стороны приглашаются принять в нем участие.Семинар должен сосредотачиваться на мозговой атаке. Это мощнаятехника сбора информации.Во встрече должны принимать участие руководитель проекта, разработчик требований, основные заинтересованные стороны и специалисты в определенной области.

Процедура проведения подобного семинара следующая:1. Объясните, что сбор требований проводится методом мозговой атаки.1.1. Все идеи принимаются как хорошие.1.2. Идеи записываются, но не обсуждаются – никогда ни о чем неспорьте, просто записывайте и двигайтесь дальше. Все будетпроанализировано позже.2.

Попросите членов команды назвать ключевые требования к системе.3.8. Что мы узнали872.1. Напишите каждое требование на стикере.2.2. Приклейте стикер на стену или доску.3. Затем можно еще раз просмотреть все выявленные требования и напротив каждого записать дополнительные атрибуты (см. раздел3.6.5).После встречи результаты анализируются и превращаются в требования, как обсуждалось ранее в этой главе. Результаты распространяются для сбора комментариев.Выработка требований – это итеративный процесс, в котором требования выявляются по мере уточнения понимания нужд заинтересованных сторон.

Возможно, придется организовать несколько семинаровпо мере углубления вашего понимания.Намного больше информации об организации семинаров и выработкетребований можно найти в книгах [Leffingwell 1] и [Alexander 1].3.8. Что мы узналиВ данной главе представлен рабочий поток определения требованийв UP и общее обсуждение требований, предъявляемых к программному обеспечению. Вы узнали следующее.• Большая часть работы в рабочем потоке определения требованийвыполняется в фазах Начало и Уточнение жизненного цикла проекта UP.• Наша метамодель требований (рис. 3.3) показывает, что существуетдва способа представления требований: 1) функциональные и нефункциональные требования и 2) прецеденты и актеры.• Детализация рабочего потока определения требований в UP включает следующие деятельности, представляющие интерес для ООаналитиков и разработчиков:••••Стандартный рабочий поток определения требований в UP расширяется:• актером: Разработчик требований;• деятельностью: Выявление функциональных требований;•••Выявление актеров и прецедентов;Детализация прецедента;Построение модели прецедентов.деятельностью: Выявление нефункциональных требований;деятельностью: Назначение приоритетов требований;• деятельностью: Отображение (trace) требований в прецеденты.Большинство провалов проектов обусловлено недостатками выработки требований.88Глава 3.

Рабочий поток определения требований••••••••Существует два типа требований:• функциональные требования – какое поведение должна предлагать система;• нефункциональные требования – определенное свойство илиограничение, накладываемое на систему.Правильно сформированные требования должны быть выраженыв простых структурированных фразах на английском языке, использующих выражения shall (должен), для того чтобы инструментальные средства выработки требований могли без труда проводить ихсинтаксический анализ.<id> <система> shall <действие>Модель требований содержит функциональные и нефункциональные требования к системе.

Это может быть:• документ;• база данных в системе управления требованиями.Требования могут быть организованы в таксономию – иерархию типов требований, которая классифицирует требования.Требования могут иметь атрибуты – дополнительную информацию(метаданные), ассоциированную с каждым требованием:• например приоритет – MoSCoW (Must have, Should have, Couldhave, Want to have);• например атрибуты RUP (Status, Benefit, Effort, Risk, Stability,TargetRelease);• количество атрибутов требований должно быть минимальным,от этого проект только выиграет.Карта местности еще не территория.

Естественный язык содержит:• пропуски – информация отфильтровывается;• искажения – информация модифицируется;• обобщения – информация обобщается в правила, убеждения и понятия об истинности и ложности.Кванторы общности (например, «все», «каждый») могут указыватьграницы чьейлибо ментальной карты сферы деятельности; их необходимо ставить под сомнение.Техники выявления требований:• интервью;• анкеты;• семинары.4Моделирование прецедентов4.1. План главыВ этой главе обсуждаются основы моделирования прецедентов, что является еще одной формой выработки требований.

Моделирование прецедентов будет рассмотрено так, как оно описано в UP. Основное внимание уделяется конкретным методам и стратегиям, которые могутприменяться ОО аналитиком или дизайнером для эффективного моделирования прецедентов. В разделе приведены только самые простыепрецеденты, чтобы ничто не отвлекало от рассмотрения этих методов.Полный (и более сложный) учебный пример можно найти на нашемвебсайте www.umlandtheunifiedprocess.com.UML не определяет какойлибо формальной структуры для описанияпрецедентов. В этом кроется проблема, поскольку разные разработчики моделей используют разные стандарты. Чтобы както справитьсяс этим, в этой главе и в учебном примере мы приняли простой и эффективный стандарт.

Наш вебсайт предоставляет схему XML (eXtensibleMarkup Language, расширяемый язык разметки) с открытым исходным кодом для прецедентов и актеров, которую читатели могут свободно использовать в своих проектах. Эти шаблоны основываются налучших практиках индустрии и обеспечивают простой, но при этомэффективный стандарт записи спецификаций прецедентов.На нашем вебсайте также можно найти очень простую таблицу стилей XSL (eXtensible Stylesheet Language, расширяемый язык стилей),которая превращает XMLдокументы прецедентов в HTML, отображаемый в броузере. Эта таблица стилей – полезный пример. Она можетбыть запросто настроена под стандарты фирменного оформления илидругие стандарты оформления документов для различных организаций.

Подробное обсуждение XML выходит за рамки нашей книги, нодля эффективной работы с такими документами, возможно, понадобится обратиться к учебникам по XML, таким как [Pitts 1] и [Kay 1].90Глава 4. Моделирование прецедентовобзор4.2. Моделирование прецедентовelse4.3. Деятельность UP: выявление актеров и прецедентовизучаем границы системыизучаем актеровизучаем прецедентыизучаем глоссарий проекта4.3.1. Контекст системы(границы системы)4.3.2.

Что такое актеры?4.3.3. Что такое прецеденты?4.3.4. Глоссарий проекта4.3.2.1. Идентификация актеров4.3.3.1. Идентификация прецедентов4.3.2.2. Время как актер4.3.3.2. Диаграмма прецедентов4.4. Деятельность UP: Детализация прецедента4.5. Спецификация прецедентов4.5.1. Имя прецедента4.5.2. ID прецедента4.5.3. Краткое описание4.5.4. Актеры4.5.5. Предусловия и постусловия4.5.6. Основной потокизучаем, как сократитьколичество прецедентовизучаем, как моделироватьповторение в потоке прецедентаизучаем, как моделироватьальтернативные потоки4.5.6.1.

Ветвление потока4.5.6.3. Повторение в потоке4.5.7. Моделированиеальтернативных потоков4.5.6.2. Ключевое слово Если (If)4.5.7.1. Выявлениеальтернативных потоков4.5.6.4. Ключевоеслово Для (For)4.5.6.5. Ключевоеслово Пока (While)4.6. Отображение требований4.7. Когда применять моделирование прецедентов4.8. Что мы узналиРис. 4.1. План главы4.5.7.2. Сколькоальтернативных потоков?4.2. Моделирование прецедентов91Помимо схемы с открытым исходным кодом и таблиц стилей мы работаем над более гибким подходом под названием SUMR (Simple Use caseMarkup Restructured – простая реструктурированная разметка прецедентов, произносится «summer»). Это простой язык структурированной разметки текстов с открытым исходным кодом для прецедентови актеров.

Примеры схемы SUMR, синтаксические анализаторы и генераторы XML и HTML предоставлены на нашем вебсайте, подробнеесм. в разделе 2.2.4.2. Моделирование прецедентовМоделирование прецедентов – это форма выработки требований. В разделе 3.6 было показано, как создавать модель требований, объединяяфункциональные и нефункциональные требования так называемым«традиционным» способом. Моделирование прецедентов – это другой,дополнительный способ выявления и документирования требований.Моделирование прецедентов обычно происходит следующим образом:•Устанавливаются границы потенциальной системы.•Выявляются актеры.•Выявляются прецеденты:••определяется прецедент;•устанавливаются основные альтернативные потоки.Предыдущие шаги повторяются, пока прецеденты, актеры и границы системы не стабилизируются.Обычно начинают с самой общей оценки границ системы, чтобы обозначить область моделирования.