• Like
Бизнес и системный анализ весна 2013 лекция 4
Upcoming SlideShare
Loading in...5
×
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,504
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
77
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 2. Часть 1 Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 3.  Анализ проблемы  Формулировка проблемы  Извлечение требований  Заинтересованные лица  Персоны  Концепция  Сценарный подход Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 4. ЖЦ Продукта Стратегия Продукта Описание Возмож-ти Бизнес кейс Рынок / Сегмент Бизнес модель Концепция продукта Заинтересованные стороны Формулировка проблемы Возможности Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 5. Желательность идеи Осуществимость идеи Жизнеспособность идеи Лекция №4. «Моделирование использования. Анализ проблемы» Клиенты Что они думают, делают и чувствуют? Имеет ли бизнес-модель смысл? Source: Adapted from IDEO (www.IDEO.com) Имеем ли мы необходимые Технологии? ‹#›
  • 6. Business Case* • Business Case является стандартным способом КОММУНИКАЦИИ обоснования начала проекта • Business Case охватывает финансовые и другие бизнес-аспекты проекта. Как положительные, так и отрицательные Пакет поддержки принятия решения (“Decision Support Package”) в этом контексте синоним “Business Case” Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 7. Opportunity Identificati on Concept Generation Concept Evaluation Development Launch Gate GateGate GateGate Лекция №4. «Моделирование использования. Анализ проблемы» Оценка Идеи Грубая оценка Полный кейс ‹#›
  • 8. Выделение требований (elicitation) Анализ требований (analysis) Описание требований (specification). Валидация требований (validation) Управление требованиями (Requirements management) Управление изменениями (Change management) исправление и устранение недостатков Лекция №4. «Моделирование использования. Анализ проблемы» Повторение ( л.1)‹#›
  • 9. Problem definition Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 10. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 11. • «Эйнштейн однажды сказал, что правильная постановка задачи важнее даже, чем ее решение. • Для нахождения приемлемого или оптимального решения задачи важно знать, в чем она состоит. Как ни просто и прозрачно данное утверждение, чересчур многие специалисты в науке управления игнорируют очевидное. • Миллионы долларов расходуются ежегодно на поиск элегантных и глубокомысленных ответов на неверно поставленные вопросы». • К. Шеннон Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 12. Заказчик (Область проблемы) • Анализ проблемы • Выявление и понимание потребностей Исполнитель (Область решения) Определение системы • Управление границами системы • Уточнение и улучшение определения системы. Специфицирование Управление изменениями Лекция №4. «Моделирование использования. Анализ проблемы» Повторение ( л.1)‹#›
  • 13. • Анализ проблемы • Выявление и понимание потребностей • Определение системы • Управление границами системы • Уточнение и улучшение определения системы. Специфицирование • Управление изменениями Лекция №4. «Моделирование использования. Анализ проблемы» *Дин Леффингуэлл, Дон Уидриг Принципы работы с требованиями к программному обеспечению. Унифицированный подход Повторение ( л.1)‹#›
  • 14. Проблема Область решения Область проблемы Потребности Возможности Требования к ПО ПО Проектирование Тестиров ание Докуме нтация Глоссарий Лекция №4. «Моделирование использования. Анализ проблемы» Повторение ( л.1)‹#›
  • 15. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 16. • Для избежание проблемы “Да, …, Но ….” “Да, {Это удовлетворяет требованиям}, но {это не решает мою проблему}.” • Решаемая проблема - это источник, и она направляет решение – Анализ проблемы вначале значительно выгоднее, чем потом … • Результаты анализа будут использованы в дальнейшем  Формулирование проблемы  Основное действующее лицо – заказчик: “Мне необходимо …”  Формулирование требования  Основное действующее лицо – система: “Система обеспечивает …” Разработка требований Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 17. Лекция №4. «Моделирование использования. Анализ проблемы» Какая из идентифицированных причин имеет наибольший вклад? То, что заказчик называет проблемой Разработка требований ‹#›
  • 18. Лекция №4. «Моделирование использования. Анализ проблемы» • Kurt Levin - американский социальный психолог, автор концепции. • Force Field Diagram (Диаграмма силового поля) - модель, построенная на идее, что силы как способствуют, так и сдерживают изменения. • Система находится в динамическом «равновесии» при балансе сил. • Для проведения изменений, необходимо чтобы сумма «движущих сил» (driving forces), была больше суммы «сдерживающих сил» (restraining forces) ‹#›
  • 19. Формулировка проблемы Почему? И Как? Лекция №4. «Моделирование использования. Анализ проблемы» Помогает найти корень проблемы ‹#›
  • 20. Проблема (The problem of) Описание проблемы Затрагивает (Affects) Заинтересованные лица В результате чего (The impact of which is) Влияние проблемы Успешное решение должно (A successful solution would) Ключевые выгоды решения Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 21. Лекция №4. «Моделирование использования. Анализ проблемы» Moore ‘91 Для (заказчик) У которого (определение возможности или потребности ) (Название продукта ) (категория продукта) Который ( описание ключевых преимуществ использования). В отличие от (основная альтернатива) Наш продукт (описание дифференциации) ‹#›
  • 22. • • • • • • • • Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 23. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 24. Роль Персона Бизнес требование Потребность Возмож-сть Вариант использ-ния Харак-ка качества Функц-е требование Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 25. • Анализ Заинтересованных сторон • Персоны • Интервьюирование (Interviews) • Бизнес-моделирование (Business Modeling) • Семинар (Requirements Workshop) • Мозговой штурм (Brainstorming & Idea Reduction) • Прототипирование (Prototypes) • Контекстная диаграмма, Сценарии использования • Словарь Данных • Планирование извлечения требований • Вопросники (Questionnaires) • Ролевые игры (Role Playing) • Анализ спецификаций требований и другой документации заказчика Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 26. Определение, ключевые ЗС Stakeholders Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 27. Определение: индивидуумы или организации, которые активно вовлечены в проект, или чьи интересы могут быть затронуты в процессе или результате выполнения проекта. Они могут также оказывать влияние на цели и результаты проекта. Цели проектной команды: должна идентифицировать Заинтересованные стороны, определить их требования и ожидания, и до возможной степени управлять их влиянием на проект для обеспечения его успешности Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 28. Заинтересованные стороны Лекция №4. «Моделирование использования. Анализ проблемы» Ключевые польз-ли Конечные польз-ли Владельц ы БП СпонсорУправл. Партнер РП Координа тор проекта Управляющий комитет Исполнитель Заказчик Поставщ ик Члены команды Руков-ли Групп ‹#›
  • 29. Кто: Менеджер Исполнителя, осознающий куда ввязался, командир- кандидат в герои (возможно «посмертные») Интересы: убедить спонсора на максимально-достаточной бюджет, уговорить заказчика на постановку более простой задачи и договориться с ними о максимально приемлемом сроке Влияние: участвует в управлении проектом совместно с Менеджером проекта (Заказчик); Организует работы Исполнителя, контролирует работы Заказчика Обязательства: отвечает за достижение основных параметров проекта Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 30. Кто: разработчики, тестировщики, консультанты, которых очередной раз призвали послужить светлому делу Исполнителя Интересы: реализовать требования Заказчика за счет своих творческих и других способностей, в соответствии со своим видением Влияние: обеспечивает успешность функционирования новой системы за счет корректного выполнения своих обязательств Обязательства: участие в работе проектной группы, выполнение задач в соответствии с рабочим планом; регулярная отчетность о выполнении; участие в формировании требований, тестировании, обучении Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 31. Кто: эксперты в различных IT областях Интересы: работа такая, освоение новых знаний, углубление имеющихся Влияние: от правильного выбора методик, технологий, инструментария, оценки сложности продукта, алгоритмов зависит ход проекта Обязательства: помогает Менеджеру оценить техническую сложность проекта, оказывает консультации по всем тех. вопросам в ходе проекта, участвует в разработке архитектуры продукта. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 32. Кто: представитель руководства заказчика Интересы: получить запланированный эффект от проекта Влияние: принимает окончательное решения при спорных ситуациях; утверждает изменения основных параметров проекта (бюджеты, сроки), определяет цели и идентифицирует выгоды проекта Обязательства: участвует в управлении проектом и своевременном принятии решений, обеспечивающих успешное завершение проекта, утверждении подходов к выполнению проекта и приемке результатов Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 33. Кто: руководитель функционального подразделения, эксперт своей предметной области, детально понимающий БП предприятия в этой области и отвечающий за них Интересы: получить ПРОДУКТ, решающий необходимый круг задач Влияние: формирует требования к продукту, принимает результаты в своей функциональной области Обязательства: координирует работы по своему бизнес-процессу, формулирует требования к продукту, участвует в сборе и анализе и детализации требований, контролирует реализацию требований в ходе проекта, участвует в тестировании Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 34. Кто: специалист своей предметной области, детально понимающий БП предприятия в этой области, будущий ключевой пользователь продукта (Champion) Интересы: получить УДОБНЫЙ В ИСПОЛЬЗОВАНИИ продукт, решающий необходимый круг задач Влияние: формирует требования к продукту Обязательства: формулирует требования к продукту, участвует в сборе и анализе и детализации требований, контролирует реализацию требований в ходе проекта, участвует в тестировании Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 35. Кто: будущий непосредственный пользователь продукта Интересы: получить УДОБНЫЙ ПРОДУКТ, максимально упрощающий каждодневную работу Влияние: обеспечивает успешность функционирования новой системы за счет корректного использования продукта Обязательства: обучается новому продукту Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 36. Кто: «Могучая кучка»: Спонсор проекта, Управляющий партнер, Координатор проекта, Менеджер проекта, другие ЗС, обладающие властью Интересы: обеспечить нормальный ход проекта Влияние: принятие, либо утверждение, всех ключевых проектных решений Обязательства: инициирование старта проекта и фиксация его завершения Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 37. • ЭМПАТИЯ – Что говорит – Что думает – Что чувствует – Что делает • ИНТЕРПРЕТАЦИЯ – Чего хочет – Что для него важно • ФОКУС – В чем состоит проблема/задача – Что будет решением Поиск проблемы Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 38. • • • • • • • • Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 39. Разработаны Аланом Купером Архетип пользователя системы для помощи в принятии решения о возможностях, функциях и дизайне Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 40. На что обращать внимание? Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 41. Поиск проблемы • ЭМПАТИЯ – Что говорит – Что думает – Что чувствует – Что делает Лекция №4. «Моделирование использования. Анализ проблемы» • ИНТЕРПРЕТАЦИЯ – Чего хочет – Что для него важно • ФОКУС – В чем состоит проблема/задача – Что будет решением ‹#›
  • 42. • синтезируется на основе интервью реальных людей • Суммированное описание содержит – Поведение , – Цели, – Навыки, – Отношение Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 43. • Основные (primary) • Второстепенные (satisfy when we can) • Малозначительные (low-priority) • Затронутые(Affected) • Исключающие (Exclusionary) • Заинтерсованные лица (Stakeholders) » From Boxes and Arrows Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 44. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 45. • Документ уровня всей системы, дающий ответы на вопросы “Что ” и “Почему” для продукта или приложения • Содержит информацию о: – Потребностях пользователей – Целях и назначении – Рынке сбыта – Среде использования – Возможностях продукта ( Features) Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 46. Business case Business drivers Vision Лекция №4. «Моделирование использования. Анализ проблемы» Stakeholders & Needs Problem Statement Features ‹#›
  • 47. • Назначение (Документа) • Границы • Определение • Ссылки на другие документы • Обзор – Purpose – Scope – Definitions, Acronyms – References – Overview Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 48. • Описание возможности • Описание проблемы • Позиционирование продукта 2.1 Business Opportunity 2.2 Problem Statement 2.3 Product Position Statement Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 49. • Динамика рынка • Обзор заинтересованных сторон • Обзор пользователей • Пользовательская среда • Профили Заинтересованных лиц • Профили пользователей Лекция №4. «Моделирование использования. Анализ проблемы» 3.1 Market Demographics 3.2 Stakeholder Summary 3.3 User Summary 3.4 User environment 3.5 Stakeholder Profiles 3.6 User Profiles ‹#›
  • 50. • Перспектива продукта • Обзор возможностей продукта • Предположения и зависимости • Стоимость и ценообразование • 4.1 Product Perspective • 4.2 Summary of Capabilities • 4.3 Assumptions and Dependencies • 4.4 Cost and Pricing Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 51. • Возможности продукта • Ограничения • Атрибуты качества • 5. Product Features • 5.1 <aFeature> • 5.2 <another Feature> • 6. Constraints • 7. Quality Ranges Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 52. • Приоритеты • Другие требования к продукту • Требования к документации • Приложение 1 – Атрибуты возможностей 8. Precedence and Priority 9. Other Product Requirements 9.1 Applicable Standards 9.2 System Requirements 9.3 Performance Requirements 9.4 Environmental Requirements 10. Documentation Requirements 10.1 User Manual 10.2 Online Help 10.3 Installation Guides 10.4 Labeling and Packaging 11. Appendix 1 - Feature Attributes Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 53. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 54. 1. Concept Statement – внешний документ, который готовится для целей демонстрации потребителям и фиксации их реакций 2. Состав Concept Statement: 1. Неудовлетворенные потребности потребителей 2. Как работает продукт 3. Фичи продукта 4. Преимущества для потребителя Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 55. Concept statement Customer & Stakeholder Problem Statement Solution Vision Concept statement Opportunity statement Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 56. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 57. Написание Concept Statement для тестирования Неудовлетворенные потребности потребителей Как работает продукт Возможности продукта Преимущества для потребителя Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 58. • • • • • • • • Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 59. Что мешает сделать все правильно ? Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 60. Неопре деленн ость Функци ональн ый подход Эффект ряби Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 61. Слож ность Скурпул езность анализа Аналитическ ий паралич Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 62. • Сценарное планирование метод стратегического планирования, позволяющий управлять неопределенностью будущего. • Эту концепцию в мире бизнеса популяризировала группа планировщиков из Shell, которая смогла “предсказать” нефтяной кризис 1973г. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 63. Движущие силы (Driving forces) Предопределенные элементы (predetermined elements) Ключевых неопределенности(key uncertainties) Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 64. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 65. Планирование действий по Максимизация положительного эффекта Избежание фатальных Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 66. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 67. • В 1996 году Айвар Джекобсон впервые сформулировал технику визуального моделирования для специфицирования сценариев использования при разработке ПО. Изначально им использовался несколько терминов usage scenarios и usage case, но со временем устоялось использование термина use case. • Благодаря целой плеяде методистов и в первую очередь Алистеру Коберну в течение 1990-х сценарии использования стали ключевой методологией специфицирования функциональных требований Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 68. нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (англ. Actors). http://ru.wikipedia.org/ Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 69. Цель: “Разместить заказ” sc1 sc2 sc6 sc7 ... S sc3 (Успех) (Провал ) S S F S F S S F F F F Получить ... кредит ... резерв sc4 sc5 Подцель: *Коберн Алистер Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 70. • Один основной сценарий «Ура-сценарий» • Множество альтернативных – Типичные варианты Например: Снятие наличных не с того счета – Редкие варианты Например: Снятие более 1–ого млн – Исключительные варианты (Ошибки) Например : Ящик с деньгами пуст Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 71. Бизнес сценарий (Business use case ) Системный сценарий (System use case ) Использует не техническую терминологию Описывает поведение системы на языке пользователя Рассматривает систему в качестве «черного ящика» Определяет функцию которую система предоставляет пользователю По сути представляет собой описание «Бизнес процесса» по достижении цели уровня бизнеса/пользователя По сути представляет собой описание достижения цели уровня приложения Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 72. • В 2003 году Л. Басс, П. Клементс, Р. Кацман в Книге Software Architecture in Practice предложили подход трансформации Атрибутов качества системы в Сценарии Атрибутов Качества Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 73. Каркас приложен ия Бизнес сценарии Сценарии использования Архитектурные сценарии Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 74. Хижина Дом советов Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 75. < Главное Скорость Главное ? --> Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 76. • Методология объединяет : – Пользователя системы (актера) – Дерево целей – Связанные между собой общей целью функциональных требований к системе • В результате грамотного применения позволяет : – Поместить функциональные требования в простой и понятный для конечного пользователя текстовый формат – Сгруппировать все сценарии достижения и не достижения цели – Сформировать основу для документирования и прослеживания не функциональных требований к системе не «завязанную» на реализацию 2-76 Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 77. Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 78. Актер(Actor): это кто-то или что-то взаимодействующее с системой Сценарий использования(Use case): Набор экземпляров сценария, где каждый экземпляр это последовательность действий, выполняемых актером и системой, приводящая к получению актером наблюдаемого результата(observable result) или ценности (Value) Actor Use Case Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 79. Ассоциация коммуникации (Communicates-association): ассоциация между актером и сценарием, указывающая на их взаимодействие Стрелка : показывает кто начинает взаимодействие Лекция №4. «Моделирование использования. Анализ проблемы» ‹#› Actor Use Case Actor 2
  • 80. Bank Consortium Bank Customer Deposit Funds Withdraw Cash Transfer Funds Cashier Maintain ATM Maintenance Crew Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 81. Лекция №4. «Моделирование использования. Анализ проблемы» Transmit request Send back approval Dispense cash Ask for Receipt Printed receipt Return bank card Insert Card Approve card Enter PIN Approve PIN Enter account, amount Withdraw Cash Bank Consortium Bank Customer ‹#›
  • 82. 1. Идентифицируйте заинтересованных лиц (stakeholders) 2. Определите цели заинтересованных лиц (бизнес сценариев) по отношению к системе 3. Сделайте краткое описание каждого бизнес сценария Лекция №4. «Моделирование использования. Анализ проблемы» Как правило выполняется на этапе формирования концепции для крупной системы или решения ‹#›
  • 83. 1. Определите действующих лиц (actors), а затем сценарии, в которых они участвуют. 2. Определите внешние события, на которые реагирует система, а потом свяжите эти события с определенными действующими лицами и сценариями использования. 3. Определите сценарии использования на основе существующих функциональных требований. 4. Сделайте краткое описание каждого сценария. 1-й и 2-й шаги могут чередоваться местами Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 84. 1. Определите требования переходного периода (transition requirements) и свяжите со сценариями использования и действующими лицами 2. Определите характеристики качества (Quality Attributes) и свяжите их свяжите со сценариями использования и действующими лицами На данном шаге необходимо идентифицировать ограничения и требования, которые накладывает решение (solution domain) Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 85. 1. Свяжите отношениями зависимости <<depends>> Бизнес и системные сценарии 2. Свяжите отношениями зависимости системные и архитектурные сценарии 3. Определите приоритет и очередность разработки (Road Map) для полученной модели 4. Уберите «висящие» системные сценарии или найдите для них владельцев Цель данного шага идентифицировать пропущенные или «лишние» сценарии использования Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 86. Сортировка и фильтрация Архитектурные сценарии Микрооперации Бизнес контекст Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 87. Полное описание (Fully dressed use case) Формальный документ основанный на детальном шаблоне Свободное описание (Casual use case/User story) Состоит из нескольких абзацев суммирующих сценарий Краткое описание (Brief) Состоит из нескольких предложений суммирующих сценарий Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 88. Полное описание (Full dressed ) Введение Связанные документы <Сценарий > Действующее лицо Предусловие Ход событий Основной Альтернативный Экраны Эскиз Описание элементов История изменений Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 89. Выделение требований (elicitation) Анализ требований (analysis) Описание требований (specification). Валидация требований (validation) Управление требованиями (Requirements management) Управление изменениями (Change management) исправление и устранение недостатков Лекция №4. «Моделирование использования. Анализ проблемы» Повторение ( л.1)‹#›
  • 90. • • • • • • • • Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 91. Часть 1 Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›
  • 92. Безуглый Дмитрий bdl@system-approach.ru Лекция №4. «Моделирование использования. Анализ проблемы» ‹#›