12. Входящие и производные требования. Разработка требований в контексте изменений.

Требования, порожденные одним процессом, становятся исходными требованиями для другого процесса. Из этого естественным образом следует, что на вход процесса разработки требований поступают исходные требования (Input Requirements), а на выходе формируются производные требования (Derived Requirements)

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

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

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

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

На рисунке можно видеть, что практически любое действие может вызвать необходимость в изменении, а также то, что эти изменения обычно направлены снизу вверх. Это не означает, что заказчики никогда не меняют своих намерений или что проблемы возникают только на нижних уровнях в процессе применения стратегии проектирования «сверху вниз». Дело в том, что нисходящая траектория всегда соответствует естественному направлению движения, а для движения по обратному пути, очевидно, требуется поддержка. Одним из типичных случаев, когда может понадобиться запрос на изменения, является обнаружение ограничений, присущих используемой модели, или отклонений от нормы в анализируемых результатах, которые могут проявиться при попытке сгенерировать производные требования или стратегию проверки соответствия для производных требований.

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

13. Методы моделирования для разработки требований. Диаграммы потоков данных. Диаграммы «сущность-связь». Диаграммы состояний.

Что такое моделирование.

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

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

Способы моделирования для инженерии требований

1) Диаграммы потоков данных

2) Диаграммы сущность–связь

3) Диаграммы состояний

4) Объектно-ориентированные подходы

Диаграммы потоков данных

Диаграммы потоков данных (data flow diagrams, DFD) являются основой большинства традиционных методов моделирования. Это весьма лаконичная форма графического представления структуры и интерфейсов системы. Несмотря на то что изначально подобные диаграммы предназначались для отображения данных и их потоков в компьютерных системах, на практике их можно использовать для отображения потоков любого типа, независимо от того, базируется система на компьютерах или нет. Только поток управления (control flow) не может быть отображен с помощью диаграмм потоков данных. Диаграмма потоков данных состоит из следующих элементов: потоки данных (обозначаются именованными стрелками); процессы преобразования данных (окружности или эллипсы); хранилища данных (горизонтальные параллельные линии); внешние объекты (прямоугольники). Простой пример на рис. 3.1 демонстрирует использование диаграммы потоков в традиционном контексте информационных систем.

Потоки отображают обмен информацией или материальными объектами между двумя процессами преобразования данных. В реальных системах потоки могут быть непрерывными, создаваемыми по запросу, асинхронными и т. д. Диаграммы этого типа необходимо дополнять текстовыми описаниями каждого процесса, хранилища данных и потока. Словарь данных (data dictionary) используется для определения всех потоков и хранилищ данных. Каждый эллипс на диаграмме определяет основные функциональные возможности, которыми обладают компоненты системы. Эти возможности описываются в виде П-спецификаций (process specification) или мини-спецификаций (miniature specification). Подобные текстовые спецификации часто записываются в форме псевдокода. Контекстная диаграмма (context diagram) – это диаграмма потоков данных самого верхнего уровня, отображающая взаимодействие создаваемой системы с внешними системами (см. рис. 3.2).

Пример на Рис. 3.4.,Рис. 3.5.

Таким образом, диаграммы потоков данных:

отображают общую функциональную структуру и потоки;

определяют функции, потоки и хранилища данных;

определяют интерфейсы между функциями;

предоставляют основу для определения требований к системе;

предоставляют инструментальные средства;

широко используются для разработки программного обеспечения;

применимы при разработке любых систем.

Диаграммы сущность–связь

Моделирование информации, хранимой в системе, такой как планы полётов, записи баз данных и знаний, часто имеет важное значение. Диаграммы сущность–связь (entityrelationship diagrams, ERD) предоставляют средства моделирования сущностей, которые представляют интерес и отношений, которые существуют между ними. Диаграммы сущность–связь разработал Чен (Chen, 1976).

Сущность (entity) – это объект, который может быть недвусмысленно определён, например как клиент, поставщик, составная часть или продукция. Свойство (property) или атрибут (attribute) – это информация, описывающая сущность. Связь (relationship) характеризуется кардинальным числом (мощностью отношения), отражающим природу связи (один к одному, один ко многим, многие ко многим) между сущностями-участниками. Подтипом (subtype) называется подмножество другой сущности, то есть тип X является подтипом Y, если каждый член X принадлежит Y. Диаграмма сущность–связь определяет модель, которая описывает систему лишь частично, посредством определения сущностей внутри этой системы и связей между ними. Эта модель не зависит от процессов, которые требуют создания или использования информации. Таким образом, диаграмма сущность–связь представляет собой идеальный инструмент для абстрактного моделирования на этапе определения требований к системе в целом.

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

Описания функционирования и потоков данных недостаточно для определения требований. Кроме этого, необходима способность к описанию поведения системы, а в некоторых случаях и к описанию системы как сущности, имеющей конечное число возможных «состояний», когда внешние события выступают в роли переключателей, вызывающих переходы между состояниями. Чтобы отобразить все перечисленные аспекты, необходимо определить, в каких состояниях может находиться система и как она реагирует на события в каждом состоянии. Для этой цели чаще всего используют диаграммы состояний (statecharts), предложенные Харелом (Harel, 1987).

Диаграммы состояний рассматриваются в сочетании с описанием поведения системы. Полная иерархия состояний может быть показана в рамках одной диаграммы, в которой допускается параллелизм, таким образом, диаграммы состояний могут оказаться особенно полезными в тех случаях, когда в системе преобладают параллельные действия. Помеченный надписью прямоугольник с закруглёнными углами обозначает состояние. Иерархия отображается посредством вложений (инкапсуляции) событий, а линии со стрелками различной формы, снабженные кратким описанием событий, соответствуют переходам между состояниями. Описания состояний, событий и переходов позволяют применять диаграммы состояний для моделирования систем в целом. На рис. 3.11 показана диаграмма состояний для полёта самолёта. На самом верхнем уровне определены два состояния – «На земле» и «В воздухе», а также переходы между ними. Внутри состояния «В воздухе» расположены три независимые группы состояний, а внутри состояния «На земле» – группы состояний «Возможность выруливания» и «На взлётно-посадочной полосе»

В свою очередь, состояние «Возможность выруливания» включает в себя состояния более низкого уровня «Выруливание» и «На стоянке/В ангаре» и т. д. Переход в состояние «В воздухе» происходит, когда шасси самолёта отрываются от земли, а переход в состояние «На земле» – в момент контакта шасси с посадочной полосой. Каждое из этих состояний может уточняться (детализироваться), создавая иерархию возможных состояний, как показано на рис. 3.11. Диаграмма состояний имеет весьма полезное свойство. Когда состояние помечено знаком H (history), то при возвращении системы в это состояние все вложенные состояния также возвращаются к начальному положению.