На рис. Г-3 показана диаграмма состояний, где отображен возможный статус заказа набора блюд и его возможные изменения.
Рис. Г-3. Диаграмма состояний для статуса заказов на наборы блюд.
Бизнес-правила
(нижеследующее — пример отдельного перечня бизнес-правил)
| № | Определение правила. | Тип правила | Статическое или динамическое | Источник |
| Бизнес-правило- 1 | Периоды доставки — это 15-минутные интервалы, начинающиеся каждую четверть часа. | Факт | Статическое | Менеджер кафетерия |
| Бизнес-правило-2 | Доставка всех заказов должна быть завершена между 10:00 и 14:00 по местному времени. | Ограничение | Динамическое | Менеджер кафетерия |
| Бизнес-правило-3 | Все блюда из одного заказа должны быть доставлены в один и тот же пункт. | Ограничение | Статическое | Менеджер кафетерия |
| Бизнес-правило-4 | Все блюда из одного заказа должны быть оплачены одним и тем же методом. | Ограничение | Статическое | Менеджер кафетерия |
| Бизнес-правило-8 | Блюда должны быть заказаны не более, чем за 14 календарных дней до даты доставки. | Ограничение | Динамическое | Менеджер кафетерия |
| Бизнес-правило-11 | Если заказ доставлен, то клиент должен оплатить его посредством удержания из зарплаты. | Ограничение | Динамическое | Менеджер кафетерия |
| Бизнес-правило- 12 | Стоимость заказа подсчитывается как сумма цен единиц каждого блюда, умноженных на количество заказанных единиц этого блюда, плюс соответствующий налог с продаж, плюс плата за доставку, если заказ доставляется в пункт, расположенный вне зоны бесплатной доставки. | Вычисление | Динамическое | Политика кафетерия, налоговые законы штата |
| Бизнес-правило-24 | Только работники кафетерия, назначенные менеджером кафетерия менеджерами меню, могут создавать, изменять или удалять меню кафетерия. | Ограничение | Статическое | Политика кафетерия |
| Бизнес-правило-33 | Передача данных по сети, включающая финансовую или поддающуюся учету личную информацию, должна проходить со 128-битным шифрованием. | Ограничение | Статическое | Политика безопасности корпорации |
| Биэнес-правило-35 | [здесь должны быть детали политики ограниченного доступа к компьютерным системам] | Ограничение | Статическое | Политика безопасности корпорации |
| Бизнес-правило-86 | Только штатные сотрудники могут регистрироваться для совершения каких-либо покупок в компании посредством удержания из зарплаты. | Ограничение | Статическое | •Финансовый директор корпорации |
| Бизнес-правило-80 | Сотрудник может зарегистрироваться для оплаты питания в кафетерии посредством удержания из зарплаты, если не более 40% его начисленной зарплаты удерживается в настоящее время по другим причинам. | Ограничение | Динамическое | Финансовый директор корпорации |
|
|
Словарь терминов
CRUD-матрица — CRUD matrix — таблица, которая позволяет согласовать действия системы с элементами данных, чтобы показать, где каждый элемент создается (Created), читается (Read), обновляется (Updated) и удаляется (Deleted).
IEEE (Institute of Electrical and Electronics Engineers) — организация, которая поддерживает набор стандартов для управления и выполнения проектов по конструированию ПО и систем.
Planguage — основанный на ключевых словах язык, предложенный Tom Gilb, который позволяет создать точную и количественно оцениваемую спецификацию требований.
|
|
Альтернативное направлении развития — alternative course — направление, учитывающее вариант использования, которое ведет к успеху (достижение цели действующего объекта), но которое подразумевает отклонение от нормального направления в специфике задач
или при взаимодействии объекта с системой.
Анализ основных причин— root cause analysis действия, которые предпринимаются для поиска основных причин, вызывающих наблюдаемые проблемы.
Анализ требований— analysis, requirements — процесс классификации информации, касающейся требований, по различным категориям, оценка требований для определения желаемого качества, представление требований в различных формах, выделение детальных требований из требований более высокого уровня, обсуждение приоритетов требований и т.д.
Аналитик требований requirements analyst — роль члена команды по разработке требований. Аналитик отвечает за работу с заинтересованными лицами — за извлечение, анализ, определение, утверждение требований и за их управление. Эта роль также может называться бизнес-аналитик, системный аналитик, разработчик требований и просто аналитик.
Аналитик — analyst — см. аналитик требований.
Архитектура — architecture — структура системы, включающая ПС и оборудование (они, собственно говоря, и составляют систему), взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам.
Атрибут качества — quality attribute — разновидность нефункциональных требований, которые описывают качество или свойства системы: удобство и простота использования, легкость перемещения, легкость в эксплуатации, целостность, надежность, эффективность и устойчивость к сбоям. В требованиях описаны рамки атрибутов качества, до которых продукт демонстрирует желаемые характеристики, но не те, которые продукт создает,
|
|
Атрибуты требований requirement attribute — описательная информация о требованиях, которая обогащает положения о желаемой функциональности продукта. К ней относятся источники данных, логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.
Бизнес-аналитик— business analyst — см. аналитик требований.
Бизнес-правило — business rule — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса.
Бизнес-требования — business requirement — высокоуровневая бизнес-цель организации, которая строит продукт, или клиента, который приобретает продукт.
Блок-схема — flowchart — модель, которая показывает этапы процесса и точки принятия решений в логике процесса или программы. Аналогична диаграмме взаимодействия.
Бумажный прототип — paper prototype — неработающая модель пользовательского интерфейса ПО с недорогими, несложными в исполнении эскизами экрана.
Вариант использования — use case — описание набора логически
связанных возможных взаимодействий действующего лица и системы, которые дают результат, ценный для действующего лица.
Вертикальный прототип vertical prototype — частичная реализация системы, содержащей ПО, с учетом всех уровней архитектуры. Используется для оценки технической осуществимости и выполнения. Также называется структурным прототипом или прототипом концепции.
Включенная взаимосвязь — includes relationship — конструкция, в которой несколько повторяющихся в разных вариантах использования стадий выделяются в отдельный подвариант использования. Когда необходимо, этот подвариант вызывается вариантом использования более высокого уровня (или «вызывающим»).
Выходные условия — postcondition — условия, которые описывают состояние системы после успешного завершения варианта использования,
Горизонтальный прототип horizontal prototype — частичная 'или возможная реализация пользовательского интерфейса для систем ПО. Применяется для оценки легкости и простоты использования, а также завершенности и корректности требований. Также называется прототипом поведения или имитацией.
Граница проекта — scope — часть образа конечного продукта, создаваемого в ходе текущего проекта. Определяет границу между внутренней и внешней областью проекта,
Действующий объект actor — лицо, играющее особую роль, система ПО или аппаратное устройство, которое взаимодействует с системой для достижения полезных целей. Также называется ролью пользователя.
Дерево решений — decision tree — аналитическая модель, которая графически показывает действия системы в ответ на все комбинации набора факторов, которые влияют на поведение части системы.
Диаграмма «сущность - связь» — entity-relationship diagram — аналитическая модель, которая показывает логические взаимосвязи между парами объектов.
Диаграмма варианта использования — use-case diagram — эта аналитическая модель идентифицирует действующее лицо, взаимодействующее с системой для достижения значимых целей, и различные варианты использования, которые действующее лицо будет выполнять.
Диаграмма взаимодействия — activity diagram — аналитическая модель, которая позволяет динамически представить систему, посредством изображения потока от одной функции к другой. Схожа с блок-схемой.
Диаграмма классов — class diagram — аналитическая модель, которая показывает набор классов системы или определенной предметной области и их взаимосвязи.
Диаграмма перехода состояний — state-transition diagram — аналитическая модель, показывающая возможные состояния, или статусы, системы и разрешенные переходы между ними. Аналогична диаграмме состояний.
Диаграмма последовательностей — sequence diagram — аналитическая модель, которая показывает порядок прохождения сообщений между объектами или компонентами в системе для выполнения работы.
Диаграмма потока данных — data flow diagram — аналитическая
модель, которая описывает процесс, набор данных, оконечные устройства и потоки, характеризующие поведение бизнес-процессов или систем ПО.
Диаграмма состояний — statechart diagram — аналитическая модель, показывающая последовательность состояний объекта на протяжении времени его жизни в ответ на происходящие события или возможные состояния системы в целом. Аналогична диаграмме перехода состояний.
Документ об образе и границах — vision and scope document — документ, в котором определены бизнес-требования к новой системе, в том числе положения об образе продукта и описания границы проекта.
Допущение — assumption — положение, которое считается верным в отсутствие доказательств или точных знаний.
Зависимость — dependency — зависимость проекта от внешних (факторов, событий или групп, находящихся вне зоны контроля.
Заинтресованные лица — stakeholder — активно участвующие в проекте лица, группы или организации, которых затрагивает полученный результат и которые сами могут влиять на этот результат.
«Золочение», украшательство — gold plating — на являющаяся необходимой или избыточно сложная функциональность, разработанная для продукта.
Извлечение требований — elicitation, requirements — процесс определения требований к ПО или системе от различных источников посредством интервью, семинаров, анализа задач, рабочих потоков и документов и других механизмов.
Карта диалогов — dialog map — аналитическая модель, которая описывает архитектуру пользовательского интерфейса, показывая видимые элементы и навигацию между ними.
Класс пользователей — user class группа пользователей системы, имеющих схожие требования к системе. Члены пользовательского класса функционируют как действующие лица при взаимодействии с системой.
Класс — class — описание набора объектов, имеющих общие свойства и поведение, которые стандартным образом соотносятся с элементами реального мира (людьми, местами или вещами) в бизнесе или определенной предметной области.
Клиент — customer — лицо, заинтересованное в проекте, которое запрашивает, оплачивает, выбирает, определяет, использует или получает продукт,
Количество элементов — cardinality — количество элементов данных объектов или данных, которые связаны с элементами других объектов или данных. Например, «один к одному», «один ко многим» или «многие ко многим».
Коммерческие готовые продукты — COTS (commercial off-the-shelf) product — готовый набор ПО, приобретаемый у поставщика. Применяется как готовое решение или интегрируется, настраивается и расширяется в соответствии с потребностями клиента для удовлетворения нужд последнего.
Контекстная диаграмма — context diagram — аналитическая модель, которая описывает абстрактную систему высокого уровня. Контекстная диаграмма определяет внешние для системы объекты, которые взаимодействуют с ней, но ничего не отображает внутренней структуры или поведения системы.
Критерий приемлемости ~ acceptance criteria — условия, кот-рым продукт должен удовлетворять, чтобы его приняли пользователи, клиенты или другие заинтересованные лица.
Нефункциональные требования — nonfunctional requirement —
описание присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна соблюдать, в отличие от наблюдаемого поведения системы.
Нормальное направление развития — normal course — последовательность действий, заданная по умолчанию в варианте использования, которая ведет к удовлетворению выходных условий этого варианта использования или достижению целей пользователей.
Образ — vision — длительная стратегическая концепция конечной цели и формы новой системы.
Образцы документов — process assets — документы — шаблоны, формы, списки, политики, процедуры, описание процессов и примеры рабочих продуктов, которые собраны для эффективного применения в организации с целью улучшить приемы разработки ПО.
Объект — entity — элемент области бизнеса, данные о котором будут собираться и сохраняться.
Объект — object— отдельный вариант класса, для которого собран набор атрибутов данных и список возможных операций. Например, «Мэри Джонс» — отдельный вариант класса «Клиент».
Ограничение — constraint — налагается на доступные разработчику возможности дизайна или конструирования продукта.
Одноразовый прототип — throws way prototype — прототип, который создается для уточнения и утверждения требований и вариантов дизайна. Такие прототипы не используются после того, как цель достигнута.
Ожидание — exception — условия, которые могут помешать успешному завершению варианта использования. Если некоторые возвратные механизмы не работают, то выходные условия варианта использования не достигаются и желаемая цель не достигается.
Оконечное устройство — terminator — объект на контекстной диаграмме или диаграмме потока данных, который представляет классы пользователей, действующие лица, системы ПО или оборудование. внешнее по отношению к описываемой системе, но взаимодействующее с ней. Также называется внешним объектом.
Оперативный профиль — operational profile — комплект сценариев, который представляет ожидаемые случаи применения ПО.
Организатор мероприятия — facilitator — лицо, ответственное за планирование и работу группы, например работу семинара по извлечению требований,
Основная версия требований — baseline, requirements — зафиксированный в определенный момент времени, согласованный, просмотренный и одобренный набор требований для указанной версии продукта.
Основная модель — essential — лишена характерных черт и ограничений. Описывает информацию на концептуальном уровне, независимо от того, как она может быть реализована в системе.
Пилотная версия — pilot — контролируемое выполнение нового процесса для оценки его работы в реальных условиях и готовности к развертыванию.
Пользователь — user — клиент, который взаимодействует с системой непосредственно или косвенно (например, пользуется результатами работы системы, хотя не генерирует эти результаты). Также называется конечным пользователем.
Пользовательский сценарий — usage scenario — см. сценарий.
Правило решения — decision rule — согласованный способ выработки единого решения
Предварительные условия — precondition — условия, которые должны быть удовлетворены, или состояние, в котором система должна пребывать, чтобы мог начаться вариант использования.
Проверка — verification — процесс оценки рабочего продукта, позволяющий определить, действительно ли он отвечает спецификациям и условиям, определенным в начале разработки.
Прототип ~ prototype — частичная, предварительная или возможная реализация программы. Применяется для исследования и утверждения требований, а также для разработки приемов. Прототипы бывают эволюционные, одноразовые, бумажные, горизонтальные и вертикальные. Их можно комбинировать, например эволюционный вертикальный прототип.
Процедура — procedure — пошаговое описание направления действий для выполнения и завершения конкретной работы,
Процесс — process — последовательность действий, выполняемых для реализации данных целей. Описание процесса представляет собой документированное определение этих действий. Процесс может содержать одну или несколько процедур.
Процесс построения требований — requirements engineering — область, которая охватывает все стороны жизненного цикла проекта, связанные с необходимыми возможностями и атрибутами продукта Состоит из разработки требований и управления требованиями. Считается подобластью процессов построения системы и ПО,
Разработка требований — requirements development — процесс определения объема проекта, классов и представителей пользователей, извлечения, анализа, спецификации и утверждения требований. Результатом этого процесса считается основная версия требований, в которой указано, что за продукт должен быть построен.
Расползание границ проекта — scope creep — условия, при которых границы проекта увеличиваются, как правило, неконтролируемость. на протяжении всего процесса.
Распределение allocation — см. распределение требований.
Распределение требований requirements allocation — процесс распределения системных требований по различным архитектурным и компонентным подсистемам.
Расширенная взаимосвязь — extends relationship — конструкция, где альтернативное направление варианта использования ответвляется от нормальной последовательности действий. Последовательность действий альтернативного направления можно определить как расширенный вариант использования, который выполняется для достижения альтернативного результата. Процесс продолжается, когда альтернативное направление вновь присоединяется к основному для завершения,
Ретроспектива — retrospective — см. спецификация требований к продукту и спецификация требований.
Риск — risk — таблица, где показаны логические связи между отдельными функциональными требованиями и другими системными документами и их фрагментами, включая другие функциональные требования, варианты использования, элементы дизайна и архитектуры,
фрагменты кода, варианты тестирования и бизнес-правила.
Словарь данных — data dictionary — набор определений элементов данных, структуры и атрибутов, которые важны для данной предметной области.
Событие — event — инициирующее или стимулирующее событие, которое происходит в системной среде, например поведение функции
или изменение состояния,
Совет по управлению изменениями— change control board — группа людей, отвечающая за решение принять или отклонить предлагаемое изменение в требованиях к ПО.
Спецификация требований — specification, requirements — процесс документирования системы в структурированном, доступном всем и управляемом формате. Также называется и результат этого процесса. См. также спецификация требований к продукту.
Спецификация требований к продукту — software requirements specification — набор функциональных и нефункциональных требований к продукту ПО,
Сторонник продукта — product champion — назначенный представитель отдельного класса пользователей, который поддерживает требования представляемых им групп пользователей.
Сценарий — scenario — описание взаимодействия пользователя и системы с целью достижения некоторой цели. Пример работы с системой. Один из путей развития варианта использования. Часто представлен в виде истории.
Таблица «событие - реакция» — event-response table — перечень внешних или зависящих от времени событий, которые могут влиять на систему, и описание того, как система будет отвечать на каждое из них.
Таблица решения — decision table —таблица, где показаны все комбинации значений для наборов факторов, которые влияют на поведение части системы, и определены ожидаемые действия системы в ответ на каждую комбинацию.
Трассирование — tracing (also traceability) — процесс определения логических связей между одним элементом системы (вариантам [использования, функциональными требованиями, бизнес-правилами, компонентами дизайна, фрагментами кода, вариантами тестирования и т.д.) и другим.
Требования — requirement — документ, где указаны потребности или цели пользователей либо условия и возможности, которыми должен обладать продукт, чтобы удовлетворить такие возможности или цели,
Требования для интерфейса внешнего устройства — external interface requirement — описание интерфейса между системой ПО и пользователем, другой системой ПО или оборудованием.
Требования к системе — system requirement— высокоуровневые требования к продукте, который состоит из множества подсистем, в том числе только ПО или ПО и оборудования.
Требования пользователей — user requirement — цели и задачи, которые пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы.
Управление требованиями — requirements management — работа с определенным набором требований к продукту — начиная от процесса разработки продукта и заканчивая поддержкой действующего продукта. Управление подразумевает трассирование статуса продукта, управление изменениями требований и версиями спецификаций требований, а также трассирование отдельных требований до других этапов проекта и рабочих продуктов.
Утверждение—validation — процесс оценки рабочего продукта, позволяющий определить, действительно ли он отвечает требованиям.
Функциональная точка — function point — измерение размера ПО, основанное на числе и сложности внутренних логических файлов, файлов интерфейса внешнего устройства, вводимых извне данных, результатов и запросов.
Функциональные требования functional requirement — положение о фрагменте требуемой функциональности или поведения, которые система проявляет при определенных условиях.
Функция — feature — набор логически связанных функциональных требований, которые обеспечивают возможность для использования и дают возможность удовлетворить бизнес-задачу.
Цикл водопадной модели проекта — waterfall development life cycle — модель процесса разработки ПО, в которой различные действия с требованиями, дизайном, кодированием, тестированием и развертыванием выполняются последовательно, с небольшим наложением или итерациями.
Цикл разработки ПО — software development life cycle — последовательность действий, в которой ПО определяется, конструируется, строится и проверяется.
Шаблон — template — образец, который используется в качестве руководства при создании всеобъемлющей документации или других элементов.
Эволюционный прототип — evolutionary prototype — полностью функциональный прототип, построенный как «скелет» или некая стадия конечного продукта, которые постепенно будут «обрастать мясом» по мере прояснения требований.
Эксперт предметной области — subject matter expert — лицо, имеющее обширный опыт и знания в предметной области и считающееся авторитетным источником информации о предметной области.
Экспертиза — inspection — тип экспертной оценки, когда члены специально созданной команды в определенном и строгом порядке исследуют рабочий продукт на предмет выявления дефектов.
Экспертная оценка — peer review — действия, предпринимаемые одной или несколькими лицами (не авторами продукта), для исследования продукта с целью обнаружить возможные дефекты и улучшить возможности.
Экстремальное программирование — Extreme Programming — «быстрый» метод разработки ПО, который характеризуется тесным взаимодействием разработчиков с находящимися тут же представителями клиентов, ограничением документации требований «историями пользователей», а также быстрым и частым выпуском небольших фрагментов функциональности пользователей.