Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Верификация

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

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

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

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

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

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

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

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

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