Введение в инженерию программного обеспечения Модуль 2: программные требования
Содержание • • Основы программных требований Процесс работы с требованиями Извлечение требований Анализ требований Спецификация требований Проверка требований Практические соображения 2
3
Определение программных требований Программные требования – это свойства, которые должны быть надлежащим образом представлены для решения конкретных практических задач. Основные процессы управления программными требованиями: • извлечение (сбор) требований • анализ требований • специфицирование требований • утверждение требований. 4
Зачем нужно работать с требованиями? Работа с требованиями позволяет: • Корректно моделировать задачи реального мира • Формулировать приемочные тесты • Добиваться в итоге успешной реализации проекта. 5
Что же такое требование? Понятие требования включает в себя следующие аспекты: • Условие или возможность, требуемые пользователем для решения задач или достижения целей. • Условие или возможность, которыми система (или ее компонент) должна обладать для обеспечения условий контракта, стандартов, спецификаций или других регулирующих документов. • Документальная репрезентация (зафиксированное определение, описание) условий или возможностей, перечисленных в предыдущих пунктах. 6
Требования к продукту и процессу Требования К продукту К процессу Свойства продукта, который надо получить Свойства процесса, с помощью которого разрабатывают продукт Выбор платформы, архитектуры решения 24/7 J 2 EE Модульное тестирование, Junit 7
Функциональные и нефункциональные требования Требования Функциональные Нефункциональные задают “что” система должна делать с соблюдением “каких условий” 8
Классификация требований Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы. Пример: Мы решили заняться предпринимательством – открыть интернет магазин. Соответственно наша потребность – создать сайт для магазина. 9
Классификация требований Группа функциональных требований: • Бизнес-требования – определяют высокоуровневые цели заказчика разрабатываемого ПО. (пр. : интернет-магазин должен обеспечивать объем продаж в $1 000). • Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться при помощи создаваемой программной системы. (пр. : интернетмагазин должен позволять регистрироваться пользователям, совершать покупки, обеспечивать обратную связь). • Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. (пр. : зарегистрироваться, изменить свои личные данные, помещать/удалять товары в корзину) 10
Классификация требований Группа нефункциональных требований: • Бизнес-правила – связаны с корпоративными регламентами, политиками, стандартами, законодательными актами. (пр. : интернет-магазин должен обеспечивать безопасность безналичных расчетов). • Внешние интерфейсы – взаимодействие с другими системами, операционной средой, возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей. (пр. : интернет-магазин должен иметь возможность попасть на площадку Яндекс. маркет). 11
Классификация требований Группа нефункциональных требований: • Атрибуты качества – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков (применимость, надежность, производительность, эксплуатационная пригодность). (пр. : интернет-магазин должен обеспечивать работу со 100 одновременными покупателями). • Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . . . ), которые, в свою очередь, могут относиться, например, к внешним интерфейсам. (пр. : выбор платформы для создания интернет-магазина). 12
Классификация требований Системные требования – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. (пр. : конкретный набор средств для интернет-магазина: БД, движок сайта, сервер). 13
Процесс работы с требованиями характеризуется следующими аспектами: • Непрерывность - постоянно действующий процесс на всех этапах жизненного цикла программного обеспечения. • Участники: • Пользователи – те, кто будет непосредственно использовать программное обеспечение (описывают задачи) • Заказчик - тот, кто отвечает за заказ программного обеспечения (описывают бизнес-требования) • Аналитики - играют роль <квалифицированных> “представителей” потребителей (маркетинг) • Программисты - ответственны за техническую оценку путей решения поставленных задач и последующую реализацию требований заказчиков. • Управление – связь между процессами и деятельностью • Качество – высокое качество работы с требованиями – основа успешного завершения проекта. 14
Извлечение требований - это первая стадия построения видения автоматизируемой проблемной области, которая состоит из следующих ключевых этапов: • Идентификация заинтересованных лиц • Определение способов их взаимодействия • Определение выполняемых ими бизнес-процессов Заказчики Исполнители Требования Продукт 15
Источники требований Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта. Только после этого можно определить их влияние на проект: • Цели • Знания предметной области • Заинтересованные лица • Операционное окружение • Организационная среда Следствия понимания источников требований: • Выделение приоритетов • Однозначность требований, передаваемых инженерам • Связь между требованиями • Их взаимное влияние друг на друга 16
Техники извлечения требований: • Интервьюрирование. Внимание: получение информации от пользователя != получению требований; информация должна быть проанализирована и трансформирована в требования! • Сценарии – ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями. • Прототипы –инструмент для уточнения и/или детализации требований: от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные проекты. • Наблюдение - подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения бизнес-процессов (XP). 17
Анализ требований – это трансформация информации, полученной от пользователей (и других заинтересованных лиц) в четко и однозначно определенные требования, передаваемые инженерам для реализации в программном коде Анализ требований включает: • Обнаружение и разрешение конфликтов между требованиями; • Определение границ задачи, решаемой создаваемым программным обеспечением; • Детализацию системных требований для установления программных требований 18
Этапы анализа требований включают: • Классификация требований : функциональные и нефункциональные, внутренние или внешние зависимости, требования к процессу или продукту, приоритет требований, содержание требований в отношении конкретных подсистем создаваемого программного обеспечения, изменяемость/стабильность требований. • Концептуальное моделирование - разработка модели проблемы реального мира – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы - ”что” надо сделать • Архитектурное проектирование и распределение требований “как” это будет реализовано 19
Спецификация требований Для описания комплексных проектов (в части требований) используется три основных документа (спецификации): • Определение системы – содержит концептуальное определение системы с точки зрения области применения, изложение требований в нем ведется в терминах прикладной области (бизнес-процессы, операционное окружение, организационные и другие регламенты). • Системные требования – ключевой аспект связывания концептуальной модели и практической реализации программы. • Программные требования - устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать. 20
Программные требования В программные требования обычно включают: • процедуры проверки получаемого ПО на соответствие предъявляемым ему требованиям (вплоть до содержания планов тестирования), • характеристики, определяющие качество и методы его оценки, • вопросы безопасности • и многое другое Требования могут быть описаны: • На обычном языке • С использованием полуформальных методов • С использованием формальных методов Задача этой спецификации состоит в том, чтобы программные требования были ясны, связи между ними прозрачны, а содержание данной спецификации не допускало разночтений и интерпретаций. 21
Ошибки составления программных требований Основные ошибки, встречающиеся при специфицировании программных требований: • Терминологическая неопределенность – отсутствие глоссария. • Отсутствие представления о классификации требований – подмена одних категорий другими, смешение требований. • Фокусировка на деталях пользовательского интерфейса – встречается акцентирование не на необходимой функциональности, а на деталях пользовательского интерфейса. • Излишнее акцентирование внимания на деталях реализации. • Слабая формализация бизнес-процессов - перемешивается описание бизнеса и требований к ПО, что приводит сложностям в понимании сути разрабатываемой системы. 22
Проверка требований Принято считать, что требования описаны неполностью, если для них не заданы правила V&V (verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеровтестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям. Правильно создавать продукт Создание правильного продукта 23
Методы проверки требований Основные практики проверки требований: • Обзор требований - требования “вычитывают” в поисках необоснованных предположений, описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т. п. • Прототипирование - подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований (пример структуры сайта, реализация каркаса приложения) 24
Методы проверки требований Основные практики проверки требований: • Утверждение модели - связана с вопросами обеспечения приемлемого качества продукта. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны заказчика. • Приемочные тесты - Требования должны быть верифицируемы. Требования, которые не могут быть проверены и аттестованы (утверждены) – это всего лишь “пожелания”. Именно так они буду восприниматься разработчиками, даже в случае их высокой значимости для пользователей. 25
Практические соображения • Итеративная природа процесса работы с требованиями меняющаяся природа требований Классические методологии Agile методологии • Управление изменениями - одна из ключевых тем управления требованиями: необходимо определять процедуры для обработки изменений в требованиях. • Атрибуты требований – позволяют их классифицировать (пр. : сценарии использования) • Измерение требований – оценка масштаба проекта, необходимых ресурсов. 26
Рекомендуемая литература • «Инженерия программного обеспечения» , Соммервилл И. • Основы Программной Инженерии (по SWEBOK) http: //swebok. sorlik. ru/ • «Разработка требований к программному обеспечению» , Карл И. Вигерс 27
Вопросы 28
От теории к практике! 29
Скачать презентацию Введение в инженерию программного обеспечения Модуль 2 программные
SWE module 2.pptx