Все атрибуты качества взаимосвязаны. В качестве простого примера можно рассмотреть требования "высокой надежности" и "простоты тестирования". Эти требования несколько противоречивы, поскольку для распределенной системы существует множество причин и способов выхода из строя.

Бизнес-правила

Бизнес-правила или правила предметной области определяют процессы в предметной области. Это требования не к конкретному приложению, а ко всем приложениям для данной предметной области. Типичными бизнес-правилами явля­ются политика компаний, а также физические или государственные законы.

Бизнес-правила влияют на другие требования к системе, обычно определяемые прецедентами, поскольку они проясняют многие неясные при описании прецедентов моменты. Например, если при описании прецедента Оформление продажи кому-то взбредет в голову осуществлять платежи по кредитной карточке без подписи покупа­теля, то такая возможность будет пресечена наличием бизнес-правила, учитывающе­го требования служб авторизации платежей (ПРАВ1).

Предупреждение. Правила — это не требования к приложению. Не включайте в список правил свойства системы. Правила описывают процессы из предметной области, а также их ограничения, а не свойства приложения.

Информация из предметной области

Зачастую очень важно внести в дополнительную спецификацию некоторую информацию из предметной области, имеющую отношение к разрабатываемой системе (продажам и бухгалтерскому учету, геофизических свойствах потоков нефти, воды или газа и т.д.) и позволяющую разработчикам глубже понять про­исходящие процессы. В этот раздел можно включать ссылки на литературу, мнения экспертов, формулы, законы к другие ссылки.

Пример для системы Алтын: видение (фрагмент)

Введение

Нам видится надежное приложение автоматизации розничной торговли следующего поколения (POS-система Алтын), обеспечивающее гибкую поддержку различных бизнес-правил, механизмы поддержки различных терминалов и интерфейсов пользователя, а также интеграцию с различными внешними вспомогательными системами. Анализ в этом примере носит иллюстративный характер.

Позиционирование

Экономические предпосылки

Существующие программные продукты не обеспечивают настройку на потребности различных пользо­вателей, в частности добавление различных бизнес-правил или поддержку разных сетевых архитектур (например, на основе "толстого" или "тонкого" клиента, двух-, трех- или четырехуровневые архитекту­ры). Кроме того, они плохо масштабируются. Ни одна из известных систем не обеспечивает автомати­ческий переход из интерактивного в автономный режим при сбоях внешних систем, Отсутствует простая возможность интеграции с внешними системами. Существующие системы не поддерживают новые тер­минальные технологии. Негибкость существующих систем открывает новую нишу на рынке программно­го обеспечения POS-систем.

---

Формулировка проблемы

Традиционные POS-системы не обладают гибкостью, неустойчивы к сбоям и не обеспечивают интеграцию с внешними системами. Это приводит к проблемам с оформлением продаж, несоответствию программного обеспечения экономическим потребностям предприятий, невозможности точной и своевременной обработ­ки данных и поддержки планирования. Эти проблемы касаются кассиров, менеджеров по продажам, сис­темных администраторов и руководителей предприятий.

Место системы

Указать, для кого предназначена система, описать ее свойства и отличия от продуктов конкурирующих организаций.

Заинтересованные лица

Необходимо определить, для кого предназначена система и каковы проблемы заинтересованных лиц.

Демографические особенности рынка...

Заинтересованные лица, не являющиеся пользователями системы...

Пользователи системы...

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

Необходимо объединить информацию из списка исполнителей и задач, а также из раздела описания пре­цедентов, отражающего потребности заинтересованных лиц.

Задачи уровня пользователя

Сюда можно включить список исполнителей и их задач, разработанный в процессе моделирования преце­дентов, либо более сжатую информацию. Пользователи (и внешние системы) используют данную систему в таких целях.

Кассир. Оформляет продажи, возврат товаров, регистрирует выручку.

Системный администратор. Управляет пользователями, безопасностью и системными таблицами.

Менеджер. Осуществляет запуск и завершает работу системы.

Система анализа торговой деятельности. Анализирует данные о продажах.

Окружение... Обзор

Перспективы продукта

Система Алтын обычно будет устанавливаться в магазинах, при использовании мобильных терминалов они будут располагаться вблизи сети магазинов, либо внутри магазинов. Система будет обслуживать поль­зователей и взаимодействовать с другими системами, как показано на рис. Видение 1. Диаграмма строится на основе диаграммы прецедентов.

Контекстные диаграммы можно строить в различных форматах с разной степенью детализации, но все они отражают взаимодействие внешних исполнителей с системой.

Преимущества системы

Подобно перечню исполнителей и их задач, в этой таблице указаны задачи, их решения и преимущества, однако на более высоком уровне, чем при описании прецедентов.

Здесь описывается основное значение и отличительные свойства продукта.

Свойство	Преимущества для заинтересованных лиц
Система будет обеспечивать всю основную функциональность, необходимую торговым орга­низациям, включая обработку информации о продажах, авторизацию платежей, оформление возврата платежей	Быстрая работа торговых точек в автоматическом режиме

Рис. Видение. Контекстная диаграмма POS-системы Алтын

---

Предположения и зависимости...

Стоимость и ценообразование...

Лицензирование и установка...

Основные свойства системы

Как было упомянуто выше, свойства системы описываются сжато путем перечисления основных функции.

Оформление продаж.

Авторизация платежей (по кредитной или дебитной карточке, чеком).

Системное администрирование и управление пользователями, безопасностью, таблицами констант

Автоматический переход в автономный режим работы при выходе из строя внешних систем

Транзакции в реальном времени на основе промышленных стандартов с внешними системами, включая бухгалтерскую систему, систему складского учета, учета человеческих ресурсов, вычисления налогов, службы авторизации платежей. Определение и выполнение настраиваемых бизнес-правил в фиксированных точках выполнения сценариев.

Другие требования и ограничения

Видение (комментарий)

Ту ли проблему мы решаем? Формулировка проблемы

На начальной стадии разработки при определении требований необходимо кратко сформулировать суть проблемы. Это позволит избежать недопонимания между заинтересованными лицами. Зачастую разные участники проекта ставят перед собой различные задачи.

В шаблоне RUP для формулировки проблемы предлагается использовать не текстовый, а табличный формат.

Проблема состоит в
Затрагивает
Влияет на
Ее успешное решение основывается на

Основные высокоуровневые цели и потребности заинтересованных лиц

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

• Необходимо обеспечить бесперебойное оформление продаж.

• Необходимо обеспечить возможность корректировки бизнес-правил.

Каковы основные проблемы и цели?

Заинтересованные лица зачастую формулируют свои потребности в форме пред­полагаемых решений, например: "Нам необходим штатный программист для на­стройки бизнес-правил при их изменении". Такие решения иногда оправданны, по­скольку заинтересованные лица хорошо понимают проблемы своей предметной об­ласти и возможные пути их решения. Однако иногда возникают попытки предложить решения, которые являются неоптимальными или выходят за рамки основной проблемы.

Поэтому проблему и основные цели должен исследовать системный анали­тик. Как было описано в предыдущих главах, он сможет выстроить иерархию проблем и определить приоритеты их решения.

Методы групповой работы

В процессе определения высокоуровневых требований и целей большое внима­ние уделяется групповой работе. Вот некоторые приемы групповой работы, облег­чающие процесс изучения проблемы и определения основных задач: построение диа­грамм Парето, многовариантное голосование, точечное голосование, номинальный групповой процесс, мозговой штурм и группировка по признаку подобия. Информа­цию об этих и других приемах можно почерпнуть из Internet. Автор предпочитает применять несколько перечисленных методик в процессе одного семинара для изу­чения общих проблем и требований с разных точек зрения.

---

Прецеденты — не единственный способ выражения функциональных требований.

Совет. В документ "Видение" желательно включать менее 50 свойств. Если их боль­ше, попробуйте сгруппировать некоторые из них и сформулировать на более высоком уровне абстракции.

Другие требования в документе "Видение”

В документе "Видение" системные свойства вкратце отражают функцио­нальные требования, которые более детально изложены в описании прецедентов. В этом документе можно также отразить другие требования (например, к на­дежности и удобству в использовании), которые более подробно описаны в раз­деле "Специальные требования" модели прецедентов и в дополнительной специ­фикации. Однако здесь возникает риск неоправданного дублирования. Напри­мер, в шаблонах продуктов, поддерживающих RUP, содержатся идентичные или схожие разделы требований к надежности, производительности, удобству в ис­пользовании и т.д. При таком дублировании очень сложно отслеживать измене­ния во всех документах. Кроме того, при этом нужен одинаковый уровень дета­лизации дополнительной спецификации и документа "Видение". То есть краткие и детальные описания требований становятся идентичными.

Совет. Старайтесь избегать дублирования требований в дополнительной специфика­ции, документе "Видение" и описании прецедентов. Лучше сформулировать их в дополнительной спецификации или описании прецедентов, а в документе "Видение" сделать ссылку на эти описания.

Этот совет позволит упростить разработку моделей. Однако если вы предпо­читаете использовать стандартные шаблоны, то это тоже не запрещается.

Видение, свойства или прецеденты — что раньше?

О порядке разработки артефактов говорить неуместно. Различные артефак­ты, относящиеся к требованиям, создаются параллельно. Тем не менее, можно порекомендовать такую последовательность разработки.

1. Создайте краткий черновой вариант документа "Видение".

2. Идентифицируйте задачи пользователей и соответствующие прецеденты.

3. Опишите некоторые прецеденты и приступите к разработке дополнитель­ной спецификации.

4. На основе полученной информации уточните документ "Видение".

Комментарии: словарь терминов

В простейшем варианте словарь терминов (glossary) представляет собой список важных понятий и их определение. Очень часто возникает ситуация, когда тех­нический или другой термин используется заинтересованными лицами в не­сколько различных значениях. Такие противоречия необходимо разрешить для облегчения общения и однозначной формулировки требований.

Совет. Начинайте разработку словаря терминов на ранних этапах выполнения проек­та. Мне приходилось работать в коллективах, где один и тот же термин по-разному трактовался различными разработчиками.

В словарь терминов нужно вносить не все возможные понятия, а только не­ясные, неоднозначные или требующие дополнительного изучения, например, информацию о форматировании или правила верификации.

---

Словарь терминов в роли словаря данных

В рамках UP словарь терминов также играет роль словаря данных (data dictionary) — документа, содержащего информацию о данных. На начальной стадии проекта словарь терминов включает лишь основные термины и их описа­ние, а на стадии развития его можно превратить в словарь данных.

К атрибутам терминов относятся следующие.

• Синонимы

• Описание

• Формат (тип, длина, единицы измерения)

• Взаимосвязи с другими элементами

• Диапазон значений

• Правила проверки корректности

Составные термины

В словарь терминов заносятся не только простейшие понятия, такие как "цена товара". В него необходимо включать и сложные элементы, например, "продажа" (это понятие включает в себя другие элементы, такие как дата и место продажи), а также аббревиатуры, используемые для описания передачи дан­ных между исполнителями в рамках одного прецедента. Например, рассмотрим следующий фрагмент описания прецедента Оформление продажи.

Система отправляет запрос на авторизацию платежа внешней службе авторизации платежей и запрос на подтверждение платежа. Термин "запрос на авторизацию платежа" обозначает набор данных, содер­жание которых необходимо пояснить в словаре терминов.

Надежные спецификации — нет ли здесь противоречия?

При описании требований может сложиться впечатление, что реальные требова­ния уже хорошо определены и вполне понятны и их можно использовать для надежного планирования и объективного оценивания состояния проекта. Однако это иллюзия. Разработчики программного обеспечения из собственного опыта знают, насколько это не так. Об этом свидетельствует и высказывание Гете, вы­бранное в качестве эпиграфа к данной главе.

На самом деле реальное значение имеет лишь соответствие программы тес­там, определенным пользователями и заинтересованными лицами, а также вы­полнение поставленных задач (которые зачастую нельзя четко сформулировать до начала работы с программой).

Создание дополнительной спецификации и документа "Видение" — это уп­ражнение, позволяющее несколько прояснить поставленные задачи, обосновать назначение продукта и описать основные идеи. Однако эти документы, как и любой артефакт дисциплины определения требований; не являются надежной спецификацией. Только в процессе написания кода, его тестирования, получения обратной связи, взаимодействия с пользователями и потребителями можно со­ставить реальное представление о сущности системы.

Это не призыв к отказу от анализа и быстрому написанию кода, а лишь ре­комендации по правильному восприятию требований и их постоянной доработке.

Не слишком ли много UML на начальной стадии проекта?

Основная задача начальной фазы — накопить достаточно информации для составле­ния общего видения проекта, принятия решения о его достижимости и целесообраз­ности. Поэтому на этом этапе не требуется создавать подробных диаграмм в системе обозначений языка UML за исключением простых диаграмм прецедентов. На данном этапе необходимо сосредоточить внимание на осмыслении масштаба проекта и 10% требований. Разрабатываемые документы являются текстовыми. Большая часть диа­грамм приходится на следующую фазу — фазу развития.

---

Смотрите также файлы

• Курсовая работа Управление проектами.docx

• Лабораторная ПРИС управление мероприятиями.docx

• КИС Контрольная работа.doc

• Технические измерения и приборы курсовой.pdf

• Курсовая.doc