Системная инженерия Евгений Александрович Мирошниченко к т н

Системная инженерия Евгений Александрович Мирошниченко к. т. н. , доцент кафедры вычислительной техники Института кибернетики 401 ауд. 10 к. © Томский политехнический университет, 2015

Инженерия требований (Requirements Engineering) Инженерия требований — междисциплинарный подход, который связывает стороны поставщика и заказчика для определения и поддержки требований, которым должна отвечать целевая система, продукт или услуга. ISO/IEC/IEEE 29148 -2011 Systems and software engineering — Life cycle processes — Requirements engineering Требование — утверждение, которое передаёт или выражает некоторую потребность и связанные с ней ограничения и условия. ISO/IEC/IEEE 29148 -2011 Systems and software engineering — Life cycle processes — Requirements engineering

Классификация требований • Функциональные требования описывают функции и задачи системы или элементов системы. • Требования к производительности. Количественные требования к производительности. • Интерфейсные требования. Требования к интерфейсу определяют, как система должна взаимодействовать с внешними системами (внешний интерфейс) или, как элементы системы (в том числе и человеческие элементы), взаимодействуют друг с другом (внутренний интерфейс). • Проектные ограничения. Требования, которые ограничивают набор возможностей, открытых перед проектировщиком системы (например, система должна включать наследование определённых элементов системы). • Требования к процессу включают: соблюдения национальных, государственных или местных законов, в том числе природоохранного законодательства; административные требования; требования к взаимоотношениям заказчика и поставщика; конкретные директивы работы и т. д. • Нефункциональные. Определяют то, в каких условиях система будет существовать или функционировать. Сюда входят, например, требования к надёжности, сопровождаемости/ремонтопригодности, или требования к пользовательскому интерфейсу.

Примеры атрибуции требований • Идентификация. Уникальный идентификатор (например, номер, имя, мнемоника). • Приоритеты для стейкхолдеров. Для идентификации приоритета каждого требования, могут быть использованы шкала (например, от 1 до 5) или простая схема (например, High, Medium или Low). • Зависимости. Спецификация зависимостей между требованиями. • Риск. Методы анализа рисков могут быть использованы для определения ранжирования требований с точки зрения их последствий или степени предотвращения риска. • Источник. • Обоснование. • Сложность. Предполагаемая сложность реализации. • Тип.

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

Управление требованиями — процесс, включающий • идентификацию требований, • документирование требований, • анализ требований, • отслеживание требований, • приоритезацию требований, • достижение соглашения по требованиям, • управление изменениями.

Системы управления требованиями • • • Visual Studio Team Foundation Server Borland Caliber. RM IBM Rational Requisite. Pro Open Source Requirements Management Tool Requirements Management for Eclipse Telelogic's DOORS Top. Team Analyst GATHERSPACE workspace. com Case Complete и т. д. Списки • http: //www. volere. co. uk/tools. htm • http: //www. software-pointers. com/en-requirements-tools. html

Инженерия методов «Essence: Kernel and Language for Software Engineering Methods» ( «Основы: ядро и язык методов программной инженерии» ) — стандарт OMG 2014 г. , созданный SEMAT OMG (Object Management Group): консорциум по стандартам в компьютерной индустрии, основан в 1989 г. SEMAT (Software Engineering Method and Theory): консорциум по унификации теории программной инженерии, основан в 2009 г.

Метод • Альфы (Alphas) — ключевые понятия (essential things to work with). • Типовые деятельности (Activity Spaces) — ключевые типы деятельности (essential things to do). • Компетенции (Competencies) — ключевые способности (the abilities needed). • Рабочие продукты (Work products) Alpha: ключевой элемент, с помощью оценки состояния которого можно оценить прогресс и успешность проекта. An essential element of the endeavor that is relevant to an assessment of the progress and health of the endeavor. Alpha is an acronym for an Abstract-Level Progress Health Attribute. Типовая деятельность: Заготовка (placeholder) для типовой деятельности в проекте. Называет, что должно делаться, но не предписывает как именно. A placeholder for something to be done in the software engineering endeavor. A placeholder may consist of zero to many activities. Компетенция: Характеристика представителя стейкхолдера или члена команды с точки зрения способности к определённой работе. A characteristic of a stakeholder or team member that reflects the ability to do work.

Альфы

Типовые деятельности

Компетенции

Стейкхолдеры: состояния

Возможности: состояния

Требования: состояния

Команда: состояния

Работа: состояния

Технология работы: состояния

State Checklist Recognized q All the different groups of stakeholders that are, or will be, affected by the development and operation of the software system are identified. Стейкхолдеры q There is agreement on the stakeholder groups to be represented. At a minimum, the stakeholders groups that fund, use, support, and maintain the system have been considered. q The responsibilities of the stakeholder representatives have been defined. Represente d q q Involved q The stakeholder representatives assist the team in accordance with their responsibilities. q The stakeholder representatives provide feedback and take part in decision making in a timely manner. q The stakeholder representatives promptly communicate changes that are relevant for their stakeholder groups. In Agreement q The stakeholder representatives have agreed upon their minimal expectations for the next deployment of the new system. q The stakeholder representatives are happy with their involvement in the work. q The stakeholder representatives agree that their input is valued by the team and treated with respect. q The team members agree that their input is valued by the stakeholder representatives and treated with respect. q The stakeholder representatives agree with how their different priorities and perspectives are being balanced to provide a clear direction for the team. Satisfied for Deployment q The stakeholder representatives provide feedback on the system from their stakeholder group perspective. q The stakeholder representatives confirm that the system is ready for deployment. Satisfied in Use q Stakeholders are using the new system and providing feedback on their experiences. q The stakeholders confirm that the new system meets their expectations. The stakeholder representatives have agreed to take on their responsibilities. The stakeholder representatives are authorized to carry out their responsibilities. The collaboration approach among the stakeholder representatives has been agreed. The stakeholder representatives support and respect the team's way of working.

Пример описания метода