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

●Движущая сила. Фактор, которым можно пренебречь.

Например, если мы установим ограничения на функции — это означает, что мы должны реализовать все функции для сдачи проекта заказчику. Чем мы тогда можем пренебречь, если не успеваем к сроку? Если для сроков мы установили степень свободы, то мы можем пренебречь сроками, если на сроки мы тоже

установили ограничения, то можем пренебречь качеством функций. Чем различаются бизнес-требования и требования пользователей?

Бизнес-требования для успешности ПП, требования пользователя — для каких каких задач будет использовать этот ПП пользователем (их рабочие места).

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

Чем различаются функциональные и нефункциональные требования?

Нефункциональные требования определяют качество.

Лекция 2. Методы выявления требований к ПО

2.1.Сбор требований пользователей

●Определение групп пользователей. Уже формируется в концепции либо формируется на основе списка функций.

●Выбор типичных представителей групп пользователей.

●Опрос типичных представителей пользователей (интервью, анкеты). Интервью дает больше ответов, так как не статична, в отличии от анкеты.

●Наблюдение за пользователями на рабочих местах.

●Проведение совместных семинаров. Трудоемкий, но эффективный.

●Создание перечня задач для каждой группы пользователей.

●Определение системных событий и реакции на них.

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

●CRC-карточки.

●Анализ проблем работающего ПО. Уже на основе запущенного ПП.

●Создание прототипа (макетирование). Создание частичного функционала ПО и соответственно демонстрации этого прототипа пользователю, а он на основе этого выскажет мнение о ПО, то ли хотел пользователь.

2.2.Определение классов пользователей

Группировка пользователей:

●по привилегиям доступа и уровню безопасности,

●по задачам, решаемым пользователями,

●по используемым функциям,

●по частоте использования продукта,

●по опыту работы в предметной области или с компьютерной системой,

●по используемой платформе,

●по языку.

2.3. Характеристики классов пользователей

●Название класса пользователей.

●Привилегированный и непривилегированный. Непривилегированный - нежелательный пользователь, например примеру, хакер.

●Численность пользователей. Помогает расставить приоритеты для функций.

●Описание типичного представителя класса пользователей:

— поведение,

— выполняемые операции, решаемые задачи,

— квалификация в предметной области,

— опыт и навыки работы с информационной системой,

—предпочтения. Оказывает влияние на нефункциональные требования,

—раздражающие факторы. Оказывает влияние на нефункциональные требования.

2.4. Представление системных событий и реакции на них

CRC: Class — Responsibility — Collaboration (Класс — обязанность — взаимодействие)

Основное внимание в этом методе уделяется внешнему поведению объекта. Классы должны реагировать адекватно.

Итог: выявление ошибочных или отсутствующих требований.

2.5.1. Пример CRC-карточки

2.6. Прототипы (макеты) ПО

Делает для того, чтобы программисты правильно все поняли.

●Задачи:

—уточнение формулировки требования,

—исследование альтернативных решений,

—создание готового программного продукта.

●Варианты прототипов:

—горизонтальные (интерфейсы пользователя),

—вертикальные (структура ПО, временнЫе характеристики, алгоритмы, структура БД).

Прототипы одноразовые и эволюционные.

2.7. Представление требований пользователя на основе варианта использования

●Идентификатор;

●Имя (глагол+объект);

●Источник (автор);

●Дата создания;

●Основное действующее лицо;

●Дополнительно действующее лицо;

●Триггер (действие, инициирующее вариант использования);

●Предварительные условия (начальное состояние);

●Выходные условия;

●Нормальное и альтернативное направление варианта использования;

●Исключения;

●Приоритет;

●Частота использования;

●Бизнес-правила;

●Специальные требования (Другая информация);

●Предположения.

2.8. Процессы обработки данных варианта использования

Этим занимается системный аналитик.

Составить список функциональных требований должен быть параллельно продублирован со списком тестов. Сколько функц. требований столько (как минимум) и тестов.

Составить предварительный список моделей анализа. Анализируются данные и алгоритмы (как минимум), будут представлены в виде диаграмм.

Составить словарь данных. Термины предметной области должны быть понятны программистам.

В результате будет сформулирован список функциональных требований.

2.9. Нефункциональные требования

нефункциональные = эксплуатационные (качественные). С точки зрения ПП. Каждое требование также имеется детализация.

●функциональная пригодность (functional suitability),

●уровень производительности (performance efficiency),

●аппаратная и программная совместимость (compatibility),

●удобство использования, практичность (usability),

●надежность (reliability),

●защищенность (security),

●сопровождаемость (maintainability),

●переносимость (portability).

ГОСТ Р ИСО/МЭК 25010-2015 Требования и оценка качества систем

ипрограммного обеспечения (SQuaRE). Модели качества систем и программных продуктов.

2.10. Уточнение нефункциональных требований

Детализация требования “удобство использования (практичность)”:

●определимость пригодности, то есть ПП должен удовлетворять представлениям пользователям о том, что он может с ним делать,

●изучаемость, то есть легкость изучения ПП (легкость вхождения),

●управляемость, то есть что-то можно изменить в ПП,

●защита от ошибки пользователя,

●эстетика пользовательского интерфейса - дело субъективное,

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

2.11.Стандарты практичности (usability)

Common User Access (CUA) — IBM.

Команды меню, требующие уточнения параметров выполняемого действия, заканчиваются многоточием («...»).

В программах есть встроенная справочная система, вызываемая из меню «Справка», расположенного в конце строки меню; контекстно-зависимая справка может вызываться клавишей F1.

Первое меню должно называться «Файл» и должно содержать операции по работе с файлами (создать, открыть, сохранить, сохранить как) и команду выхода.

Следующее меню «Правка» содержит команды отмены, повтора, вырезания, копирования, вставки и удаления.

Команда «вырезать» выполняется нажатием Shift+Del,

«копировать» — Ctrl+Ins, а «вставить» — Shift+Ins.

2.12.Бизнес-правила

Типы бизнес-правил:

●факты,

●ограничения,

●активаторы операций,

●выводы,

●вычисления.

Источники бизнес-правил:

●законы государства,

●корпоративная политика,

●стандарты и нормативные документы,

●формулы,

●модели данных.

2.12.1.Примеры бизнес-правил

●Факт:

— Каждый товар должен иметь штрих-код.

●Ограничение:

— Доставка всех заказов должна выполняться между 10:00 и 14:00

по местному времени.

●Активатор операции:

—После добавления покупателем товара в корзину предложить ему

приобрести сопутствующие товары.

●Вывод:

—Если товар данного вида на складе отсутствует, присвоить данному товару статус «нет в наличии».

●Вычисления:

— Цена единицы товара снижается на 10 % при заказе более 6 единиц данного товара.

Лекция 3. Анализ и моделирование требований к ПО

3.1.Атрибуты качества требований

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

●Необходимость (обоснованность). Показывает, что требование может выйти за границы нашего ПП, нашей концепции.

●Осуществимость. Нужно реально оценивать реализацию требования.

●Корректность (в плане написания слов, например, нельзя «Защита от дурака»).

●Однозначность толкования. Не должно быть двусмысленности.

●Непротиворечивость.

●Проверяемость (требования должны быть проверяемы).

●Приоритет. На основе приоритета будут выпускаться версии, выставляется приоритеты экспертами. Чем выше приоритет, тем первее реализация в версии.

●Статус.

3.2.Статус требования

Порядок такой, 5 вариант используется не обязательно:

1.Предложено

2.Одобрено или отклонено (если отклонено, то удаляется, дальше не продолжается цепочка)

3.Реализовано

4.Проверено

5.Удалено (опционально)

3.3. Полный набор требований ПО

Минимальные группы требований для ПО:

●Вводы системы

●Выводы системы