Разработка требований. Тема 5

1.

theme 5
Information Systems and Software
Requirements Engineering
Тема 5 Разработка требований к
информационным системам и программному
обеспечению

2.

• Разработка требований
— это процесс определения, документирования и поддержания
требований.
• Это процесс сбора и определения услуг, предоставляемых
системой.
• Процесс разработки требований состоит из следующих основных
действий:
• Выявление требований
• Анализ и Спецификация требования
• Проверка и подтверждение требований
• Управление требованиями

3.

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

4.

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

5.

6.

• „Bună dimineața, Maria.
- Sunt Marcel, analist de cerințe pentru un nou sistem informațional
Managmentul Resurselor Umane (HR) pe care urmează să -l dezvoltăm
pentru dvs.
- În primul rând mulțumesc că ai acceptat să devii susținătoare al acestui
proiect.
- Informațiile D-tale. ne vor fi foarte utile.
- Acum totuși spune-mi te rog ”de ce mai ai nevoie? "

7.

• „Hm, de ce am nevoie”, meditează Maria.
- Habar n-am de unde să încep.
Ei bine,
- noul sistem ar trebui să funcționeze mult mai repede decât cel
existent.
- Apoi, știi cum se blochează vechiul sistem, dacă numele unui angajat
este prea lung - trebuie să contactăm serviciul de asistență pentru ca
aceștia să introducă numele. În noul sistem, numele lungi nu trebui să
blocheze sistemul.
- Aș dori, de asemenea, să pot schimba numele angajaților, chiar dacă
starea lor civilă rămâne aceeași. "

8.

-Ar fi, de asemenea utilă, Funcția de evidență a timpului petrecut
pentru instruire de fiecare angajat în anul current,
- -Ar mai fi, de asemenea utilă, Funcția de evidență a timpului de
întârziere la servicui,
- Marcel a scris conștiincios toate dorințele Mariei, dar capul lui a început să se
învârtă.
- Nu știa ce să facă cu această informație și habar nu avea ce să transmită
dezvoltatorilor.
- Marcel Ei bine, s-a gândit el, dacă Maria vrea să facem asta, cred
că va trebui să o facem.

9.

• Суть процесса формулирования требований
заключается в выявлении потребностей и ограничений,
выраженных заинтересованными сторонами проекта.
• Цель процесса формулирования требований – выявить
и сформулировать требования пользователей,
занимающих средний уровень в модели требований –
триаду (Бизнес-требования, пользовательские требования,
функциональные требования).

10.

• Аналитик должен структурировать объема
информации полученной в процессе идентификации
требований.
• Задавая пользователю только вопрос
«Чего вы хотите?», вы получите множество
информации, в которой сложно будет разобраться.
• Вопрос: «Что вы должны делать?» - гораздо
правильнее.
• Результатом этапа формулирования требований является
согласованное понимание потребностей всех
заинтересованных сторон проекта.

11.

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

12.

13.

Схема Захмана

14.

• Схема Захмана позволяет:
— использовать одну концептуальную основу, единую и понятную
как для бизнес-специалистов, так и для ИТ-специалистов;
— фокусироваться на отдельных аспектах предприятия (вплоть до
конкретной системы), не теряя взгляда на целое;
— обеспечивать согласованность бизнеса и ИТ за счет соответствия
описаний в ячейках;
— сохранять независимость от какого-либо программного продукта
(инструмента).

15.

• Разработка требований — это деятельность, которая
преобразует потребности и желания клиентов и
потенциальных пользователей компьютерных систем,
обычно неполные и выраженные в неформализованных терминах,
в полных, точных и последовательных спецификациях,
предпочтительно записанных в формализованных обозначениях.
Вкладом в этот процесс является обычно неформализованный,
нечеткий «Список пожеланий»,
Для нас вывод должен быть достаточно формализованной
спецификацией для анализа

16.

• Успех процесса разработки требований
полностью зависит от
«способности перейти от неформализованных и
расплывчатых отдельных требований
к формализованной спецификации, понятной и
согласованной всеми заинтересованными
сторонами.

17.

• Результатом инженерии требований является:
«иерархический список требований, которая:
обеспечивает согласованное понимание между
заинтересованными сторонами проекта (покупателями,
пользователями, заказчиками, операторами, поставщиками);
- он проверен в соответствии с реальными потребностями
и может быть реализован;
- обеспечивает основу для проверки проекта и принятия решения.

18.

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

19.

• Жизненный цикл требований

20.

Этапы процесса разработки встраиваемой системы
• Идея/цель продукта
• Техническая спецификация
• Архитектура решения
• Раздел компонентов и доработка дизайна
• План тестирования
• Реализация дизайна
• PoC / Разработка прототипа
• Полевые испытания
• Улучшения конечного продукта
• Выпуск продукта

21.

22.

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

23.

System Thinking

24.

• Жизненный цикл системы включает в себя все этапы создания и
существования системы, которые можно разбить на этапы.
• Жизненный цикл позволяет разделить проект на:
- система,
- концепция,
- проектирование и разработка,
- производство и/или строительство,
- распространение,
- эксплуатация,
- техническое обслуживание и поддержка, а также вывод из эусплуатации.
- Здесь термин «стадия» относится к разным периодам жизненного цикла
системы.
- Некоторые этапы могут перекрываться во времени, например, этап
использования и этап поддержки.

25.

System Life Cycl

26.

• Исследование:
• этот этап обычно включает в себя
• определение миссии (зачем нужна система?
• кто будет ее использовать?) и
• понимание требований (как должна выглядеть система?
• как система будет использоваться?).
Определение целей и приложений проекта имеет
решающее значение для разработки успешных систем.

27.

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

28.

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

29.

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

30.

• Использование:
• Этап использования — это когда система доставляется
заказчику и развертывается для использования на
обьекте.
• Если поставляемая система (например, сотовый телефон)
является частью большой сервисной системы (также
известной как система в системе), интеграция и проверка
этой совместимость системы с другими
вспомогательными системами имеет решающее
значение для успеха ее развертывания.

31.

Graphical ‘Vee’ Model

32.

Expluatare,
Mentenanță
validare
Elaborarea
concepției
verificare
Ingineria
Cerințelor
Elaborarea
arhitecturii
sistemului
implementare
în funcțiune
Asamblare,
Integrare
componente
Realizarea
sistemului
Locul ingineriei cerințelor în ciclul de viață al sistemului

33.

• Жизненный цикл требований
1. Выявление требований заинтересованных сторон –
определение проблем, которые необходимо решить.
2. Разработка требований заинтересованных сторон
– бизнес-анализ, анализ требований, выявление
ключевых потребностей, обобщение.
3. Разработка системных требований - оценка
требований в разрезе существующих возможностей и
бизнес-процессов разработчиков.
4. Документирование требований – формальное и
подробное описание требований, (утверждение ТЗ).

34.

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

35.

• Определение объема системы и требований в соответствии со
стандартом ISO/IEC 29148:2011 (Системная и программная
инженерия. Процессы жизненного цикла. Разработка требований)

36.

• Определение объема системы и требований
зависят от:
• Внешней среды
• Организационной среды
• Оперирование деловой среды

37.

• Проблема разработки требований
• Чтобы быть уверенным, что компьютерная система правильно решает
определенную задачу, нужно сначала правильно понять задачу,
которую необходимо решить.
• В этом смысле необходимы открытие, понимание, спецификация и
анализ следующих компонентов:
• КАКАЯ проблема должна быть решена;
• ПОЧЕМУ такая проблема требует решения;
• КТО участвует и будет нести ответственность за решение этой
проблемы.
По сути, эти три компонента составляют основу
дисциплины под названием «Разработка требований
к информационным системам».

38.

• Фундаментальной проблемой разработки
требований к системе является
удовлетворенность пользователей.
• Делать это надо не точечно, не сразу, а
гибко и на перспективу.

39.

• Основные действия по построению модели требований
Относительная стоимость на
разных этапах разработки ПО

40.

Процесс идентификации требований

41.

Процесс идентификации требований
context
Реальные
требования
Осознание
требований
Приоритеты
путем
сравнение
Выборка
Осознанные
требования
Фиксация
требований
Регистрция
требованя
stakeholders
Требования
заинтересованных
сторон
Спецификаия
пользователей
Требования
обусловленные
контекстом
Реализованные
требования
Проектирование& внедрение
Возможные
решения
Фиксированные
требования
Системные
требования
Система, Soft, сервисы
Документирование
как SRS
41

42.

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

43.

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

44.

• Пример спецификации
• Спецификация авиационного радиолокационного и трекерного
комплекса:
-Система должна принимать радиолокационные сообщения от
коротковолнового радара.
- Период сканирования радара должен составлять 4 секунды.
- Частота радара должна быть в диапазоне 2,6-2,7 ГГц.
- Частота интервала повторения импульсов 1040 Гц.
- Количество трекеров должно быть до 200 самолетов.
- Полоса пропускания должна быть 2400.
- Размер сообщения должен быть 104 бит/сообщение.
- Система начнет отслеживать самолеты, которые находятся менее чем в
2 милях от контролируемой зоны.
- Инициация трекера произойдет через интервал 6 секунд после
обнаружения - ...

45.

• Даже в такой небольшой части требований, как указано выше,
терминология радиолокационной системы является специфической
и может быть сложной для аналитика, не знакомого с этой областью.
• Более того, аналитик, не знающий предметную область, не может
проверить приведенные выше спецификации на непротиворечивость и
полноту.
• В этом примере существует возможный конфликт в приведенных выше
требованиях между 2-мильной границей контролируемой зоны и 4мильной дистанцией, которую может преодолеть самолет, летящий со
скоростью 600 миль в час за 24 секунды (что является временем запуска
трекера). Необходимость разбираться в радиолокационной технологии в
этом примере, без сомнения, обязательна.
• Это приводит к другому вопросу: где можно найти такое
(предметное) знание и как его получить?

46.

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

47.

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

48.

• Но на практике запрос пользователей создает трудности по
нескольким причинам:
- пользователи не всегда имеют четкое представление о своих
требованиях к новой системе
- у пользователей могут возникнуть трудности в описание
своих знаний в проблемной области
- различаются средства выражения знаний пользователей и
аналитиков; пользователи используют свою собственную
предметно-ориентированную терминологию, в то время как
аналитики используют компьютерно-ориентированный
словарь
- пользователям может не понравиться идея создания новой
(незнакомой) информационной системы, и поэтому они не
захотят участвовать в процессе выявления требований.

49.

• Действия при выявления требований

50.

• В процессе выявления требований перед аналитиком
ставятся задачи:
- Выявить все источники знаний о требованиях
- Получить необходимые знания о предметной области
- принять решение об актуальности полученных знаний
для решения проблемы
- Понимать значение полученных знаний и их влияние на
требования к информационной системы.

51.

• Часто трудности в выявлении и анализе требований
возникают из-за недостаточного понимания логической
части приложения, также известной как бизнес-логика.
• Бизнес-логика является определяющим элементом для
процесса моделирования и автоматизации,
• Бизнес-логика включает в себя как бизнес-правила, так и
рабочие процессы внутри бизнеса,
• который описывает передачу документов или данных от
одного участника (физического лица или программной
системы) к другому.

52.

• При разработке ИТ-систем бизнес-логика преследует
следующие цели:
- моделирование бизнес-объектов из реального мира
(материальные резервы, клиенты, поставщики,
продукты, нормы и регламенты);
- управление способом хранения бизнес-объектов
(отображение бизнес-объектов в таблицах базы
данных);
- описание условий взаимодействия и взаимовлияния
бизнес-объектов друг с другом.

53.

ПРОЦЕСС ПРОЕКТИРОВАНИЯ ТРЕБОВАНИЙ

54.

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

55.

Requirement Elicitation and
Development
Requirement Management & Planing
Documentation of
Requirements
Validation and
Verification of
Requirements

56.

• A. Выявление и разработка требований
• Фаза выявления и разработки требований в основном
фокусируется на изучении и сборе желаемых
требований и целей системы с разных точек зрения
(заказчик, пользователи, ограничения, операционная среда
системы, торговля, маркетинг стандарт и т. д.).
• Этап Выявление требований начинается с определения
заинтересованных сторон в новую систему и сбор
необработанных требований с различных точек зрения.
• Сырые требования – это требования, которые не были
проанализированы и еще не были записаны в правильно
сформулированном требованием.

57.

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

58.

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

59.

60.

1. Анализ требований:
• Сбор и разработка требований к хорошему качеству
является основной деятельностьюлюбой организации по
разработке качественных программных продуктов.
• Затем Эти требования тщательно анализируются в
контексте требований бизнеса.
• Также отмечается, что выявленные необработанные
требования могут быть противоречивыми.
Следовательно,переговоры, согласование, коммуникация
и установление приоритетов необработанных
требований становятся важной деятельностью анализ
требований.

61.

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

62.

2. Распределение и декомпозиция требований:
• Цель распределения и декомпозиции требований сверху
вниз состоит в том, чтобы убедиться, что все системные
требования выполняются подсистемой или набором
подсистем, которые могут работать вместе для
достижения целей.
• Системные требования верхнего уровня должны быть
организованы иерархически, что позволит просматривать и
управлять информацией на разных уровнях абстракции.
• Требования декомпозируются до уровня, на котором
требование может быть спроектирована и протестирована.

63.

• Таким образом, выделение и декомпозиция требований
может выполняться для нескольких иерархических
уровней.
• Уровень детализация увеличивается по мере того,
как работа продвигается вниз по иерархии. То есть
системные требования носят общий характер, в то
время как требования на нижних уровнях иерархии
очень специфичны.
• Системные требования верхнего уровня,
определенные в Этап разработки системных
требований является основным входом для этапа
декомпозиции требований и потока вниз.

64.

• B. Документироавние требований
Это Официальный документ который составляется после сбора требований,
который содержит полное описание поведениея программной системы.
• Процесс развития Требования– это деятельность по определению того, какие
функциональности системы будут выполняться программным обеспечением.
• Нефункциональные требования объединяются вместе с функциональные
требования в спецификацию требований к программному обеспечению их
распределение и декомпозиции вниз.
• Спецификация требований к программному обеспечению устанавливается для
каждой программной подсистемы, каждого элемента конфигурации
программного обеспечения или компоненты является частью этой фазы.
• Документирование требований включает идентификация и спецификация
требование.

65.

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

66.

• 2) Спецификация требований:
• Документ спецификации требований создается после успешной
идентификации требований.
• Документ описывает поставляемый продукт, а не процесс его
разработки.
• Спецификация требований к программному обеспечению (SRS) — это
эффективный инструмент который представляет собой полное
описание поведения разрабатываемой системы или программного
обеспечения.
• полное описание поведения включает в себя набор вариантов
использования, описывающих все взаимодействия пользователей с
информационной системой или программным обеспечением.
• В дополнение к вариантам использования SRS также содержит
нефункциональные (или дополнительные) требования.

67.

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

68.

C. Проверка и подтверждение требований
Когда все требования описаны и указаны в SRS, то заинтересованные
стороны должны осознать каковы эти требования. Следует убедиться,
что заявленые требования правильны (валидация) и эти требования
сформулированы правильно (проверка).
Мероприятия по валидации и верификации включают проверку
системных требований на соответствие и проверка правильности
системных требований согласно документации.
Наиболее распространенные методы проверки требований - это обзоры
требований с заинтересованными сторонами, и прототипирование.
Требования к программному обеспечению должны быть
подтверждены а требований системного уровня, должен быть
проверены.

69.

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

70.

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

71.

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

72.

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

73.

• Для начала, рассмотрим кто такие стейкхолдеры.
• Стейкхолдерами могут быть любые физические лица и/или
организации, которые активно участвуют в проекте, и чьи
интересы могут быть затронуты не только в процессе создания
системы, но и непосредственно по завершению самого проекта.
• Ими могут быть:
• менеджеры, начальники отделов, директора, любые
сотрудники организации, которые будут хоть как-то
взаимодействовать с готовым решением, и чьи
требования (пожелания, идеи, потребности, проблемы)
будем собирать.

74.

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

75.

• Плюс:
Получение документированной информации.
Минус:
Данный способ не применим при наличии в компании только
базовых документов (или при их полном отсутствии) или, если в
компании Заказчика не поддерживается актуальность
документации.

76.

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

77.

• Преимущества:
1. Высокая скорость получения результатов.
2. Сравнительно небольшие материальные затраты.
• Недостатки:
1. Данный метод не подходит для выявления неявных требований.
2. При составлении опросника физически невозможно учесть все
необходимые вопросы.

78.

• Интервью
• Этот метод известен многим, своего рода беседа
“по душам” с заинтересованным лицом, тет-а-тет.
Необходимо задавать:
- открытые вопросы для получения информации и
- закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты
требований.
Данный способ применяется, в основном, для получения информации по какой-либо
конкретной теме и/или для уточнения требований.
На первый взгляд этот способ оказывается достаточно легким, но это не так.
Провести хорошее интервью достаточно сложно.
- Вы должны гибко реагировать на реакцию интервьюируемого и в случае
необходимости изменять порядок заготовленных вопросов или их формулировку. Не
забудьте включить диктофон во время интервью или вести заметки.

79.

• Из плюсов:
1. Возможность задавать вопросы в произвольной
последовательности.
2. Возможность использовать вспомогательный материал.
3. Анализ невербальной реакции опрашиваемого человека,
позволит сделать дополнительный вывод о достоверности его
ответов.
Из минусов:
4. Интервью отнимает достаточно много времени и сил.
5. Дополнительной сложностью является получение одинаковых
ответов от интервьюируемых.

80.

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

81.

• Преимущество:
Помогает лучше понять сложные процедуры или процессы.
Недостаток:
Данный метод сильно зависит от опыта Заказчика, а также от его
умения формулировать и выражать свои мысли.

82.

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

83.

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

84.

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

85.

• Преимущество:
Быстрое получение обратной связи и информации от Заказчика.
Недостатки:
Достаточно высокая цена для Заказчика.
Затраты по времени на адаптацию сотрудника.

86.

• Работа «в поле»
• Работа «в поле» состоит из наблюдения за деятельностью и процессами
будущих пользователей системы, и в определении требований, основанных
на этом наблюдении. Если говорить проще, то это наблюдение за тем, как
работают пользователи, и документирование процесса, задач и
результатов их деятельности.
• Метод позволяет избежать проблем, связанных с трудностями
стейкхолдеров в описании и выражении своих потребностей.
• В некоторых случаях процесс наблюдения может сопровождаться
«интервьюированием» пользователей для уточнения особенностей и
деталей их работы и задач. В процессе наблюдения можно так же выявить
пути оптимизации бизнес процессов Заказчика.

87.

• Преимущества:
1. Позволяет наглядно увидеть проблему и разработать наиболее оптимальный
вариант ее решения.
2. Помогает наиболее точно собрать требования, наблюдая за работой
сотрудников.
Недостатки:
1. В процессе наблюдения могут быть упущены некоторые альтернативные
сценарии бизнес процесса.
2. Трудно применим на секретных предприятиях или опасных (вредных)
производствах.

88.

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

89.

• Мозговой штурм
• Мозговой штурм — наиболее часто используемый метод получения
требований, которые связанны с новыми или плохо изученными
направлениями деятельности организации Заказчика или функциями
системы.
Он позволяет собрать множество идей от различных заинтересованных лиц
(стейкхолдеров) в кратчайшие сроки и практически бесплатно.
Во время мозгового штурма участники «накидывают» любые идеи,
касающиеся решения данной проблемы.
С помощью этой методики можно проработать несколько различных
вариантов решения заданной проблемы, а также разрешить конфликты
требований.

90.

• Плюсы:
Позволяет генерировать множество (в том числе и нестандартных)
вариантов решений, а также позволяет участникам развивать идеи
друг друга.
Минусы:
Участники мозгового штурма должны быть мотивированы на идеи.
Трудно применим в распределенных командах.

91.

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

92.

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

93.

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

94.

• Комбинирование разных методик позволяет повысить
эффективность сбора требований, а так же избежать их
«потери».
При сборе требований необходимо помнить, что важны
не только функциональные требования (ЧТО делает
система), но и нефункциональные (КАК система это
делает).
Тщательно собранные требования минимизируют риски
проекта, т.к. позволяют сформировать четкий и понятный
базис для разработки системы.

95.

• Analiza cerințelor
Formularea
problemei
Colectarea
cerințelor
Analiza
cerințelor
Как бизнес-аналитик, анализ требований
является наиболее важной частью вашей
работы.
Это поможет вам определить реальные
потребности ваших стейкхолдеров.
В то же время он позволяет вам общаться с
заинтересованными сторонами на
понятном им языке (например, на
диаграммах, моделях) вместо сложного
текста.

96.

• Анализ требований имеет:
- Конкретная цель
- Конкретная запись
- Конкретный выход
- Использует ресурсы
- ряд действий, которые необходимо выполнять в
определенном порядке
– Может затронуть более одного организационного
подразделения.
- Создает дополнительную ценность для клиента

97.

• ответ на вопрос: "Как проводить анализ требований?"
- думать, копать в детали, спрашивать, искать истинные
причины и зависимости, находить несоответствия и их
устранять, описывать, моделировать, согласовывать,
декомпозировать от общего к частному и собирать картинку
обратно до уровня целостной системы.
Повторять все вышеперечисленное до тех пор, пока не будет
найден консенсус с заказчиком и заинтересованными лицами,
командой разработки и всеми остальными, которых так или
иначе затронут изменения.

98.

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

99.

100.

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

101.

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

102.

• Одной из широко используемых методик документирования
системных требований является построение ряда моделей системы.
Эти модели используют графические представления,
показывающие решение как исходной задачи, для которой создается
система, так и разрабатываемой системы.
• Модели являются связующим звеном между процессом анализа
исходной задачи и процессом проектирования системы.
● Модели могут представить систему в различных аспектах:
– Внешнее представление, когда моделируется окружение или рабочая
среда системы.
– Описание поведения системы, когда моделируется ее поведение.
– Описание структуры системы, когда моделируется системная
архитектура или структуры данных обрабатываемых системой

103.

• Наиболее важным аспектом системного моделирования
является то, что оно опускает детали.
• Модель является абстракцией системы и легче поддается
анализу, чем любое другое представление этой системы.
• В идеале представление системы должно сохранять
всю информацию относительно представляемого
объекта.
• Абстракция является упрощением и определяется выбором
наиболее важных характеристик системы.

104.

1. Notația de modelare a proceselor busines (BPMN)
BPMN (Business Process Modeling & Notation) este o reprezentare grafică a
proceselor de afaceri busines folosind obiecte simple, care ajută organizația să
comunice într-un mod standard. Obiectele utilizate în BPMN includ:
Fluxuri de Obiecte
InterConectarea obiectelor
Direcții de parcurgere a activităților
Artefacte.
Un model BPMN bine conceput trebuie să poată oferi detalii despre activitățile
desfășurate în timpul procesului, cum ar fi:
Cine desfășoară aceste activități?
Ce elemente de date sunt necesare pentru aceste activități?
Cel mai mare beneficiu al utilizării BPMN este că este mai ușor de partajat, iar
majoritatea instrumentelor de modelare acceptă BPMN.

105.

Exemplu analiză și modelare în BPMN

106.

2. Tehnica diagramelor de flux
Diagramă de flux este o reprezentare vizuală a fluxului secvențial și a logicii
de control a unui set de activități sau acțiuni conexe.
Există diferite formate pentru diagramele de flux care includ:
- fluxuri liniare,
- Fuxuri de sus în jos și
- Fluxuri transversale ().
O diagramă de flux poate fi utilizată pentru diferite activități, cum ar fi:
- reprezentarea fluxurilor de date,
- interacțiunile sistemului, etc.
Avantajul utilizării Diagramei de flux este că poate fi ușor de citit și scris chiar și
pentru membrii echipei non-tehnice și poate arăta procese paralele prin funcție
și/sau atributele critice ale unui proces etc.

107.

108.

3. Diagrame fluxului de date
Diagramele fluxului de date arată modul în care datele sunt procesate de un sistem în ceea ce
privește intrările și ieșirile.
Componentele diagramei fluxului de date includ:
Proces (funcție)
Flux de date (Flow)
Repozitoriu (file / database)
Entități externe
O diagramă logică a fluxului de date arată activitățile sistemului, în timp ce o diagramă
fizică a fluxului de date arată infrastructura unui sistem.
O diagramă a fluxului de date poate fi proiectată la începutul procesului de solicitare a cerințelor
din faza de analiză din cadrul SDLC (Ciclul de viață al dezvoltării sistemului) pentru a defini
domeniul de aplicare al proiectului.
Pentru o analiză ușoară, o diagramă a fluxului de date poate fi introdusă în subprocesele sale
cunoscute sub denumirea de „DFD pe nivele”.

109.

110.

111.

112.

113.

4. IDEF (Definiție integrată pentru modelarea
funcțiilor)
IDEF sau Definiție integrată pentru modelarea funcțională este un
nume comun care se referă la clase de limbaje de modelare a
întreprinderii.
Este utilizat pentru activitățile de modelare necesare pentru a sprijini
analiza, proiectarea sau integrarea sistemului.
Există aproximativ 16 metode pentru IDEF, cele mai utilizate versiuni ale
IDEF sunt IDEF0, IDEF3 și IDEF1x.

114.

115.

116.

117.

• 5. Diagrame de activitate a rolului- (RAD)
Diagrama activități pe roluri este similară cu notația de tip diagramă.
În Diagrama activități pe roluri , instanțele de rol sunt participanți la
proces, care au starea de început și de sfârșit.
RAD necesită o cunoaștere profundă a procesului sau a organizației
pentru a identifica rolurile.
Componentele RAD includ:
- Activități
- Evenimente externe
- Stările

118.

119.

• Rolurile grupează activitățile împreună în unități de
responsabilitate, în funcție de setul de responsabilitate pe care îl
desfășoară.
• O activitate poate fi desfășurată izolat cu un rol sau poate necesita
coordonare cu activități din alte roluri.
• Evenimentele externe sunt punctele în care apar schimbări de stare.
• Stările sunt utile pentru cartografierea activităților unui rol pe
măsură ce progresează de la stare la stare. Când se atinge o
anumită stare, aceasta indică faptul că un anumit obiectiv a fost
atins.
• RAD este util în susținerea comunicării, deoarece este ușor de citit și
de prezentat o vizualizare detaliată a procesului și permite modelarea
activităților în paralel.

120.

6. Rețele Petri colorate (CPN)
• CPN sau Rețele Petri colorate este un limbaj graf - orientat pentru
specificarea, verificarea, proiectarea și simularea sistemelor.
• Rețele Petri colorate sunt o combinație de grafică și text.
Componentele sale principale sunt Locuri, Tranziții și Arcuri.
• Obiectele din rețelele Petri au inscripții specifice pentru:
Locuri: are inscripție precum .Nume, .Color Set, .Marcare inițială etc.
Tranziție: are inscripție precum .Nume (pentru identificare) și .Guard
(expresia booleană constă din unele dintre variabile)
Arcuri: are inscripție ca .Arc. Când este evaluată expresia arcului,
aceasta produce mai multe seturi de culori de jetoane.

121.

122.

7. UML (Unified Modeling Language)
• UML este un limbaj de modelare utilizat în principal pentru specificarea,
dezvoltarea, vizualizarea și documentarea sistemului software.
• Pentru a surprinde importante procese de afaceri și artefacte UML
oferă elemente precum:
- Stare
- Obiect
- Activitate
- Clase

123.

124.

• Există 14 diagrame UML care ajută la modelare,
Un model de afaceri bazat pe UML poate fi o contribuție
directă la un instrument de cerințe.
Cele mai semnificative diagrame UML pote fi:
- model comportamental care încearcă să ofere
informații despre ceea ce face sistemul
- model structural care va reflecta din ce constă sistemul.

125.

8. Diagramele Gantt
• O diagramă Gantt este o reprezentare grafică a unui program care
ajută la coordonarea, planificarea și urmărirea sarcinilor specifice întrun proiect.
• Reprezintă intervalul total de timp al obiectului, împărțit în trepte.
• O diagramă Gantt reprezintă:
- lista tuturor sarcinilor care trebuie efectuate pe axa verticală,
- pe axa orizontală se listează durata estimată a activității și/sau numele
persoanei alocate activității.
- O diagramă poate demonstra multe activități.

126.

127.

• 9. Tehnica fluxului de lucru
• Tehnica fluxului de lucru este o diagramă vizuală care reprezintă unul
sau mai multe procese de afaceri pentru a clarifica înțelegerea
procesului sau pentru a face recomandări de îmbunătățire a
procesului.
• La fel ca alte diagrame, cum ar fi diagrama de flux, activitatea UML și
harta proceselor, tehnica fluxului de lucru este cea mai veche și
populară tehnică.
• Este chiar utilizat de Busines Analist pentru a lua notițe în timpul
solicitării cerințelor.

128.

• Procesul cuprinde patru etape:
Colectarea informației
Modelarea fluxului de lucru
Modelarea proceselor de afaceri
Implementare, verificare și executare

129.

130.

• 10. Metode orientate pe obiecte
Metoda de modelare orientată pe obiecte utilizează paradigma
orientată pe obiecte și limbajul de modelare pentru proiectarea unui
sistem. Se pune accent pe găsirea și descrierea obiectului în domeniul
problemei.
Scopul metodei orientate pe obiecte este:
Pentru a ajuta la caracterizarea sistemului
Să se știe care sunt diferitele obiecte relevante
Cum se relaționează între ele obiectele
Cum se specifică sau se modelează o problemă pentru a crea un
design eficient
Să analizeze cerințele și implicațiile acestora

131.

• Această metodă este aplicabilă sistemului care are cerințe
dinamice (se modifică frecvent).
• Este un proces de derivare a cazurilor de utilizare, a fluxului de
activitate și a fluxului de evenimente pentru sistem.
• Analiza orientată pe obiecte poate fi realizată prin necesități
textuale, comunicarea cu părțile interesate de sistem și
documentul de viziune.
• Obiectul are o stare, iar schimbările de stare sunt condiționate
de comportament. Deci, atunci când obiectul primește un
mesaj, starea se schimbă prin comportament.

132.

• 11. Analiza decalajului
• Analiza decalajului este tehnica utilizată pentru a determina diferența
dintre starea propusă și starea actuală pentru orice afacere și
funcționalitățile acesteia.
• Răspunde la întrebări precum care este starea actuală a proiectului?
Unde vrem să fim?
Etape ale Analizei Gap includ:
Revizuirea sistemului
Cerințe de dezvoltare
Comparație
Implicații
Recomandări

133.

• Литература
• An Effective Requirement Engineering Process Model for Software Development and Requirements
Management . Dhirendra Pandey, U. Suman, A. K. Ramani