17. Определение области проблем. Согласование требований с заинтересованными сторонами.

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

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

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

Является ли требование полным?

Является ли требование понятным?

Является ли требование реализуемым?

Является ли план проверки соответствия понятным и приемлемым?

18. Определение заинтересованных сторон. Разработка сценариев использования. Определение границ системы. Сбор требований.

Заинтересованная сторона (Stakeholder) – физическое лицо, группа лиц, организация или иная структура, имеющая прямые или косвенные интересы (или права) относительно системы (или её свойств)

19. Определение стратегии проверки соответствия. Определение критериев приемки и проверки.

20. Инженерия требований в области решений. Получение системных требований из пользовательских. Область решений

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

В отличии от области проблем, работа инженера по требованиям начинается уже с готового набора требований.

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

(Далее информация взята из книги Элизабет Халл “Разработка и управление требованиями”. Стр. 131 На рис. 6.2 приведен пример универсальной схемы преобразования пользовательских требований в системные.

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

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

21. Разработка архитектурной модели системы.

От требований к системе в целом можно переходить к рассмотрению

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

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

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

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

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

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

Следующий этап определения требований к системе – создание проекта архитектуры системы, как показано во второй части схемы типового процесса на рис. 6.1. Архитектура должна быть представлена в терминах набора элементов, взаимодействующих для создания эмерджентных свойств, определяемых требованиями к системе в целом. Требования, возникающие в процессе проектирования архитектуры (рис. 6.1), определяют требования, которые должны быть выполнены поставщиками каждого элемента системы. Разработка продолжается на более низких уровнях проектирования, всё больше углубляясь в подробности реализации