Презентация на тему Требования к разработке ПО

цикла разработки, что позволит снизить число доработок и повысить

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

управления проектами
Управление требованиями
Реализация процесса построения требований

будут примеры, которые вы сможете использовать на практике! Тем

самым поняв, чем и для чего мы с вами занимаемся.

ПО
Требования с точки зрения клиента
Приемы формулирования требований
Бизнес - аналитик

возникает из-за несовершенства способов, которые люди применяют для сбора,

документирования, согласования и модификации требований к ПО.
Проблемы могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных предположений, недостаточно определенных требований и бессистемного изменения процесса.
Многие исследования показывают, что на ошибки, внесенные на этапе сбора требований, приходится от 40 до 50% всех дефектов, обнаруженных в программном продукте.
Некорректные сведения от пользователей и недостатки определения и управления требованиями клиентов — основные причины провалов проектов. Но невзирая на эти сведения многие организации все еще применяют неэффективные методы сбора требований.
Нигде более, как на стадии сбора требований так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта. К заинтересованным в проекте лицам относятся клиенты, пользователи, бизнес-аналитики, разработчики и многие другие.

требования, они обычно начинают с проблемы терминологии. Разные эксперты,

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

линии – содержатся в
*пунктирные – влияют на (являются

отправной точкой)
Овалы – тип информации требований
Прямоугольники – документы, в кот. Хранятся эта инф.

то есть цели, которые организация намерена достичь с помощью

такой системы
Основное содержание БТ – бизнес – цели организации или клиента, заказывающих систему
БТ в форме документа – документ о концепции и границах (vision and scope document). Другие руководящие документы, которые используют в этом качестве: устав проекта (project charter), вариант использования (business case) или документ рыночных требований (market requirements document)
Пример: авиакомпания хочет на 25% снизить затраты на сотрудников у стойки в аэропорту. Может возникнуть идея установки терминала саморегистрации

иметь возможность выполнять с помощью продукта, который должен в

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

тех или иных условиях. Они определяют, что разработчики должны

создать, чтобы пользователи могли выполнять свои задачи (пользовательские требования) в рамках бизнес – требований
Пример: у пассажира ДОЛЖНА быть возможность распечатать посадочные талоны на все рейсы, на которые он зарегистрировался

отвечает за действия по работе с требованиями в проекте)

документирует функциональные требования в спецификации требований к ПО (software requirements specification – SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
Этот документ называют: документ бизнес – требований, функциональная спецификация, документ требований и т.д.

который содержит многие компоненты или подсистемы.
«Система» – программное обеспечение

или подсистемы ПО и оборудования
Пример: рабочее место кассира в супермаркете. В нем есть сканер ШК, интегрированный в весами, и ручной сканер ШК. Есть клавиатура, монитор, выдвижной ящик – касса. Все эти устройства взаимодействуют под управление ПО. На основе требований к системе или продукту, БА формулирует конкретную функциональность, которую должны поддерживать тот или иной компонент или подсистема, а так же интерфейсы взаимодействия между ними

стандарты и вычислительные алгоритмы

уровню обслуживания . Представляют собой описание различных измерений характеристик

продукта, которые важны для пользователей или для разработчиков
Другие НФ требования описывают внешние интерфейсы между системой и внешним миром. Например, подключение к другим программным системам, аппаратным устройствам и пользователям.
Ограничение проектирования и реализации накладывают границы на возможности выбора разработчика при проектировании продукта.

что система делает, а как хорошо она это делает.

Они могут описывать важные характеристики или свойства системы – доступность, легкость, простота в использовании, производительность.
Так же НФ требования описывают среду, в которой работает система, например платформа, переносимость, совместимость и ограничения.

для пользователя и удовлетворяют бизнес – цели.
Пример -

избранные страницы или закладки веб-браузера, средства проверки орфографии, запись макрокоманды, автоматическое обновление определений вирусов в антивирусной программе.
Характеристики могут охватывать множество пользовательских требований и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач.

потребности, требования рынка или концепции менеджеры и маркетинг определяют

бизнес – требования для ПО
2. На основа пользовательских требований аналитик или менеджер продукта определяет функции, которые дадут возможность пользователям выполнять их задачи.
3. Разработчикам необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью не выхода за рамки налагаемых ограничений. Тестировщики определяют, как проверять правильность реализации требований

мы обсудили до этого – требования, описывающие свойства программной

системы, которую планируется построить. Будем называть их требованиями к продукту
Для проекта используется другой набор требований. Например, документ, где описана среда разработки, ограничение бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживающую среду.

рабочие станции, специальные аппаратные устройства, тестовые лаборатории
Потребности в обучении

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

старой на новую систему, например требования по переносу и

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

по правовой защите (патенты, товарные знаки или авторское право)

интеллектуальной собственности, связанной с разрабатываемым ПО

требований
Анализ
Документирование
Утверждение

В эти составные части входят все действия, включающие сбор,

оценку, документирование и утверждение требований для ПО

выявлением требований, таких, как – интервью, совещания, анализ документов,

создание прототипов. Ключевые действия:
Определение классов ожидаемых пользователей продукта и других заинтересованных лиц
Понимание задач и целей, а также бизнес – целей, которым соответствуют эти задачи
Изучение среды, в которой будет использоваться новый продукт
Работа с отдельными людьми, которые предоставляют каждый класс пользователей, чтобы понять их потребности и ожидания в отношении качества

понимания всех требований и представление наборов требований в различном

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

архитектуре
Согласование приоритетов реализации
Выявление пробелов в требованиях или излишних требований,

не соответствующих заданным рамкам

о требованиях постоянным и хорошо организованным способом. Ключевое действие:
Преобразование

собранных потребностей пользователей в письменные требования и диаграммы, пригодные для понимания, анализа и использования целевой аудиторией

которые позволят разработчикам создать решение, удовлетворяющие бизнес – целям.

Основные действия:
Проверка задокументированных требований для устранения всех недостатков до принятия требований группой разработки
Разработка приемочных тестов и критериев, которые должны подтвердить, что созданный на основе требований продукт будет отвечать потребностям заказчика и удовлетворять поставленным бизнес – целям.

моментальный снимок, который представляет согласованный, проверенный и одобренный набор

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

отдельных требований до их проектирования, исходного кода и тестов
Отслеживание

состояния требований и действий по изменению на протяжении всего проекта

– переделка того, что уже готово
Недостаточное вовлечение пользователей
Небрежное планирование

(я кое-что придумал, когда сделаете?)
«Разрастание» требований пользователя
Двусмысленные требования
Требования – «бантики» (то что разраб. Добавили, потому что могут)
Пропущенные классы пользователей

требованиях и в готовом продукте
Меньше переделок
Быстрее разработка и поставка

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

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

области — Создайте словарь бизнес-терминов

Установите границы для контроля изменений — Проанализируйте, какое влияние оказывают

изменения — Определите основную версию и управляйте версиями требований — Отслеживайте хронологию изменений — Отслеживайте состояние требований — Определите изменяемость требований — Используйте утилиту управления требованиями — Создайте матрицу связей требований

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

рисками, касающимися требований — Отслеживайте объем работ по реализации требований — Делайте выводы из полученного опыта

Определите образ и границы проекта — Определите классы пользователей — Выделите

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

Проанализируйте осуществимость — Расставьте приоритеты для требований — Смоделируйте требования — Создайте

словарь терминов — Распределите требования по подсистемам — Воспользуйтесь технологией развертывания функций качества (Quality Function Deployment)

ПО — Определите источники требований — Задайте каждому требованию уникальный идентификатор —

Задокументируйте бизнес-правила — Укажите атрибуты качества

требования — Определите критерии приемлемости

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

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

принимать участие в разработке ПО, должны пройти непродолжительный тренинг

(один-два дня), чтоб научиться формулировать требования. Он полезен и для менеджеров по разработке и по работе с клиентами. Обучение поможет понять особое значение выделения требований, суть процесса их разработки, а также опасность пренебрежения ими.

в общих чертах понять предметную область, проведите семинар, на

котором познакомьте их с бизнесом клиента, терминологией и назначением создаваемого продукта. Это уменьшит вероятность путаницы, непонимания и доработок. Можно также на время проекта назначить каждому разработчику «личного пользователя», который будет разъяснять профессиональные термины и бизнес-концепции. Лучше, если это будет настоящий фанат продукта.

снизит вероятность непонимания, Включите в него синонимы, термины, имеющие

несколько значений, и термины, имеющие в предметной области и повседневной жизни разные значения.

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

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

и границах проекта содержит бизнес-требования к продукту. Описание образа

проекта позволит всем заинтересованным лицам в общих чертах понять назначение продукта. Границы проекта определяют, что следует реализовать в этой версии, а что — в следующих. Образ и границы проекта — хорошая база для оценки предлагаемых требований, Образ продукта должен оставаться от версии к версии относительно стабильным, но для каждого выпуска необходимо составлять отдельный документ о границах.

упустить из виду потребности отдельных пользователей, выделите их в

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

классе пользователей. Это человек, который сможет точно передавать настроения и

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