Chapter 4 – Инженерия требований Lecture 1 1Chapter 4 Requirements engineering. - презентация

1 Chapter 4 – Инженерия требований Lecture 1 1Chapter 4 Requirements engineering

2 Темы презентации Функциональные и нефункциональные требования Документ требования к ПО Спецификация требований Процессы инженерии требований Извлечение и анализ требований Управление требованиями 2Chapter 4 Requirements engineering

3 Инженерия требований Процесс создания услуг, которые клиент требует от системы и ограничений, в рамках которой действует и развивается. Сами требования являются описаниями системных служб и ограничений, которые создаются в процессе инженерии требований. 3Chapter 4 Requirements engineering

4 Что такое требование? Оно может варьироваться от высоко-уровневого абстрактного утверждения сервиса или системного ограничения до детальной математической функциональной спецификации. Это неизбежно, поскольку требования могут выполнять двойную функцию Могут быть основой для заявки на контракт – поэтому должны быть открыты для интерпретации; Могут быть основой для самого контракта - поэтому должны быть определены в деталях; Оба эти утверждения можно назвать требованиями. 4Chapter 4 Requirements engineering

5 Requirements abstraction (Davis) Абстракция требований (Davis) «Если компания хочет контракт на крупный проект по разработке ПО, она должна определить свои потребности в достаточно абстрактной форме, поскольку решение не предопределено. Требования должны быть написаны так, что некоторые подрядчики могут предложить цену для контракта, предлагая, возможно, различные способы удовлетворения потребностей клиента организации. После того, как контракт подписан, подрядчик должен написать определение системы для клиента более подробно, так что клиент понимает и может подтвердить, какое ПО будет делать. Оба этих документа можно назвать документом требования системы ". 5Chapter 4 Requirements engineering

6 Типы требований Пользовательские требования Утверждения на естественном языке плюс диаграммы сервисов, которые предоставляет система и ее операционные ограничения. Пишутся для заказчика. Системные требования Структурированный документ, содержащий подробные описания функций системы, служб и эксплуатационных ограничений. Определяет, что должно осуществляться таким образом, может быть частью договора между клиентом и подрядчиком. 6Chapter 4 Requirements engineering

7 Пользовательские и системные требования 7Chapter 4 Requirements engineering

8 Читатели различных типов спецификации требований 8Chapter 4 Requirements engineering

9 Функциональные и нефункциональные требования Функциональные требования Перечень сервисов, которые должна выполнять система, причем должно быть указано, как реагирует на те или иные входные данные, как ведет себя в определенных ситуациях. В некоторых случаях указывается чего система не должна делать. Нефункциональные требования Описывают характеристики системы и ее окружения, а не поведение системы. Перечень ограничений на действия и функции, выполняемые системой, ограничения на процесс разработки, стандарты и т.д. Часто применяются к системе как к целому, а не к отдельной функции или сервисам. Требования предметной области Constraints on the system from the domain of operation 9Chapter 4 Requirements engineering

10 Функциональные требования Описывают функциональные или системные сервисы Зависят от типа ПО, ожидаемых пользователей и типа системы, в которой используется ПО. Функциональными требованиями пользователей могут быть утверждения на высоком уровне, что система должна делать. Функциональные требования к системе должны описывать системные службы в деталях. 10Chapter 4 Requirements engineering

11 Функциональные требования к MHC-PMS Пользователь должен иметь возможность искать списки назначений для всех клиник. Система должна генерировать каждый день, для каждой клиники, список пациентов, которыем, как ожидается, делают назначения в тот же день. Каждый сотрудник использующий систему должен быть однозначно определен по его или ее 8-значному номеру сотрудника. 11Chapter 4 Requirements engineering

12 Requirements imprecision Требования к неточности Проблемы возникают, когда требования не точно указаны. Неоднозначные требования могут быть по-разному интерпретированы разработчиками и юзерами. Рассмотрим термин 'поиск' в требовании 1 Намерение пользователя - поиск имени пациента во всех назначениях во всех клиниках Интерпретация разработчика - поиск имени пациента в отдельной клинике. Пользователь выбирает клинику затем ищет. 12Chapter 4 Requirements engineering

13 Требования к полноте и согласованности В принципе, требования должны быть как полными так и непротиворечими. Complete – полные Они должны включать в себя описание всех необходимых объектов. Consistent - Согласованные В описаниях объектов системы не должно быть никаких конфликтов или противоречий. На практике невозможно произвести документ с полными и непротиворечивыми требованиями. 13Chapter 4 Requirements engineering

14 Нефункциональные требования Определяют системные свойства и ограничения, например, требования надежности, времени отклика и хранения. Ограничениями являются возможности устройств ввода/вывода, системы представления и тд Требования к процессу могут также указать обязательные конкретные IDE, язык программирования или метод разработки. Нефункциональные требования могут быть более важными, чем функциональные. При их невыполнении система может оказаться бесполезной. 14Chapter 4 Requirements engineering

15 Типы нефункциональных требований 15Chapter 4 Requirements engineering

16 Non-functional requirements implementation Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. It may also generate requirements that restrict existing requirements. 16Chapter 4 Requirements engineering

17 Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. 17Chapter 4 Requirements engineering

18 Examples of nonfunctional requirements in the MHC-PMS Product requirement The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the MHC-PMS system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan priv. 18Chapter 4 Requirements engineering

19 Цели и требования Игногда нефункциональные требования очень трудно указать точно и их трудно проверить. Цель Общее намерение пользователя, такие как простота использования. Проверяемость нефункциональных требований Утверждение использующее некоторые меры, которые могут быть объективно проверены. Цели могут быть полезными для разработчиков, поскольку они передают намерения юзеров системы. 19Chapter 4 Requirements engineering

20 Требования к Юзабилити Система должна быть проста в использовании медицинским персоналом и должны быть организованы таким образом, что пользовательские ошибки сводятся к минимуму. (Цель) Медицинский персонал должен быть в состоянии использовать все системные функции после четырех часов обучения. После этого тренинга, среднее количество ошибок, допущенных опытными пользователями не должно превышать двух за час использования системы. (Тестируемые нефункциональные требования) 20Chapter 4 Requirements engineering

21 Метрики для указания нефункциональных требований Свойство Измерение Speed Скорость Обработанные транзакции / сек Пользователь / Время отклика события Время обновления экрана Size Размер Мбайты Количество микросхем ROM Ease of use Простота использования Тренировочное время Количество кадров справки Reliability Надежность Среднее время до отказа Вероятность отсутствия Частота возникновения неисправности Доступность Robustness Робастность Время перезапуска после сбоя Процент событий, вызывающих сбой Вероятность повреждения данных при сбоях Portability Переносимость Процент целевых зависимых заявлений Количество целевых систем 21Chapter 4 Requirements engineering

22 Доменные требования Системный операционный домен накладывает требования к системе. Например, система управления движением поездов должна учитывать тормозные характеристики в различных погодных условиях. Доменные требования быть новыми функциональны- ми требованиями, ограничения в отношении существующих требований или определят конкретные вычисления. Если требования домена не удовлетворены, то система может быть неработоспособной. 22Chapter 4 Requirements engineering

23 Система защиты поездов Это требование домена для системы защиты поезда: Замедление поезда должно быть вычислено как: Dtrain = Dcontrol + Dgradient где Dgradient есть 9.81ms2 * компенсированный gradient/alpha и где значения 9.81ms2/alpha известны различные типы поезда. Неспециалисту трудно понять последствия этого и как это взаимодействует с другими требованиями. 23Chapter 4 Requirements engineering

24 Проблемы Доменных требований Понятность Требования выражаются на языке предметной области; Они часто не понимаются программными инженерами, разрабатывающими систему. Неявность Специалисты предметной области понимают область настолько хорошо, что они не думают делать требования явными. 24Chapter 4 Requirements engineering

25 Ключевые моменты Требования к программной системе устанавливают, что система должна делать, и определяют ограничения на ее эксплуатацию и реализацию. Функциональные требования это утверждения услуг, которые система должна обеспечивать или являются описанием того, как должны выполняться некоторые вычисления. Нефункциональные требования часто ограничивают разрабатываемую систему и процесс разработки. Они часто связаны с возникающие свойства системы и, следовательно, применимы к системе в целом. 25Chapter 4 Requirements engineering