Содержание
- 2. Становление аналитика Знание предметной области — ценное качество для эффективного аналитика. Аналитику, разбирающемуся в бизнесе, легче
- 3. Бывший пользователь Во многих корпоративных отделах информационных технологий есть сотрудники, пришедшие в бизнес-аналитики из обычных пользователей.
- 4. К сожалению, бывшие пользователи зачастую имеют весьма поверхностные знания о разработке ПО и взаимодействии с технически-
- 5. Бывший разработчик Менеджеры проекта, которым не хватает профессионального аналитика требований, зачастую ожидают, что его функции будет
- 6. Разработчику, ставшему аналитиком, вероятно, придется более подробно ознакомиться с предметной областью бизнеса. Однако разработчики легко переходят
- 7. Профильный специалист Аналитик требований, будучи экспертом в предметной области, за- частую определяет требования к системе, которые
- 8. Создание атмосферы тесного сотрудничества Иногда в проектах по разработке ПО возникают напряженные отношения между аналитиками, разработчиками,
- 9. Аналитик требований — основное лицо, отвечающее за обеспечение тесного доброжелательного сотрудничества с представителями пользователем и прочими
- 10. Определение образа и границ проекта Как мы говорили ранее, бизнес-требования составляют высший уровень абстракции в цепи
- 11. Признаком того, что бизнес-требования недостаточно ясно определены, можно считать ситуацию, когда определенные функции сначала включают в
- 12. Определение образа продукта вплоть до бизнес-требований Образ продукта (product vision) выстраивает работу всех заинтересованных лиц в
- 13. Образ – то есть весь продукт. Он будет изменяться относительно медленно при определении со временем стратегии
- 14. Например, федеральное правительственное агентство получило долгосрочный заказ, рассчитанный на пять лет, на разработку массивной ИС. Команда
- 15. Образ продукта Версия 1.0 оговоренного объема Версия 1.1 оговоренного объема Версия 1.2 оговоренного объема Версия n
- 16. Конфликтующие бизнес - требования Бизнес-требования, собранные из разных источников, могут конфликтовать. Представьте себе компьютер со встроенным
- 17. Разработчику иногда хочется сделать киоск высокотехнологичным и увлекательным для покупателей. Продавцу же нужна простая и полностью
- 18. Кроме того, тот (или те), кто финансирует проект, проекта должен разрешать конфликты различных заинтересованных в проекте
- 19. Бизнес-требования и варианты использования Бизнес-требования определяют и набор бизнес-задач (вариантов ис- пользования), которые позволяет выполнять приложение
- 20. Бизнес-требования влияют на приоритеты реализации вариантов использования и связанные с ними функциональные требования. На- пример, такая
- 21. Документ об образе и границах проекта Документ об образе и границах (vision and scope document) собирает
- 22. Владельцем документа об образе и границах считается тот, кто финансирует проект или несет аналогичную ответственность. Аналитик
- 24. Бизнес-требования Проекты выпускаются с полным убеждением, что новый продукт для кого-то сделает мир лучше. Бизнес-требования описывают
- 25. Исходные данные Суммирует обоснование и содержание нового продукта. Здесь помещают общее описание предыстории или ситуации, в
- 26. Возможности бизнеса Для коммерческого продукта описывают существующие рыночные возможности и рынок, на котором продукту придется конкурировать
- 27. Бизнес-цели и критерии успеха Суммирует важные преимущества бизнеса, предоставляемые продук- том, в количественном и измеряемом виде.
- 29. Потребности клиентов или рынка Опишите потребности типичных покупателей или целевых сегменты рынка, включая потребности, которые не
- 30. Бизнес риски Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта.
- 31. Образ решения В этом разделе документа определяется стратегический образ системы, позволяющей выполнять бизнес-задачи. Этот образ обеспечивает
- 32. Положение об образе проекта Составьте сжатое положение об образе проекта, обобщающее долго- срочные цели и назначение
- 33. Основные функции Назовите или пронумеруйте каждую основную функцию нового продукта или возможность, предоставляемую пользователям, уникальным последовательным
- 34. Предположения и зависимости Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный
- 35. Масштабы и ограничения проекта Когда химик изобретает новую химическую реакцию, которая преобразует один тип химиката в
- 36. Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не
- 37. Объем первоначальной версии Обобщает основные запланированные функции, включенные в первоначальную версию продукта. Опишите характеристики качества, которые
- 38. Объем последующих версий Если вы представляете поэтапную эволюцию продукта, укажите, какие функции будут отложены и желательные
- 39. Ограничения и исключения Определение границы между тем, что входит и выходит за границы проекта, — отличный
- 40. Бизнес-контекст В этом разделе обобщаются некоторые бизнес-проблемы проекте, включая профили основных категорий заинтересованных лиц и приоритеты
- 41. Профили заинтересованных лиц Заинтересованными в проекте лицами (stakeholders) называются отдельные лица, группы или организации, которые активно
- 42. основная ценность или преимущество, которое продукт принесет заинтересованным лицам и то, как продукт удовлетворит покупателей. Ценность
- 43. Приоритеты проекта Чтобы принимать эффективные решения, заинтересованные лица должны договориться о приоритетах проекта. Один из подходов
- 44. Задача менеджера проекта — настроить те факторы, которые пред- ставляют собой степени свободы для достижения ключевых
- 45. Операционная среда Опишите среду, в которой будет использоваться система, и определите важнейшие требования к доступности, надежности,
- 46. Пользователи расположены далеко (географически) или близко друг от друга? В скольких часовых поясах работают ваши пользователи?
- 47. Контекстная диаграмма Уточнение рамок определяет границу и связи системы, которую мы разрабатываем, со всем остальным миром.
- 48. КАК ОТОБРАТЬ ПОЛЬЗОВАТЕЛЕЙ ДЛЯ РАБОТЫ НАД ПРОЕКТОМ Критический взгляд клиента на разрабатываемое ПО крайне важен для
- 49. Вовлечение клиентов в работу над проектом — единственный способ избежать их претензий и разочарования, когда они
- 50. Желания пользователей не всегда совпадают с функциональностью, необходимой для выполнения задач с помощью конкретного продукта. Чтобы
- 51. Основные источники получения информации о потребностях клиентов Способы и источники получения информации от клиентов зависят от
- 52. Опросы потенциальных пользователей и дискуссии с ними Самый очевидный способ выяснить потребности потенциальных пользователей нового программного
- 53. Документы, где описан уже работающий или конкурирующий продукт Эти документы могут также содержать корпоративные или отраслевые
- 54. Спецификации требований к системе Для продукта, включающего программные и аппаратные компоненты, создается спецификация требований к системе,
- 55. Отчеты об ошибках и претензии к возможностям работающей системы Персонал внутрикорпоративной и выездной службы поддержки —
- 56. Маркетинговые исследования и опросы пользователей Опросив массу потенциальных пользователей продукта, вы получите кучу информации. Проконсультируйтесь с
- 57. Наблюдение за пользователями на рабочих местах Наблюдая «один рабочий день из жизни пользователя», аналитик выявляет особенности
- 58. Сценарий анализа задач пользователей Определив, какие задачи пользователю требуется выполнять средствами системы, аналитик должен выработать необходимые
- 59. События и реакция на них Перечислите внешние события и соответствующую реакцию системы на них. Данный способ
- 60. Классы пользователей Помимо всего прочего, пользователей продукта можно подразделять по таким признакам: по частоте использования продукта;
- 61. На их основе формируются классы пользователей. Некоторых сотрудников можно отнести к нескольким классам. Так, администратор иногда
- 63. Очень важно поделить пользователей на классы по их географическому положению, виду бизнеса, которым занимается компания, или
- 64. Одни классы пользователей для вас важнее других. Когда вы принимаете решения о приоритетах или пытаетесь найти
- 65. У каждого класса пользователей есть свой набор требований, сформировавшийся в ходе выполнения задач. Кроме того, появляются
- 66. Это может показаться странным, однако классы пользователей не обязательно состоят из людей. В качестве дополнительных классов
- 67. В самом начале работы над проектом необходимо определить и охарактеризовать различные классы пользователей, чтобы узнать у
- 68. Представители пользователей При разработке каждого типа проекта, включая корпоративные информационные системы, коммерческие приложения, комплексные решения, интегрированные
- 69. Сторонники продукта Во всех крупных проектах принимают участие несколько наиболее активных представителей пользователей, которые помогают формулировать
- 70. Каждый сторонник продукта - это основной посредник между членами отдельного класса пользователей и аналитиком требований. В
- 71. Сторонники продукта, приглашенные со стороны При разработке коммерческого ПО иногда трудно найти сторонников продукта вне компании.
- 72. Если сторонник продукта — бывший пользователь или увлеченно играет роль пользователя, таковым не являясь, опасайтесь, что
- 73. Чего следует ожидать от сторонника продукта Чтобы сотрудничество со сторонниками продукта оказалось успешным, задокументируйте, что именно,
- 74. Возможные обязанности сторонника продукта
- 75. Возможные обязанности сторонника продукта
- 76. Возможные обязанности сторонника продукта
- 77. Как «продать» идею о необходимости привлечения сторонника продукта Будьте готовы встретить сопротивление, когда вы предложите привлечь
- 78. Отделив бизнес-требования от требований пользователей, вы смягчите эти препятствия. Будучи реальным пользователем, сторонник продукта принимает решения
- 79. В какие ловушки можно угодить, привлекая сторонников продукта Модель привлечения сторонника продукта хорошо зарекомендовала себя во
- 80. Некоторые менеджеры изменяют решения, принятые квалифицированным и официально назначенным сторонником продукта. Возможно, у менеджера в последнюю
- 81. Сторонник продукта, забыв, что он представляет других клиентов, озвучивает только собственные требования: конечно же, ему не
- 82. Сторонник продукта, не имеющий четкого представления о новой системе, может уступить решение важных вопросов аналитику. Если
- 83. Из-за нехватки времени опытный пользователь назначает сторонником продукта менее квалифицированного коллегу. Это может привести к давлению
- 84. Кто принимает решения Кто-то должен устранять конфликты между требованиями разных классов пользователей, сглаживать противоречия и решать
- 85. Ниже описаны некоторые конфликты, которые могут возникнуть в ходе работы над проектами, а также способы их
- 86. Если отдельные пользователи не могут прийти к согласию при определении требований, решение принимают сторонники продукта. Суть
- 88. Скачать презентацию