Добавил:
СПбГУТ * ИКСС * Программная инженерия Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Письменные лекции по дисциплине «Разработка и анализ требований»

.pdf
Скачиваний:
195
Добавлен:
29.01.2021
Размер:
3.52 Mб
Скачать

Функции системы

Атрибуты системы

Атрибуты системного окружения (используются диаграммы: контекстная и Use Case)

Не включаются в полный набор требований ПО:

Календарные планы

Выделенные средства

Тесты

3.4.Представление вводов и выводов ПО

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

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

3.5. Полнота нефункциональных требований

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

Нормируем в виде требования время, которое пользователь будет тратить на получение ответа.

Пример: время ответа для 90% транзакций будет составлять менее 3 секунд.

3.6. Пример трассировки требований.

Обоснованность: связь высокоуровневых функций и функциональных требований.

Концепция:

8. Система «Абитуриент» должна предоставлять ежедневную сводку о результатах приема документов от абитуриентов.

Функциональные требования:

SR8.1. Система получает данные о количестве принятых документов из базы данных текущего года на текущую дату.

SR8.2. Система использует для сравнения данные сводки на последний день приема из базы данных прошлого года.

SR8.3. Система рисует график в системе координат, ось х которого

— ось времени, где каждая точка — очередная дата, ось y — количество поданных заявлений. SR8.4 Диапазон значений по оси x определяется сроком приема документов (Бизнес-правило __), диапазон значений по оси y — от 0 до максимального значения количества принятых документов за предыдущий год*1,2.

SR8.5. Каждая точка графика представляет собой количество документов, принятых от начала приема документов до конкретной даты.

SR8.6. В одних осях строятся два графика: на текущий год от начала приема до текущей даты и предыдущий год на весь период приема документов.

3.6.1. Дочерние требования

SR8.1. Система получает данные о количестве принятых документов из базы данных текущего года на текущую дату.

SR8.2. Система использует для сравнения данные сводки на последний день приема из базы данных прошлого года.

SR8.3. Система рисует график зависимости количества принятых документов за период от даты начала приема документов.

SR8.31. Ось х представляет собой ось времени, где каждая точка — очередная дата, ось y — количество поданных заявлений.

SR8.32. Диапазон значений по оси x определяется сроком приема документов (Бизнес-правило __), диапазон значений по оси y — от 0 до максимального значения количества принятых документов за предыдущий год*1,2.

SR8.33. Каждая точка графика представляет собой количество документов, принятых от начала приема документов до конкретной даты.

SR8.34. В одних осях строятся два графика: на текущий год от начала приема до текущей даты и предыдущий год на весь период приема документов.

Трассировка - если мы берем каждое требование, например, из списка выше, на первом или на уровне втором и мы всегда находим родительское требование и можем подняться до уровня концепции (уровень основного требования).

Требование будет принято, если оно трассируется к основному требованию - это значит, что это требование не выходит за границы нашего требования (основного).

3.7. Дерево требований

3.8. Обоснованность требований: матрица зависимости требований

Конфликтов не должно быть. Пустая клетка — не зависят друг от друга, никаких изменений вводить не нужно. Требования с перекрытием необходимо переформулировать или удалить.

3.9. Корректность и непротиворечивость

Пример:

все служащие старше 65 лет в конце календарного года должны получить премию в размере 10000 рублей;

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

Какую премию должен получить сотрудник 65 лет, имеющий стаж работы 15 лет?

Тут происходит некорректность и неоднозначность.

3.10. Проверяемость требований Требование: система должна быть простой в эксплуатации для

опытного пользователя и сводить к минимуму количество ошибок. Проверяемое требование: опытному оператору должны быть

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

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

Система должна отвечать на произвольный запрос в течение 500 миллисекунд;

Цифры на экране, показывающем время, должны хорошо выглядеть;

Система должна быть дружественной пользователю;

Система должна экспортировать данные для просмотра в формате, в котором в качестве разделителя используется запятая.

3.10.1.Оценки разработчиков возможности проверки

требований

Система должна отвечать на произвольный запрос в течение 500

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

Цифры на экране, показывающем время, должны хорошо выглядеть. Красота — дело вкуса, проверить нельзя;

Система должна быть дружественной пользователю. Требование неконкретно, в таком виде непроверяемо;

Система должна экспортировать данные для просмотра в формате, в котором в качестве разделителя используется запятая.

Надо уточнить некоторые детали, например, что будет, если данные представляют пустое множество, в этом случае требование проверяемо.

3.11.Определение приоритетов

Необходимо устанавливать для того, чтобы оптимальным образом планировать выпуски ПО. Приоритеты требования устанавливаются экспертами. Самая простая методика:

Методика MoSCoW

Обязательные для выполнения (Must).

Должны быть сделаны (Should).

Могут быть сделаны (Could).

Не нужны (Won't).

Методика определения по срочности и важности

-----------------------------------------------------------------------------------

Важные Неважные

------------------------------------------------------------------------------------

Срочные

Высокий приоритет

Не занимайтесь им!

Не срочные

Средний приоритет

Низкий приоритет

3.12. Определение приоритета по полезности (ценности) функции

Методика вычисления относительной полезности функции для пользователя Quality Function Deployment (QFD).

Оценки выгоды, урона, стоимости, риска — от 1 (минимально) до 9 (максимально)

Приоритет = % ценности / (%стоимости * вес_стоимости + %риска * вес_риска).

Лекция 4. Средства анализа требований к ПО. Основы UML 4.1. Стандарты языка UML

Язык UML — Unified Modeling Language.

Авторы: Гради Буч, Джеймс Румбо, Айвар Якобсон.

UML 2.4.1 (2011) принят в качестве международного стандарта

ISO/IEC 19505-1, 19505-2:2012.

Спецификации UML:

1.3 (1999 год)

1.4 (2001 год)

1.5 (2003 год)

2.0 (2005 год)

2.5 (март 2015 года)

2.5.1 (декабрь 2017)

UML движется в сторону упрощения. Официальный сайт: www.omg.org

4.2.Назначение и элементы UML

Используется для анализа, проектирования, документирования ПО.

Модели UML могут быть переведены на языки программирования

(C++, Java, Visual Basic, и др.).

Элементы UML:

диаграммы,

предметы (диаграммы строятся из предметов — сущностей; различают структурные [например, класс/компонент] и предметы поведения [например, действие]),

отношения (схематическая связь между объектами).

4.3.Диаграммы UML (UML 2.5)

Структурные диаграммы (не меняются в процессе эксплуатации): Диаграмма классов.

Диаграмма компонентов (компонент — любой файл; например, файл с исходным кодом, исполняемый файл, файл с данными).

Диаграмма пакетов (например, с точки зрения Java, пакет — директория, которая хранит другие директории и java-файлы).

Диаграмма профилей (связано с пользователями).

Диаграмма объектов (отражает набор объектов и их взаимодействий).

Диаграмма композитной структуры (тоже показывает взаимодействия сущностей программного продукта).

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

Диаграмма прецедентов (отображает основные функции ПО).

Диаграмма деятельности (отображает процесс исполнения сценария варианта использования).

Диаграмма состояний (иллюстрация объекта, который имеет ограниченное число состояний; конечный автомат).

Диаграммы взаимодействия (относятся к диаграммам поведения):

Диаграмма последовательности.

Диаграмма коммуникаций.

Диаграмма обзора взаимодействия.

Диаграмма синхронизации.

4.4.Структурные диаграммы (Structure Diagrams)

Class diagram — диаграмма классов.

Component diagram — диаграмма компонентов.

Composite structure diagram — диаграмма композитной/составной структуры.

Collaboration (UML 2.0) — диаграмма кооперации.

Deployment diagram — диаграмма развертывания.

Object diagram — диаграмма объектов.

Package diagram — диаграмма пакетов.

Profile diagram (UML 2.2) — диаграмма профилей.

4.5.Диаграммы поведения (Behavior Diagrams)

Activity diagram — диаграмма деятельности.

State Machine diagram — диаграмма состояний.

Use case diagram — диаграмма прецедентов.

4.6.Диаграммы взаимодействия (Interaction Diagrams)

Communication diagram (UML2.0) / Collaboration (UML 1.x).

Диаграмма коммуникации (UML 2.0) / диаграмма кооперации (UML

1.x).

Interaction overview diagram (UML 2.0) — диаграмма обзора взаимодействия.

Sequence diagram — диаграмма последовательности. Timing diagram (UML 2.0) — диаграмма синхронизации.

4.7.Структурные предметы UML

Класс (помимо приведенных трех частей, может быть четвертая с примечаниями; + — public доступ, - — private доступ, # — protected

доступ)

Объект (паскалевская нотация)

Кооперация (сотрудничество)