На этапе формирования требований, прежде всего, необходимо определить область действия разрабатываемой системы и получить точное представление о желаемых возможностях системы.
Основой разработки требований является модель системных прецедентов, отражающая выполнение конкретных обязанностей внутренними и внешними исполнителями с использованием ИС.
Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания прецедентов, содержащие определения используемых данных и точную последовательность их выполнения. Описание осуществляется в соответствии с принятым в организации шаблоном, который обычно включает следующие разделы:
- заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);
- краткое описание прецедента;
- ограничения;
- предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);
- постусловия (возможные состояния системы после выполнения прецедента);
- предположения;
- основная последовательность действий;
- альтернативные последовательности действий и условия, их инициирующие;
- точки расширения и включения прецедентов.
В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в таблица 12.1.
Основы разработки требований к ПО. Разбор книги Карла Вигерса. Главы 1 и 2
| Элементы бизнес-модели | Элементы модели системных прецедентов |
| Бизнес-прецеденты | Подсистемы |
| Внешние исполнители | Исполнители |
| Внутренние исполнители | Исполнители или прецеденты |
| Процессы, выполняемые внутренними исполнителями | Прецеденты |
На рис. 12.9 представлена модель системных прецедентов для бизнес-прецедента Оказание медицинской помощи. Исходя из цели создания системы, в модели системных прецедентовотражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением клинических записей.
Рис. 12.9. Модель системных прецедентов
Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС.
Внутренний исполнитель Персонал центра (см. рис. 12.4, рис. 12.7) и выполняемый им ручной процесс преобразован в системный прецедент Предоставление доступа к клиническим записям.
Качества хороших требований к разработке программного обеспечения
Внешние исполнители (например, Производитель медицинского оборудования) непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей.
В модели отражены два специальных типа связи между прецедентами (на рис. 12.9 соответствующие прецеденты выделены тенью):
- включает — один прецедент в процессе своего исполнения обязательно выполняет некий блок действий, составляющих другой прецедент;
- расширяет — когда прецеденты подобны по своим действиям, но один несет несколько большую функциональную нагрузку.
Прецедент Проверка прав доступа впервые появился на диаграммах и реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение (рис. 12.10). В результате в проектируемой ИС появляются два новых объекта – программный модуль Менеджер защиты и информационный блок Набор прав.
Рис. 12.10. Диаграмма последовательностей для прецедента Проверка прав
Таким образом, результатом разработки модели системных прецедентов является не только исчерпывающий перечень функций, которые должны быть реализованы в проектируемой системе, но и подробное описание необходимой реализации этих функций.
^
Анализ требований и предварительное проектирование системы.
Основные задачи этапа:
- определить проект системы, который будет отвечать всем бизнес-требованиям;
- разработать общий предварительный проект для всех команд разработчиков (проектировщиков баз данных, разработчиков приложений, системных архитекторов и пр.)
Основным инструментом на данном этапе являются диаграммы классов системы, которые строятся на основе разработанной модели системных прецедентов. Одновременно на этом этапе уточняются диаграммы последовательностей выполнения отдельных прецедентов, что приводит к изменениям в составе объектов и диаграммах классов. Это естественное отражение средствами UML итеративного процесса разработки системы.
Диаграммы классов системы заполняются объектами из модели системных прецедентов. Они содержат описание этих объектов в виде классов и описание взаимодействия между классами.
Диаграмма классов, описывающая процедуры защиты доступа к данным, приведена на рис. 12.11.
Рис. 12.11. Диаграмма классов Защита доступа
Таким образом, в результате этого этапа проектирования появляется достаточно подробное описание состава и функций проектируемой системы, а также информации, которую необходимо использовать в базе данных и в приложениях.
Поскольку диаграммы классов строятся на основе разработанных ранее бизнес-моделей, появляется уверенность в том, что разрабатываемая система будет действительно удовлетворять исходным требованиям заказчика.
В то же время, благодаря своему синтаксису, диаграммы классов оказываются хорошим средством структурирования и представления требований к функциональности, интерфейсам и данным для элементов проектируемой системы.
Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.
Источник: it-iatu.ru
5.2. Процесс разработки требований
Чаще всего проблемами, с которыми встретились не достигшие своих целей проекты программных продуктов, являются: недостаток информации от пользователя или заказчика о функциях проекта, неполные, некорректные требования, а также многочисленные изменения требований и спецификаций. Это происходит потому, что зачастую разработчики и заказчики считают, что «даже если мы не очень точно знаем, чего хотим достичь, лучше быстрее приступить к реализации проекта, так как мы и так выбились из графика и нам некогда размышлять. Мы можем уточнить требования позднее». Подобный подход приводит к хаотическим, неупорядоченным действиям при разработке ПС, когда никто не знает, что на самом деле хочет заказчик и пользователь и как в действительности функционирует созданная на данный момент система и/или программный продукт.
Формализация и управление требованиями — это систематический метод выявления, организации и документирования требований к системе и/или ПС а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющими проект специалистами, в условиях меняющихся требований к системе
Разработка требований — это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований.
Различают четыре основных этапа процесса разработки требований:
- анализ технической осуществимости создания системы;
- формирование и анализ требований;
- специфицирование требований и создание соответствующей документации;
- аттестация требований.
На рис. 5.1 показаны взаимосвязи между этими этапами и документы, сопровождающие каждый этап процесса разработки системных требований. Рис. 5.1. Процесс разработки требований
5.3. Составляющие потока анализа требований.
- Результатами анализа и разработки требований могут быть:
- Техническое задание;
- Технические требования;
- Общие технические решения;
- Задание на проектирование;
- Подготовка конкурсной документации.
Источник: studfile.net
Требования к ПО — презентация
3 Технология разработки ПО Требования – это условия или возможности, необходимые пользователю для решения проблем или достижения целей; условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; документированное представление условий или возможностей для пунктов 1 и 2.
Изображение слайда
Слайд 4: Цитата
4 Технология разработки ПО Цитата «Если вы не поймёте требования к программному продукту правильно, то не имеет значения, как хорошо вы сделаете всё остальное» [ Карл Вигерс, 2004 ]
Изображение слайда
Слайд 5: Проблемы разработки требований
5 Технология разработки ПО Проблемы разработки требований
Изображение слайда
Слайд 6: Основной закон:
6 Технология разработки ПО Основной закон: Требования должны быть документированы
Изображение слайда
Слайд 7: Уровни требований
7 Технология разработки ПО Уровни требований
Изображение слайда
Слайд 8: Функциональные и нефункциональные требования
8 Технология разработки ПО Функциональные и нефункциональные требования функциональные требования задают ЧТО система должна делать нефункциональные требования задают с соблюдением каких условий система должна функционировать
Изображение слайда
Слайд 9: Бизнес-требования
9 Технология разработки ПО Бизнес-требования определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения
Изображение слайда
Слайд 10: Пользовательские требования
10 Технология разработки ПО Пользовательские требования Описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы Отвечают на вопросы: КТО работает и ЧТО делает с системой (с помощью системы)
Изображение слайда
Слайд 11: Формальные функциональные требования
11 Технология разработки ПО Формальные функциональные требования Определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований
Изображение слайда
Слайд 12: Нефункциональные требования — 1
12 Технология разработки ПО Нефункциональные требования — 1 Бизнес-правила включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, алгоритмами вычислений и т.д. Пример: «На Курс не может быть зарегистрировано больше Студентов, чем указал Преподаватель» Атрибуты качества описывают дополнительные характеристики продукта Пример: «Среднее время отклика системы должно составлять не более 2 секунд»
Изображение слайда
Слайд 13
13 Технология разработки ПО Внешние интерфейсы Аспекты взаимодействия с другими системами, операционной средой, а также пользовательский интерфейс Ограничения формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации Пример: «Программа должна работать в системе с 512 КБ оперативной памяти» Нефункциональные требования — 2
Изображение слайда
Слайд 14: Примеры требований
14 Технология разработки ПО Примеры требований Для формируемых вручную счетов система должна позволять оператору вводить с консоли любой номер счета, проверяя при этом уникальность вводимого номера Время обучения работе с программой сотрудника с квалификацией опытный пользователь ПК не должно быть более 16 часов Постановка единичного ордера должна занимать не более 40 миллисекунд
Изображение слайда
Слайд 15: Характеристики хороших требований
15 Технология разработки ПО Характеристики хороших требований Полнота Корректность Осуществимость Необходимость Однозначность Проверяемость
Изображение слайда
Слайд 16: Структура требований продукта
16 Технология разработки ПО Требования имеет смысл группировать в иерархическую структуру Каждому требованию должен быть назначен приоритет Структура требований продукта
Изображение слайда
Слайд 17: Спецификация требований
17 Технология разработки ПО Спецификация требований Спецификация требований к ПО это полное описание поведения разрабатываемой системы. Она включает варианты использования, которые описывают взаимодействие с пользователем. Так же спецификация содержит нефункциональные требования которые отражают ограничения дизайна или имплементации. Спецификация требований к ПО содержит Перечень функций и возможностей Перечень ограничений Нефункциональные требования
Изображение слайда
Слайд 18: Структура спецификации
18 Технология разработки ПО Структура спецификации Стандарт IEEE 830-1998 1..Введение 1.1 Назначение 1.2 Область действия 1.3 Определения, акронимы и сокращения 1.4 Публикации 1.5 Краткий обзор 2. Полное описание 2.1 Перспектива изделия 2.2 Функции изделия 2.3 Характеристики пользователя 2.4 Ограничения 2.5 Допущения и зависимости 3. Специфические требования
Изображение слайда
Слайд 19: Фрагмент спецификации требований
19 Технология разработки ПО Фрагмент спецификации требований 1. Пользователь должен иметь возможность генерации отчёта в формате html и сохранения его на файловую систему. 1.1. Пользователь должен иметь возможность запуск генерации отчёта из пользовательского интерфейса клиентской системы. 1.2. Пользователь должен иметь возможность указать следующие параметры генерации отчёта.
1.2.1. 1.3. Пользователь должен иметь возможность указать выходной файл отчёта 1.3.1. Система должна выдавать сообщение если одноимённый файл уже существует. 1.3.2. …
Изображение слайда
Слайд 20: Как писать хорошие требования
20 Технология разработки ПО Как писать хорошие требования Пишите простыми словами Используйте полные предложения с правильной грамматикой, правописанием и пунктуацией Используйте краткие и ясные короткие предложения Избегайте двусмысленных и субъективных терминов Избегайте синонимов
Изображение слайда
Слайд 21: Шаблоны требований
21 Технология разработки ПО Шаблоны требований Функциональные требования должен иметь возможность должна Функциональные требования с ограничениями и условиями < Тип пользователя>должен иметь возможность , находясь в должна в случае < описание условия >Нефункциональные требования должна обладать Ограничения должна соблюдать
Изображение слайда
Слайд 22: Способы выявления требований
22 Технология разработки ПО Способы выявления требований Интервьюирование и анкетирование Мозговой штурм и отбор идей Обыгрывание ролей Создание прототипов
Изображение слайда
Слайд 23: Управление требованиями
23 Технология разработки ПО Управление требованиями Требования изменяются – такова жизнь Все изменения должны быть задокументированы и согласованы План и сроки должны быть пересмотрены Во все артефакты, на которые влияют изменения требований, должны быть внесены соответствующие изменения
Изображение слайда
Слайд 24: UML диаграммы вариантов использования
24 Технология разработки ПО UML диаграммы вариантов использования
Изображение слайда
Слайд 25: Сценарии вариантов использования
25 Технология разработки ПО Сценарии вариантов использования Пример: Сценарий генерации отчёта 1.Пользователь инициирует запуск отчёта 2. Пользователь указывает параметры отчёта 3. Пользователь указывает файл отчёта
Изображение слайда
Последний слайд презентации: Требования к ПО: Что следует запомнить
26 Технология разработки ПО Что следует запомнить Без хорошей проработки требований вся последующая разработка может пойти насмарку Функциональные требования описывают, что должна делать программная система Нефункциональные требования описывают характеристики и ограничения системы Диаграммы вариантов использования моделируют пользовательские требования
Источник: slide-share.ru