Your SlideShare is downloading. ×
Разработка требований и Проектирование интерфейсов
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Разработка требований и Проектирование интерфейсов

3,738
views

Published on

Published in: Business

2 Comments
21 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,738
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
110
Comments
2
Likes
21
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. Разработка требований и Проектирование интерфейсов Как они связаны? Денис Бесков #uidesignersmeetup 8 октября 2009
  • 2. Программа вечера
    • Часть 1:
    • Требования: определение, назначение, виды
    • Бизнес-аналитик / системный аналитик: в чём разница?
    • Процесс разработки требований: основные фазы, роли
    • Связь требований и интерфейсов
    • Часть 2:
    • Когда нужны аналитик и проектировщик ПИ?
    • Коммуникация аналитик < - > проектировщик
    • Выстраивание работы с требованиями
    • Кто может выполнять роль аналитика?
  • 3. ЧАСТЬ 1
  • 4. Что такое требование?
    • Утверждение о свойствах продукта
    • Чужое утверждение = требование
    • Ваше утверждение = решение
  • 5. Зачем нужны требования?
    • Определять свойства продукта
    • Фиксировать договорённости
    • Служить основой для планирования, проектирования интерфейсов, архитектуры, тестирования и документирования
    • Снижать риски неуспеха проекта
  • 6. Какие требования бывают?
    • По уровню:
    • Бизнес-требования
      • Vision, BRS, MRD, PRD (до X0 единиц)
    • Пользовательские требования
      • URS (?), Functional Specification (до X0 единиц)
    • Технические требования
      • SRS, Technical Specification (до X 0 0 единиц)
    • По категории:
    • Функциональные
    • Нефункциональные
  • 7. Кто такой бизнес-аналитик?
    • Изучает организацию бизнеса ( AS-IS )
    • Выявляет проблемы и их источники
    • Помогает ЗЛ сформулировать цели
    • Формирует требования к организационным изменениям ( TO-BE )
    • … и бизнес-требования к техническим системам, в случае необходимости
  • 8. Пример работы бизнес-аналитика
    • В организации периодически возникают конфликты и срывы выполнения заказов
    • БА выяснил, что это просходит по причине отсутствия согласованной процедуры выполнения заказов
    • БА изучил пожелания, разработал и согласовал и обкатал новый регламент выполнения заказов
    • Бизнес-показатели компании улучшились
  • 9. Кто такой системный аналитик?
    • Изучает бизнес-требования
    • Изучает технологии
    • Изучает или формирует пользовательские требования
    • Создаёт технические требования на основе бизнес- и пользовательских
  • 10. Пример работы системного аналитика
    • На вход команде разработки среди прочих поступило бизнес-требование , что система должна удовлетворять Sarbanes-Oxley Act / Закону о персональных данных
    • Системный аналитик изучил законодательство и разработал пользовательские (АРМ администратора) и технические требования, обеспечивающие выполнение данного бизнес-требования
  • 11. Процесс разработки требований
  • 12. Общий контекст процессов
  • 13. Связь требований и интерфейсов
    • Пользовательские требования — основной источник информации для проектирования интерфейсов
    • Бизнес- и технические требования служат ограничениями для пользовательских требований
  • 14. ЧАСТЬ 2
    • Выстраивание работы в области
    • требований в разных ситуациях
  • 15. Треугольник ценностей и интересов Б-П-Т Бизнес (деньги, гномы) Пользователь (люди, эльфы) Технологии (штуки, тролли) Бизнес-аналитик Архитектор Маркетолог Проектировщик ПИ Инженер-эргономист Системный аналитик Менеджер C- продукта Менеджер проекта Предприниматель Психолог Хакер, гик Менеджер Разработчик Менеджер B- продукта Тестировщик Социолог Коммьюнити-менеджер Верстальщик Техпис Кадровик Инвестор Биржевой игрок
  • 16. Категории проектов
    • На чужого дядю — заказная разработка, системная интеграция (~60 % рынка , soft, B2B)
    • На нашего дядю для целей организации — внутренняя разработка (~ 3 0%, soft, B2B)
    • На нашего дядю, представляющего интересы множества других дядь — продуктовая разработка (~10%, веб )
      • B2B , B2C , G2C
  • 17. Эффективная коммуникация аналитик/проектировщик
    • Понимание содержания работы друг друга
    • Общий язык
    • Профессиональное уважение и признание важности работы друг друга
    • Чёткое разделение деятельности, как вариант:
      • UD: User Research, User Stories, GUI Vision, GUI Mockups
      • SA: Domain Modeling, Use Case Design, System Modeling, Nonfunctional Reqs, …
    • Сотрудничество при параллельной работе
    • Взаимное рецензирование артефактов
  • 18. Команда 5 человек
    • Состав
    • Менеджер, Дизайнер, 2 Разработчика, Тестировщик
    • Условия
    • Выделенного системного аналитика нет
    • Решение
    • Наиболее вероятный кандидат — менеджер
    • Второй кандидат — дизайнер интерфейса
  • 19. Команда 15 человек
    • Состав
    • Leads (7): Менеджер проекта , Аналитик, GUI Designer , Архитектор , Dev, Testing, Doc&Loc
    • Team Body (8): 4 Devs, 2 Testers, 2 Tech Writers
    • Решение
    • Аналитик вполне уместен
  • 20. Команда 25 человек
    • Состав
    • Leads (7): Project Manager, System Analyst ,
    • GUI Designer , Architect, Dev, Testing, Doc&Loc
    • Team Body (18): 2 Analysts, 2 UI Designers, 7 Devs,
    • 4 Tests, 3 TechWriters
    • Решение
    • Команда аналитиков
  • 21. Кто может выполнять роль системного аналитика?
    • Менеджер проекта
    • Проектировщик интерфейса
    • Тестировщик
    • Архитектор
  • 22. Какой объём требований нужен?
    • Рентабельный
    • «Идеального ТЗ» не существует и оно стоит больше продукта
    • Степени полноты, исходя из бюджета и рисков
    • Концепция
    • Ключевые ф.требования в форме пользовательских историй + Технические ограничения
    • Детальные пользовательские требования в форме способов применения
    • Детальные технические требования

×