Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

№

Бизнес-

правило-24

Бизнес-

правило-33

Бизнес-

правил

о-З

Бизнес-

правило-86

Бизнес-

правило-88

Определение

правила

Гип

правила

Статическое

или динами-

ческое

Только работники кафете-

рия, назначенные менед-

жером

кафетерия менед-

жерами меню, могут соз-

давать, изменять или

удалять меню кафетерия.

Ограничение Статическое

Передача данных по

сети,

включающая финансовую

или поддающуюся учету

личную информацию,

должна проходить со

128-

битным шифрованием,

Ограничение Статическое

[здесь должны быть дета-

ли

политики

ограниченно-

го

доступа

компьютер-

ным

системам]

Только штатные сотрудни- Ограничение

ки

могут регистрироваться

для совершения

каких-ли-

бо покупок в компании

посредством удержания

из

зарплаты.

Ограничение Статическое

Статическое

Источник

Политика

кафетерия

Политика

безопасно-

сти корпо-

рации

Политика

безопасно-

сти корпо-

рации

Финансо-

вый

дирек-

тор корпо-

рации

Сотрудник может зареги-

стрироваться для оплаты

питания в кафетерии по-

средством удержания

из

зарплаты, если не более

40% его начисленной зар-

платы удерживается в на-

стоящее

время по другим

причинам,

Ограничение Динамическое Финансо-

вый дирек-

тор корпо-

рации

Приложение Г

527

16-2437

Словарь терминов

CRUD-матрица

CRUD matrix — таблица, которая позволяет согла-

совать действия системы с элементами данных, чтобы показать, где

каждый элемент создается

(Created),

читается (Read), обновляется

(Updated) и удаляется (Deleted).

IEEE (Institute of Electrical and Electronics Engineers) — органи-

зация, которая поддерживает набор стандартов для управления и

вы-

полнения проектов по конструированию ПО и

систем.

Planguage — основанный на ключевых словах язык, предложенный

Tom

Gilb,

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

оцени-

ваемую спецификацию требований.

Альтернативное

напрвление

развития

alternative course — на-

правление, учитывающее вариант

использования,

которое ведет к ус-

пеху (достижение цели действующего

объекта),

но которое подразу-

мевает отклонение от нормального направления в специфике задач

или при взаимодействии объекта с системой.

Анализ основных

причин

- root cause analysis

—

действия,

кото-

рые предпринимаются для поиска основных причин, вызывающих на-

блюдаемые проблемы.

Анализ требований-

analysis,

requirements — процесс класси-

фикации информации, касающейся требований, по различным категори-

ям, оценка требований для определения желаемого качества, представ-

ление требований в различных формах, выделение детальных требова-

ний из требований более высокого уровня, обсуждение приоритетов

требований и т.д.

528

Аналитик требований

requirements analyst — роль члена команды

по разработке требований. Аналитик отвечает за работу с

заинтересо-

ванными лицами — за извлечение, анализ, определение,

утверждение

требований и за их управление. Эта роль также может называться

биз-

нес-аналитик, системный аналитик,

разработчик

требований и просто

аналитик.

Аналитик - analyst — см. аналитик требований.

Архитектура

architecture — структура системы, включающая ПС

и оборудование (они, собственно говоря, и составляют

систему),

взаи-

мосвязи между этими компонентами и поведение компонентов, види-

мое другим компонентам.

Атрибут качества ~ quality attribute — разновидность нефункцио-

нальных требований, которые описывают качество или свойства сис-

темы: удобство и простота использования, легкость

перемещения,

легкость в эксплуатации, целостность,

надежность,

эффективность и

устойчивость к сбоям. В требованиях описаны рамки атрибутов

каче-

ства,

до которых продукт демонстрирует желаемые характеристики,

но не те, которые продукт создает,

Атрибуты требований

requirement attribute — описательная

информация о требованиях, которая обогащает положения о желае-

мой функциональности продукта. К ней относятся источники данных,

логические обоснования, приоритеты, ответственные лица, номера

версий и выпусков.

Бизнес-аналитик

business analyst — см. аналитик требований.

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

business rule — политика, руководящие прин-

ципы или положения, которые определяют или ограничивают некото-

рые аспекты бизнеса.

Бизнес-требования

business requirement — высокоуровневая

бизнес-цель организации, которая строит продукт, или клиента, кото-

рый приобретает продукт.

Блок-схема - flowchart — модель, которая показывает этапы про-

цесса и точки принятия решений в логике процесса или программы.

Аналогична диаграмме взаимодействия.

Словарь терминов 529

Бумажный прототип - paper prototype — неработающая модель

пользовательского интерфейса ПО с недорогими, несложными в ис-

полнении эскизами экрана.

Вариант использования

use case — описание набора логически

связанных возможных взаимодействий действующего лица и систе-

мы, которые дают

результат,

ценный для действующего лица.

Вертикальный прототип

vertical prototype — частичная реали-

зация системы, содержащей ПО, с учетом всех уровней архитектуры.

Используется для оценки технической осуществимости и выполне-

ния. Также называется структурным прототипом или прототипом кон-

цепции.

Включенная взаимосвязь

includes relationship —

конструкция,

в которой несколько повторяющихся в разных вариантах использова-

ния стадий выделяются в отдельный подвариант использования. Когда

необходимо, этот подвариант вызывается вариантом использования

более

высокого

уровня

{или

«вызывающим»).

Выходные условия - postcondition — условия, которые описыва-

ют состояние системы после успешного завершения варианта исполь-

зования,

Горизонтальный прототип

horizontal prototype — частичная

или возможная реализация пользовательского интерфейса для сис-

тем ПО. Применяется для оценки легкости и простоты

использования,

а также завершенности и корректности требований. Также

называется

прототипом поведения или имитацией.

Граница проекта

scope — часть образа конечного продукта, соз-

даваемого в ходе текущего проекта. Определяет границу между внут-

ренней и внешней областью проекта,

Действующий объект

actor — лицо, играющее особую роль,

система ПО или аппаратное устройство, которое взаимодействует с

системой для достижения полезных

целей.

Также называется ролью

пользователя.

Дерево решений - decision tree — аналитическая модель, кото-

рая графически показывает действия системы в ответ на все комбина-

ции набора факторов, которые влияют на поведение части системы,

530 Словарь терминов

Диаграмма «сущность — связь» ~ entity-relationship diagram —

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

между парами

объектов.

Диаграмма варианта использования ~ use-case diagram — эта

аналитическая модель идентифицирует действующее лицо, взаимо-

действующее с системой для достижения значимых целей, и различ-

ные варианты использования, которые действующее лицо будет вы-

полнять.

Диаграмма взаимодействия - activity diagram —

аналитическая

модель, которая позволяет динамически представить систему, по-

средством изображения

потока

от

одной функции

другой.

СХОЖЕ!,

блок-схемой.

Диаграмма классов

class diagram — аналитическая модель, ко-

торая показывает набор классов системы или определенной предмет-

ной области и их взаимосвязи.

Диаграмма перехода состояний - state-transition diagram -

аналитическая модель, показывающая возможные состояния, или ста-

тусы, системы и разрешенные переходы между ними. Аналогична диа-

грамме состояний.

Диаграмма последовательностей ~ sequence diagram — анали-

тическая модель, которая показывает порядок прохождения

сообш,е-

ний между объектами или компонентами в системе для выполнения

работы.

Диаграмма потока данных - data flow diagram — аналитическая

модель, которая описывает процесс, набор

данных,

оконечные уст-

ройства и

потоки,

характеризующие поведение бизнес-процессов или

систем ПО.

Диаграмма состояний ~

statechart

diagram — аналитическая мо-

дель, показывающая последовательность состояний объекта на про-

тяжении времени его жизни в ответ на происходящие события или воз-

можные состояния системы в целом.

Аналогична

диаграмме перехода

состояний.

Документ об образе и границах

vision and scope

document

документ,

в котором определены бизнс-требования к новой

система,

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

проекта.

Словарь терминов 531

Допущение - assumption — положение, которое считается вер-

ным в отсутствие доказательств или точных знаний.

Зависимость - dependency — зависимость проекта от внешних

факторов, событий или групп, находящихся вне зоны контроля.

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

лица - stakeholder — активно участвующие в

проекте лица, группы или организации, которых затрагивает получен-

ный результат и которые сами могут влиять на этот результат.

«Золочение», украшательство - gold plating — на являющаяся

необходимой или избыточно сложная функциональность, разработан-

ная для продукта.

Извлечение

требований-

elicitation, requirements — процесс

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

посредством

интервью,

семинаров, анализа задач, рабочих потоков и

документов и других механизмов.

Карта диалогов

dialog map — аналитическая модель, которая

описывает архитектуру пользовательского интерфейса, показывая ви-

димые элементы и навигацию между ними.

Класс пользователей - user class

—

группа пользователей систе-

мы, имеющих схожие требования к системе. Члены пользовательского

класса функционируют как действующие лица при взаимодействии с

системой.

Класс

class — описание набора объектов, имеющих общие свой-

ства и

поведение,

которые стандартным образом соотносятся с эле-

ментами реального мира (людьми, местами или вещами) в бизнесе

или определенной предметной области.

Клиент - customer — лицо, заинтересованное в проекте, которое

запрашивает, оплачивает, выбирает, определяет, использует или полу-

чает продукт,

Количество элементов - cardinality — количество элементов дан-

ных объектов или данных, которые связаны с элементами других объ-

ектов или данных. Например, «один к одному», «один ко

многим»

или

«многие ко

многим».

Коммерческие готовые продукты - COTS (commercial off-the-

shelf) product — готовый набор ПО, приобретаемый у поставщика.

Применяется как готовое решение или интегрируется, настраивается

532 Словарь терминов

и расширяется в соответствии с потребностями клиента для удовле-

творения нужд последнего.

Контекстная диаграмма -

context

diagram

— аналитическая мо-

дель, которая описывает абстрактную систему высокого уровня. Кон-

текстная диаграмма определяет внешние для системы объекты, кото-

рые взаимодействуют с

ней,

но ничего не отображает внутренней

структуры или поведения системы.

Критерий приемлемости ~ acceptance criteria — условия, кот-

рым продукт должен удовлетворять, чтобы его приняли пользователи,

клиенты или другие заинтересованные лица.

Нефункциональные требования - nonfunctional requirement

описание

присущих свойств или характеристик, которые система ПО

должна демонстрировать, или ограничения, которые она должна со-

блюдать, в отличие от наблюдаемого поведения системы.

Нормальное напрвление развития ~ normal course —

последо-

вательность действий, заданная по умолчанию в варианте использова-

ния, которая ведет к удовлетворению выходных условий этого вариан-

та использования или достижению целей

пользователей.

Образ

vision — длительная стратегическая концепция конечной

цели и формы новой системы.

Образцы документов - process assets — документы — шаблон >t,

формы, списки, политики, процедуры, описание процессов и примеры

рабочих продуктов, которые собраны для эффективного

применения

организации с целью улучшить приемы разработки ПО.

Объект

entity — элемент области бизнеса, данные о котором бу-

дут собираться и сохраняться.

Объект -

object

—

отдельный вариант

класса,

для которого

собран

набор атрибутов данных и список возможных операций.

Например,

«Мэри Джонс» — отдельный вариант класса «Клиент».

Ограничение - constraint — налагается на доступные разработчи-

ку возможности дизайна или конструирования продукта.

Одноразовый прототип ~

throws

way

prototype — прототип, кото-

рый создается для уточнения и утверждения требований и вариантов

дизайна. Такие прототипы не используются после того, как цель дос-

тигнута.

Словарь терминов 533

Ожидание-exception

— условия, которые могут помешать успеш-

ному завершению варианта использования. Если некоторые возврат-

ные механизмы не работают, то выходные условия варианта использо-

вания не достигаются и желаемая цель не достигается.

Оконечное устройство - terminator — объект на контекстной диа-

грамме или диаграмме потока данных, который представляет классы

пользователей, действующие лица, системы ПО или

оборудование;

внешнее по отношению к описываемой системе, но взаимодействую-

щее с ней. Также называется внешним объектом.

Оперативный профиль ~

operational

profile — комплект сценари-

ев, который представляет ожидаемые

случаи

применения ПО.

Организатор мероприятия

facilitator — лицо, ответственное за

планирование и работу группы, например работу семинара по извле-

чению требований,

Основная версия требований -

baseline,

requirements — зафик-

сированный в определенный момент времени, согласованный, про-

смотренный и одобренный набор требований для указанной версии

продукта.

Основная модель - essential — лишена характерных черт и огра-

ничений. Описывает информацию на концептуальном уровне, незави-

симо от того, как она может быть реализована в системе.

Пилотная версия

pilot — контролируемое выполнение

нового

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

развертыванию.

Пользователь - user — клиент, который взаимодействует с систе-

мой непосредственно или косвенно

(например,

пользуется результа-

тами работы системы, хотя не генерирует эти

результаты).

Также на-

зывается конечным

пользователем.

Пользовательский сценарий ~ usage scenario — см. сценарий.

Правило решения - decision rule — согласованный способ выра-

ботки единого

решения,

Предварительные условия - precondition — условия, которые

должны быть удовлетворены, или состояние, в котором система долж-

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

534 Словарь терминов

Проверка - verification — процесс оценки рабочего продукта, по-

зволяющий определить, действительно ли он отвечает

спецификаци-

ям и условиям, определенным в начале разработки.

Прототип ~ prototype — частичная,

предварительная

или возмож-

ная

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

утвео-

ждения

требований, а также для разработки приемов. Прототипы

бы-

вают

эволюционные, одноразовые, бумажные, горизонтальные и вер-

тикальные. Их можно комбинировать, например эволюционный

вер-

тикальный прототип.

Процедура

procedure — пошаговое описание направления дей-

ствий для выполнения и завершения конкретной работы,

Процесс - process — последовательность действий, выполняемых

для реализации данных целей. Описание процесса представляет со-

бой документированное определение этих действий. Процесс может

содержать одну или несколько процедур.

Процесс построения требований ~ requirements engineering

область, которая охватывает все стороны жизненного цикла проекта

связанные с необходимыми возможностями и атрибутами

продукта.

Состоит из разработки требований и управления требованиями. Счи-

тается подобластью процессов построения системы и ПО,

Разработка требований

requirements

development

— процесс

определения объема проекта, классов и представителей пользовате-

лей, извлечения, анализа, спецификации и утверждения требований.

Результатом этого процесса считается основная версия требований, в

которой указано, что за продукт должен быть построен.

Расползание границ проекта - scope creep —

условия,

при кото-

рых границы проекта увеличиваются, как правило,

неконтролируемс,

на протяжении всего процесса.

Распределение allocation — см. распределение требований.

Распределение требований

requirements allocation — про-

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

ным и компонентным подсистемам.

Расширенная взаимосвязь

extends relationship —

конструк

ция,

где альтернативное направление варианта использования

от-

ветвляется от нормальной последовательности действий.

Последова

Словарь терминов 535

тельность действий альтернативного направления можно

определить

как расширенный вариант

использования,

который выполняется для

достижения альтернативного результата. Процесс

продолжается,

ко-

гда альтернативное направление вновь присоединяется к основному

для завершения,

Ретроспектива

retrospective — см. спецификация требований к

продукту и спецификация требований.

Риск

risk

— таблица, где показаны логические связи между от-

дельными функциональными требованиями и другими системными

документами и их фрагментами, включая другие функциональные тре-

бования, варианты использования, элементы дизайна и архитектуры,

фрагменты кода, варианты тестирования и бизнес-правила.

Словарь данных

data dictionary — набор определений элемен-

тов

данных,

структуры и атрибутов, которые важны для данной пред-

метной области.

Событие - event — инициирующее или стимулирующее событие,

которое происходит в системной среде, например поведение функции

или изменение состояния,

Совет по управлению

изменениями-

change control board -

группа людей, отвечающая за решение принять или отклонить предла-

гаемое изменение в требованиях к ПО.

Спецификация требований ~

specification,

requirements — про-

цесс документирования системы в структурированном, доступном

всем и управляемом формате. Также называется и результат этого

процесса. См. также спецификация требований к продукту.

Спецификация требований к продукту - software requirements

spe-cification — набор функциональных и нефункциональных требо-

ваний к продукту ПО,

Сторонник продукта - product champion — назначенный пред-

ставитель отдельного класса пользователей, который

поддерживав!

требования

представляемых

им групп пользователей.

Сценарий

scenario — описание

взаимодействия

пользователя и

системы с целью достижения некоторой цели. Пример работы с систе-

мой. Один из путей развития варианта использования. Часто

пред-

ставлен в виде истории.

536 Словарь терминов