Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Requirement Analysis by Mind Map: Requirement Analysis
5.0 stars - 6 reviews range from 0 to 5

Requirement Analysis

2. Понимание поттребностей пользователей

Преграды на пути выявления требований

Синдром "да, но..."

Синдром "неоткрытых руин"

Синдром "пользователя и разработчика"

Методы выявления требований

Интервьюирование и анкетирование

Совещания, посвященные требованиям

Мозговой штурм, посвященный идеям

Раскадровки, Пассивные, Активные, Интерактивные

Прецеденты (Юзкейсы)

Обыгрывание ролей

Создание прототипов

Функции продукта или системы

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

Атрибуты функий, Статус, Приоритет/Полезность, Трубоемкость, Риск, Стабильность, Целевая версия, Назначение, Обоснование

1. Анализ проблемы

5 Этапов анализа проблемы

Достигнуть соглашения об определении проблемы

Выделить основные причины - проблемы, стоящие за проблемой

Выявить заинтересованных лиц и пользователей

Определить границу системы решения

Выявить ограничения, котоыре необходимо наложить на решение

Моделирование Бизнес-процессов

Цели моделирования БП, Разобраться в структуре и динамике огранизации, Удостовериться в том, что заказчики, конечные пользователи и разработчики имеют одинаковое понимание организации

Выбор методологии моделирования БП

System Engineering (Системная инженерия)

Системная инженерия - это междисциплинарный подход и соответствующие ему средства, которые позволяют создавать успешно работающие системы. Это дисциплина, которая занимается выявлением на ранних этапах цикла разработки потребностей клиента и необходимых функциональных возможностей, а также документирование требований. За этим должны следовать разработка технического проекта как единого целого и проверка правильности создаваемой системы. В рамках системной инженерии рассматриваются: Функционирование Рабочие характеристики Тестирование Производство Затраты и сроки Обучение и поддержка Передача Системная инженерия объединяет действия различных групп специалистов в командные действия, образующие структурированный процесс разработки, от концепции к производству и функционированию. Системная инженерия учитывает как потребности бизнес-процесса, так и технические потребности всех клиентов с целью предоставить качественный продукт, удовлетворяющий потребности пользователя

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

3. Определение системы

Организация информации о требованиях

• For nontrivial applications, requirements must be captured and recorded in a document, database, model, or tool. • Different types of projects require different requirements organization techniques. • Complex systems require that requirements sets be developed for each subsystem.

Документ-концепция, Vision 1.0, Delta Vision

Лидер продукта

• Лидер продукта отвечает за концепцию проекта• Каждому проекту нужен лидер или небольшая лидирующая группа для защиты интересов продукта• При разработке программных продуктов лидером часто является представитель маркетинга

4. Управлением масштабом

Задание масштаба проекта

• При определении масштаба проекта первым шагом является задание базового уровня требований, т.е. упорядоченного списка высокоуровневых функций, которые будут реализовываться в указанной версии продукта• Второй шаг состоит в приблизительном определении объема трудозатрат, необходимого для каждой их перечисленных выше функций• Третьим шагом является оценка риска для каждой функции или вероятности того, что ее реализация окажет неблагоприятное воздействие на график и бюджет• Используя эти данные, команда задает базовый уровень (Baseline), таким образом, чтобы гарантировать предоставление критически важных для успеха проекта функций

Базовый уровень, Установка приоритетов функций, Критический, Важный, Полезный, Оценка трудозатрат, Высокая, Средняя, Низкая, Оценка риска, Высокий, Средний, Низкий

Сокращение масштаба

Умение общаться с заказчиком

• Необходимо привлекать заказчиков к управления собственными требованиями и масштабом их проекта• Заказчики, вовлеченные в процесс, будут владеть результатом• Выполнить задачу как следует – означает предоставить к указному времени достаточные функциональные возможности для удовлетворения реальной потребности клиента• Приемы веления переговоров являются неоценимым подспорьем при решении проблем управления масштабом

5. Уточнение Определения Системы

Спецификация требований к Программному Обеспечению (Modern SRS Package)

• Пакет спецификаций требований к программному обеспечению (Modern SRS package) представляет собой набор артефактов, полностью описывающих внешнее поведение системы. Он создает концептуальную модель создаваемой системы• Документ-концепция (Vision Document) служит исходной информацией для создания Modern SRS Package. Он определяет потребности пользователей, цели, задачи, целевые рынки и функции системы, в то время как в пакете Modern SRS Package основное внимание уделяется деталям реализации этих функций• Сбалансированный подход, как правило, заключается в совместном использовании модели прецедентов и традиционной спецификации требований

Требования к программному обеспечению, Категории элементов для определения системы, Вводы системы, Выводы системы, Функции системы, Атрибуты системы, Стрибуты системной среды, Функциональные требования, Нефункциональные требования, Практичность (Usability), Надежность Reliability, Производительность (Performance), Возможность обслуживания (Supportability), Ограничения проектирования, Использование дочерних требований

Критерии качества требования к ПО, Корректность, Недвусмысленность, Полнота, Непротиворечивость, Упорядоченность по важности и стабильности, Должно поддаваться проверке, Модифицируемость, Трассируемость, Понимаемость

Критерии качеств пакета Modern SRS Package, Хорошо составленное оглавление, Хороший индекс, История исправлений, Глоссарий

Уточнение прецедентов

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

Определение акторов

Дать название прецеденту

Составление краткого описания

Определение потока событий, Основной поток, Альтернативные потоки

Выявление пред- и постусловий

Неоднозначность и уровень конкретизации

• «Золотая середина» в требованиях достигается, когда удается добиться наибольшей понятности при наименьшей однозначности• Способность найти золотую середину зависит от навыков членов команды, содержания приложения и необходимого уровня гарантий, что система работает так, как требуется• Если необходимо исключить возможность неправильного понимания требований, может понадобиться применить более формальные методы их задания

Методы избежания неоднозначности, Эвристика запоминаний, Метод ключевых слов, Метод ударения, Другие

Что делать

Формальные методы спецификации требований

• Формальные методы описания спецификации требований применяются тогда, когда описание требований слишком сложно для естественного языка, или вам не удается создать недвусмысленную спецификацию • К формальным методам относится использование псевдокода, конечных автоматов, деревьев решений, диаграмм деятельности, моделей сущность-связь, объектно-ориентированных моделей и схем потоков данных

Псевдокод

Конечные автоматы

Деревья решений

Диаграммы деятельности

Модель сущность-связь

Объектно-ориентированные модели

Схемы потоков данных

6. Построение правильной системы

• Для правильного построения «правильной» системы необходимо постоянно убеждаться, что разработка производиться надлежащим образом, ее результаты корректны, и обрабатывать возникающие в процессе разработки изменения • Верификация (Verification) позволяет удостовериться, что деятельности разработки неизменно соответствуют потребностям клиента • Проверка правильности (Validation) демонстрирует,  что продукт соответствует предъявляемым к нему требованиям и конечный результат удовлетворяет требованиям заказчика • Поскольку изменения неизбежны, следует учитывать это при планировании и знать, как ими управлять

Верификация

Процесс оценивания системы или компоненты с целью определить удовлетворяют ли результаты некой фазы условиям, наложенным в начале данной фазы (IEEE 1012-1986, Параграф 2, 1994)

Стадии проекта, подлежащие верификации, Описанные функции действительно соответствуют потребностям, Производные от этих функций прецеденты и требования поддерживают данные функции, Прецеденты реализуются при проектировании, Проектирование поддерживает функциональные и нефункциональные аспекты поведения системы, Код действительно соответствует результатам и целям проектирования, Тесты обеспечивают полное покрытие разработанных требований и прецедентов

Уровни верификации, От потребностей пользователя к функциям продукта, От функций продукта к требованиям, От требований к архитектуре, От архитектуры к модели проектирования, От модели проектирования к реализации, От реализации к планированию тестов

From Use cases to Implementation (От понимания требований к реализации системы)

• Многие требования достаточно легко отобразить в технический проект и реализационный код • Существуют требования, слабо связанные с проектированием и реализацией; форма требования существенно иная; возникает проблема ортогональности • Смягчить проблему ортогональности можно посредством применения объектно-ориентированных методов и прецедентов • При проектировании с использованием прецедентов все заинтересованные лица получают возможность исследовать предложенную реализацию системы на соответствие вариантам использования и требованиям • Хороший проект системы не обязательно оптимален в том, что касается возможности видеть, где реализовано конкретно требование

Проблема ортогональности

Объектно-ориентированный подход

Прецедент в роли требований

Архитектура систем ПО, Задачи архитектуры, Понять, что делает система, Понять, как она работает, Иметь возможность обдумывать и разрабатывать части системы, Расширять систему, Повторно использовать части системы для создания новых систем, 4+1 представление архитектуры, Логическое представлние, Вид с точки зрения процессов, Вид с точки зрения прецедентов, Вид с точки зрения реализации, Вид точки зрения процессов

Реализация прецедентов в модели проектирования

Использование трассировки для поддержки верификации (Tracing Requirements)

• Трассировка является эффективным методом поддержки верификации• Программные требования трассируются от одной или нескольких функций продукта, заданных в документе-концепции (Vision Document)• Автоматические средства трассировки позволяют проверять верификационные отношения, чтобы удостовериться, что никакие необходимые отношения не пропущены и нет лишних верификационных отношений• Сами по себе автоматические средства не могут выполнить всю работу, верификация требует размышлений

Проверка правильности системы

• Проверка правильности (Validation) представляет собой процесс подтверждения того, что разработанная система соответствует предъявляемым к ней требованиям• Приемочное тестирование проверяет правильность работы системы в среде клиента и в сценариях использования• Чтобы добиться высокого качества, нужно проводить тестирование не только выполнения, но и соответствия требованиям и реальному использованию клиентом

Управление изменениями (Managing Change)

• Процесс управления требованиями может быть полезным только в том случае, если он позволяет распознать и решать проблему изменений • Внутренними факторами, приводящими к возникновению изменений, являются неспособность задать вопросы нужным людям в нужное время и отсутствие практического процесса, призванного справиться с изменениями требований • Чтобы повысить шансы на успех, необходимо предотвратить «просачивание» требований или, по крайней мере, существенно уменьшить их

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

Процесс управления изменениями, Осознать, что изменения неизбежны, и разработать план управления изменениями, Сформировать базовый уровень требований, Установить единый канал контроля изменений, Использовать систему контроля изменений для их фиксации, Обрабатывать изменения по иерархическому принципу