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

1. ТРЕБОВАНИЯ К
ПРОГРАММНЫМ
СИСТЕМАМ
ДЗЮБА ДМИТРИЙ ВЛАДИМИРОВИЧ, СТАРШИЙ
ПРЕПОДАВАТЕЛЬ КАФ. 806
DDZUBA@YANDEX.RU

2. Что такое требования?
Согласно IEEE Standard Glossary of Software Engineering Terminology это
1.Условия или возможности необходимые пользователю для решения задачи или достижения цели
2.Условия или возможности, которые должны быть предоставлены системой или системным
компонентом для удовлетворения требованиям контракта, стандарта, спецификации или другого
формально документа
3.Документальное представление условий или возможностей как в пункте 1 или 2
2
ТРЕБОВАНИЯ – ЭТО ОБЩЕЕ ПОНИМАНИЕ РЕШАЕМЫХ ЗАДАЧ

3. Зачем нужны требования?
•Консолидация общего понимания требований заказчика.
•Разбиение сложных требований на группы, для лучшего понимания
проекта.
•Служит основой для планирования проекта.
•Служит соглашением между командой разработки и заказчиком.
3
ТРЕБОВАНИЯ ДОЛЖНЫ БЫТЬ ДОКУМЕНТИРОВАННЫ

4. Исправление ошибок на этапе
требований – самое дешевое
4
СОЗДАНИЕ ТРЕБОВАНИЙ ПОЗВОЛЯЕТ ПРОТЕСТИРОВАТЬ ПОНИМАНИЕ ЗАДАЧИ

5. Из чего они состоят?
5

6. Какими должны быть хорошие
требования?
1. Полные
2. Нацеленные на решение поставленной задачи
3. Осуществимые
4. Нужные
5. Приоритезированные
6. Исключающие двоякого толкования
6

7. Какие этапы есть в создании требований к
программному обеспечению?
1. Определение классов пользователей (Actors)
2. Определение потребностей каждого класса пользователя (Business Goal)
3. Понимание задач и бизнес целей пользователей (Use Cases)
4. Анализ информации полученной от пользователей (функциональных требований,
нефункциональных требований, бизнес-правил, предлагаемых решений)
5. Назначение требований компонентам программного обеспечения
6. Понимание важности атрибутов качеств системы
7. Выяснение приоритетов в реализации (функциональных и нефункциональных)
8. Создание документа с требованиями и модели системы
9. Рецензирование документа для достижения общего понимания между заказчиком и
исполнителем
7

8. СБОР ИНФОРМАЦИИ
8

9. Методы сбора информации
Существуют несколько основных методов
сбора информации:
1. наблюдение за действиями пользователя
(shadowing);
2. интервьюирование (inteviewing);
3. опросы (surveys);
4. обучение, проводимое пользователями
(user instruction);
5. создание прототипов (prototyping);
Точка зрения
Концептуальные требования пишутся с
точки зрения заказчика (так их проще
документировать со слов экспертов).
9

10. Наблюдение за действиями
пользователя
Вы наблюдаете за тем, как пользователь выполняет свои задачи в реальной рабочей среде, а
также по ходу задаете ему любые необходимые вопросы. Вы должны стать «тенью»
пользователя на время, когда он выполняет свою повседневную работу. Таким образом вы
получаете информацию из первых рук, «в контексте», и выясняете цели той или иной задачи.
Чтобы получить максимум информации, необходимо «вытягивать» из пользователя как можно
больше деталей и подробностей о том, почему задача выполняется так, а не иначе.
Наблюдение бывает пассивным или активным.
◦ В первом случае вы просто наблюдаете и прислушиваетесь к пояснениям, которые пользователь,
возможно, даст.
◦ Во втором вы активно задаете вопросы, а иногда и самостоятельно выполняете некоторые задачи.
Наблюдение за пользователями — хороший способ разобраться, чем сотрудник занимается изо
дня в день. Но вам вряд ли удастся увидеть весь объем работы, так как не все задачи
выполняются в одном сеансе. Например, бухгалтеры готовят отчеты только в конце месяца,
разработчики пишут отчеты о ходе работ раз в неделю, а менеджеры собираются на планерки
раз в две недели.
10

11. Примеры вопросов, задаваемых при
наблюдении за пользователями
1. Как пользователь структурирует свою работу?
2. Какие решения он принимает в начале и при завершении задачи?
3. Как пользователи выполняют свою работу в текущей реализации?
4. Как часто система мешает выполнять задачи?
5. Как воздействуют на пользователей перерывы в работе? В состоянии ли они продолжить работу с
того же места, на котором их прервали?
6. Со сколькими сотрудниками взаимодействует пользователь при выполнении той или иной
операции?
7. Какие усовершенствования внес пользователь, чтобы упростить выполнение задачи?
8. Возможна ли модификация тех или иных стадий выполнения задачи? Каковы возможности и от
каких условий они зависят?
11

12. Постарайтесь найти ответы сами
1. Как в настоящее время пользователи выполняют свои задачи?
2. Как повысить эффективность процессов? Обязательно ли все выполняемые вручную
задачи должны возлагаться на автоматизированное решение?
3. Какие из связанных задач могут повлиять на структуру приложения?
4. Каковы критерии производительности?
5. Какие функции используются часто, а какие реже?
6. Что пользователям нравится в существующей системе, а что нет?
7. Как снизить затраты на обучение и поддержку?
8. Каковы характеристики и предпочтения пользователей?
12

13. Интервьюирование
Наблюдение — эффективное средство для выявления того, что же происходит в
компании, однако оно не всегда обеспечивает всю необходимую информацию.
Например, оно не очень годится для сбора информации о таких задачах, как
менеджерские операции, долговременные операции, растянутые на недели,
месяцы или годы, а также процессы, почти или совсем не требующие заметного
вмешательства человека. К последним относится работа службы
автоматической оплаты счетов, поддерживаемая финансовыми организациями.
Для сбора информации о подобной деятельности и процессах необходимы
интервью.
Интервью — это встреча один на один члена проектной команды и
пользователя или действующего субъекта (stakeholder). Качество информации,
собранной командой зависит от навыков как интервьюирующего, так и
интервьюируемого.
Интервьюер, сумевший «втереться в доверие» узнает много нового о
затруднениях и ограничениях существующего решения. Интервью дает
возможность задать массу вопросов по темам, которые невозможно раскрыть
средствами простого наблюдения за повседневной работой сотрудников.
13

14. Что нужно помнить при интервью
1. Начинайте с общих (не специализированных) вопросов и стройте беседу так, чтоб
интервьюируемый думал обо всех выполняемых им задачах и информации, которую он
способен вам сообщить;
2. На основании ответов на вопросы попросите интервьюируемого изложить наиболее
общие задачи и разбить их на более мелкие;
3. Особо попросите выделить информацию, которая обычно отсутствует, а так же
возможные альтернативные пути решения задач;
4. Пройдитесь по заданным вопросам несколько раз, повторно спрашивая
интервьюируемого, не упустили ли вы что-то важное;
5. Попросите интервьюируемого изложить свои мысли, как можно улучшить ситуацию, но
ни в коем случае не предполагайте, что предлагаемое решение правильное.
14

15. Примеры вопросов
◦ С какими проблемами вы сталкиваетесь при выполнении своих задач?
◦ В какой помощи вы нуждаетесь, работая удаленно?
◦ Есть ли у вас какие-либо потребности кроме задокументированных?
◦ Какие бизнес-политики помогают (или, наоборот, мешают) вам
выполнять свои обязанности?
◦ Какие люди или документы снабжают вас информацией, необходимой
для выполнения работы?
◦ Какие ешё пользователи или системы влияют на вашу работу (например,
сторонние поставщики или специалисты службы поддержки)?
15

16. Правила Глеба Жеглова
1.Разговаривая с людьми всегда
улыбайся. Люди это любят.
2.Будь к человеку внимателен и старайся
подвинуть к разговору о нем самом.
3.Найди тему, которая ему интересна.
4.Проявляй к человеку искренний
интерес...
16

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

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

19. Обучение, проводимое
пользователями
Пользователи обучают вас выполнению своих задач. Вы принимаете участие в действиях
пользователя и изучаете каждый этап процесса с его точки зрения. Вы также получите знания,
которые пользователь приобрел с течением времени и которые не представлены в артефактах
или системах.
Инструктирование потребует значительных временных затрат, если исследуемый процесс
довольно длительный. Этот метод может не дать результатов, если пользователь не умеет или
не способен обучать других. Кроме того, различные сотрудники могут по-разному выполнять
одни и те же задачи. Поэтому вы должны собрать информацию у многих пользователей.
Когда пользователи обучают вас выполнению задач, вы получаете информацию, которая
позволяет определить:
◦ дизайн пользовательского интерфейса;
◦ необходимость в обучении для поддержки существующих и будущих процессов;
◦ критерии производительности системы;
◦ воздействие, которое оказывает на выполнение задачи физическая среда.
19

20. Создание прототипов
20

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

22. Стратегия сбора информации
До сбора информации необходимо определить его стратегию: определить круг
пользователей, составить вопросы и выбрать подходящие методы сбора информации.
Определяя стратегию сбора информации, руководствуйтесь следующими вопросами:
◦ какие источники необходимо использовать для добывания информации;
◦ какую информацию необходимо собрать;
◦ какие методы сбора информации вы планируете использовать и к каким источникам тот или иной
метод применим;
◦ как предполагается хранить собираемую информацию;
◦ сколько времени вы планируете собирать информацию?
Используйте несколько методов сбора информации. Если вы положитесь лишьна один-
единственный метод сбора, полученная картина бизнеса может оказаться неполной.
Комбинируя различные методы, удается преодолеть недостатки, присущие каждому в
отдельности
22

23. 23
Какие проблемы могут возникать?
Различное толкование терминов в требованиях.
◦ Словари терминов.
Отсутствие нефункциональных требований.
◦ Надежность. Заказчик всегда хочет получть 100% надежную программу. В большинстве случаев это
невозможно (сбои аппаратуры, зависимость от внешних систем).
◦ Производительность. Даже если требования к производительности не выдвигаются, все равно они
есть. Следует сразу определить допустимые приделы.
◦ Безопасность. В случае если у программы более одного пользователя, то должны быть требования к
безопасности (кстати, если пользователь один - это то же требование к безопасности).
◦ Usability. Квалификация персонала заказчика сильно накладывает ограничение на Usability. Возможно
персонал уже привык работать с определенным типом пользовательского интерфейса и даже более
простой интерфейс будет непонятен.
◦ Модифицируемость. Следует сразу понять в какую сторону система будет развиваться, как часто будут
приходить запросы на изменение системы. Какие эти запросы будут?
◦ Тестируемость. Будет ли заключаться договор о тех. поддержке? С какой скоростью нужно
обнаруживать и исправлять сбои?

24. 24
Checklist
Отсутствие бизнес-целей. Какую выгоду принесет разрабатываемый функционал?
Описание деталей реализации. Нельзя смешивать требования и реализацию.
Описание только с помощью предикатов. Описание процесса намного понятнее чем много не
связанных условий. Это не значит, что не должно быть универсальных правил.
Недостаточное описание интерфейсов. Если есть важная информация, касающаяся взаимодействия
системы с внешним миром, она должна быть документирована.
Недостаточные требования. Требования нужно постоянно дополнять и актуализировать.
Дублирующие требования. Одно требование – только в одном месте.
Противоречивые требования. Одно требование не должно противоречить с другим.
Зависимые требования. Если одно требование вытекает из другого, эта связь должна быть
документирована

25. Практическое занятие
Занятие аналогично детской игре «Испорченный телефон». Учащиеся по очереди передают
один и тот же текст от одного другому. Цель состоит в том, что бы последний учащийся
рассказал исходный текст наиболее близко к тексту.

26. REQUIREMENT
MANAGEMENT
26

27. Требования – это живое существо,
меняющееся в течении проекта
27

28. 28
Разработка концептуальных
требований. Стабилизация.
План коммуникаций. Необходимо определить график встреч, по рассмотрению спорных вопросов в требованиях.
Ведение версий требований и историй изменения требований.
Ведение матрицы зависимости требований (одно требование может порождать другое).
Свободный доступ к единой (сетевой) версии требований.
Совет по согласованию требований. Необходимо создать совет по управлению требованиями. В этот совет будут входить люди, которые
будут проводить:
◦ Анализ требований. Так же необходимо проводить анализ требований, на предмет их влияния на весь проект и другие требования. Это
необходимо для оценки непротиворечивости требований, а так же для определения ресурсоемкости их реализации.
◦ Выделение главных требований и бизнес-целей проекта (определение приоритета требований). Разбор сценариев и выяснение их
приоритетов (голосование).
◦ Принятие решения о реализации или отклонении требований.
◦ В какой версии продукта данное требование будет внесено.
Этапы согласования требований.
◦ Внутреннее согласование внутри проектной команды.
◦ Согласование с заказчиком.

29. Создание требований
в Enterprise Architect
29

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

31. 31
Пример документа с требованиями [1/20]
Цель создания системы
◦ Содержание:
Данный раздел содержит описание цели создания системы.
◦ Бизнес цели (сконцентрировано на функционале). Может быть короткое описание запрашиваемого
функционала, например реализация интернет-магазина по продаже книг.
◦ Цели дизайна (сконцентрированы на атрибутах решения). Уменьшение ошибок операторов, повышение
производительности.
◦ Обоснование:
Обычно документы описывающие требование к системам - это довольно большие
документы. Читателю тяжело понять суть проекта, не читая весь документ. Данный
раздел позволяет понять основную идею, не читая весь документ.

32. Диаграммы Requirements
• Для фиксации требований, бизнес-
правил и бизнес-целей. Будем
использовать диаграммы с типом
Requirements.
• Элемент Requirement – по сути
упрощенная версия Класса (из
диаграммы классов), которая содержит
только описание требования (но не
содержит атрибутов или операций).

33. Пример требований к системе
req Требования заказчика
Общие
требования
Требования к
атрибутам
встречи
Геолокация
Единство
времени Границы
проекта

34. 34
Пример документа с требованиями [2/20]
Описание текущего состояния системы
◦ Содержание:
Описывается то как запрашиваемый функционал реализуется в данный момент. Если реализация
отсутствует, то указывается что разрабатываемый функционал является новым.
◦ Обоснование:
В момент написания системы у заказчика может использоваться аналогичная система (т.е. проект
- является миграцией на новую версию). Или реализуемые процессы могут существовать но в
неавтоматизированной форме и т.д. Эти факты важны при разработке системы, поскольку могут
стать источником доп. требований к разработке. Например, создание процедур миграции с
существующей системы. Или повторение сценариев работы операторов, для упрощения обучения
системе.
◦ Способ
UML модели, SADT модели, пользовательские истории ...
◦ Подсказка
Полное описание может быть большим и трудно читаемым. Сосредоточтись на наиболее важных
аспектах, которые больше всего беспокоят заказчика (т.е. Описывайте проблемные области)

35. 35
Пример документа с требованиями [3/20]
Описание границ проекта
◦ Содержание:
В данном разделе указывается что попадает в рамки данного проекта, а что остается за
рамками. Например, система автоматизации завода может автоматизировать
бухгалтерию и отдел кадров и не затрагивать работу со станками с ЧПУ. Возможно
применение UseCase диаграмм с указанием границ.
◦ Обоснование:
В ходе работы над проектом очень часто возникают вопросы, подлежит ли та или иная
функция реализации. Данный раздел определяет, где нужно остановится. Иногда
просто перечисляются области, которые попадают под автоматизацию, иногда явно
перечисляются области которые автоматизироваться не будут.
◦ Подсказка:
проще писать то что не входит в проект

36. Пример границ проекта

37. 37
Пример документа с требованиями [4/20]
Описание зависимостей и предположений
◦ Содержание:
В данном разделе указываются предположения, которые должны выполнится для
успешной работы проекта. Например, выполнение каких-то других проектов, или
предположение о максимальном числе пользователей и нагрузке.
◦ Обоснование:
Данные зависимости оказывают существенное влияние на дизайн разрабатываемой
системы.
◦ Подсказка:
Пишите только то, что является за границами вашего проекта.

38. Пример

39. 39
Пример документа с требованиями [5/20]
Описание ролей пользователей системы
◦ Содержание:
Дается таблица, в которой указываются названия ролей. Указывается описание ролей
пользователей.
◦ Обоснование:
Для простоты описания системы удобно пользователей разделить на группы и строить
описание работы пользователя применительно к группе. В большинстве случаев ролей
больше чем одна (как минимум пользователь и администратор).
◦ Подсказка:
Давайте ролям человеческие имена, это упрощает описание сценариев.

40. Пример

41. Пример документа с требованиями [6/20]
Борьба со сложностью
Структурированное изложение информации
◦ Если есть возможность разбить функционал на блоки – это лучше сделать.
Для каждого блока нужно дать короткое описание, обосновывающее его бизнес задачи
(декомпозиция общих).
Для каждого блока нужно определить его инварианты (условия, выполняющиеся всегда).
◦ Инварианты помогают мыслить категориями.
◦ Хороший инвариант описывает правило с минимумом условие (например, солнце встает на
востоке).
◦ Избегайте описания процессов в виде инвариантов (например, при выполнении условия падения
с воза бабы лошадь, используемая в качестве движетеля данного воза, должна почуствовать
некоторое облегчение).
41

42. Диаграммы типа Documentation
doc Расчетная работа
Тербования
+ Требования заказчика: Package
+ Бизнес правила: Package
+ Зависимости: Package
Варианты использования
+ Варианты использования: Package
Трассировка требований
+ Требования заказчика: Package

43. 43
Пример документа с требованиями [7/20]
Сценарии работы
Описание сценариев работы системы
◦ Варианты использования используются как механизм упрощения этапа формулировки требований для
всех заинтересованных лиц.
◦ Сценарий – это специальная последовательность действий или взаимодействий между исполнителем и
системой.
◦ Прецендент – это набор взаимосвязанных успешных и не успешных сценариев, описывающий
использование системы исполнителем для решения одной из задач.
◦ Описания прецендентов – это текстовые документы а не диаграммы. Соответственно, моделирование
прецендентов это процесс написания текста.
◦ Для иллюстрации имен прецендентов и исполнителей, а так же их взаимоотношений используются
диаграммы UML Use Case.
Преценденты бывают двух видов:
◦ Функциональные, описывающие реализацию той или иной функции.
◦ Инфраструктурные, описывающие работу системы в целом (например процессы авторизации и т.д.)

44. 44
Пример документа с требованиями [8/20]
Прецедент
Содержание сценария прецендента:
◦ Обычно описывается в виде последовательности шагов, с коротким словесным описанием шага и кем он
выполняется.
◦ Если в процессе работы допускается ветвление (например, при одни обстоятельствах выполняется одно
действие, при других - другое), то описывается наиболее часто встречающийся случай. Более редкие случаи
описываются отдельно в виде альтернативных или расширяющих сценариев.
◦ В описании стараются сконцентрироваться не на реализации процессов, а на сути выполняемых шагов (не
ввод логина и пароля а аутентификация и авторизация в системе, которая может быть реализована и с
помощью смарт-карты).
Описание прецедента состоит
◦ Описание ролей;
◦ Описание предусловий;
◦ Описание основных сценариев;
◦ Описание дополнительных (альтернативных) сценариев;
◦ Описание постусловий:

45. Пример документа с требованиями [9/20]
Плохое описание прецендента
45
◦ Роли:
◦ Оператор – сотрудник организации.
◦ Предусловие:
◦ Компьютер выключен.
◦ Сценарий:
◦ Постусловие:
◦ Программа запущена и готова к работе.

46. Пример документа с требованиями [10/20]
Хорошое описание прецендента
46
◦ Роли:
◦ Оператор – сотрудник организации имеющий права на работу с системой.
◦ Предусловие:
◦ Система ожидает авторизации (Компьютер выключен.)
◦ Сценарий:
◦ Постусловие:
◦ Оператор успешно аутентифицирован и авторизован на работу с системой.
(Программа запущена и готова к работе.)

47. Пример документа с требованиями [11/20]
Расширяющий сценарий
◦ Роли:
◦ Оператор – сотрудник организации имеющий права на работу с системой.
◦ Предусловие:
◦ В сценарии авторизации на шаге 3 система определила, что оператор имеет роль - Директор
◦ Сценарий:
◦ Постусловие:
◦ Выполнение переходит на 4 шаг базового сценария
47
Описание Роль/Модуль
1 Отправляется e-mail на почту
оператора. В e-mail пишется
время входа в систему.
Система
2 В системе сохраняется
информация о времени входа в
систему и об усппешности
отправки e-mail.
Система

48. Пример документа с требованиями [12/20]
Правила формирования описания UseCase
◦ Определите рамки системы: что включает в себя система?
Программный это комплекс или программно-аппаратный?
◦ Идентифицируйте основных исполнителей системы (роли). Для
каждого исполнителя определите его задачи.
◦ Определите преценденты, удовлетворяющие потребности каждого
исполнителя.
◦ Отсутствие внешних компьютерных систем среди основных
исполнителей – достаточно редкий случай.
◦ Имя прценедента начинается с существительного, описывающего
действия.
◦ В требованиях лучше описать преценденты, чем списки
низкоуровневых свойств.
48

49. Пример
uc Варианты использования органайзера
Авторизация и
аутентификация
Просмотр
календаря
Поиск встречи на
карте
Добавление
встречи
Информирование о
встрече
Изменение
местоположения
Пользователь
«precedes»
«precedes»
«precedes»
«precedes»
«extend»
«precedes»

50. 50
Пример документа с требованиями [13/20]
Требования к программным интерфейсам
◦ Содержание:
Данный раздел содержит спецификацию программных интерфейсов системы и описание потоков
данных между системами. Могут применяться UML диаграммы Activity, Sequence, Collaboration.
На данном этапе важно не столько детальное описание интерфейса, сколько концептуальное
описание взаимодействия с внешней системой, передаваемые данные. Описание размеров и
частоты передачи данных. Требование к времени реакции системы на события.
В качестве иллюстраций хорошо использовать Activity диаграммы или Взаимодействия.
◦ Обоснование:
Визуальное описание сценариев взаимодействия систем более понятно, чем текстовая
спецификация. Описание передаваемых данных позволяет понять, какими данными та или иная
система оперирует, кто данные производит, а кто потребляет.

51. 51
Пример документа с требованиями [14/20]
Требования к отчетности
Содержание
В данном разделе описываются отчеты, построенные системой. Описание включает:
◦ Назначение отчета. Очень важно понимать кто будет использовать данный отчет. Какая информация
для него главная, а какая второстепенная.
◦ Периодичность построения отчета. Создание сложных отчетов может создать большую нагрузку на
систему.
◦ Параметры отчета. Нужно понимать достаточно ли вводимых данных для построения отчета. Возможно
данные будут избыточны.
◦ Внешний вид (прототип) отчета. Необходимо представить описание того, какие данные будут
выводится пользователю. Это можно сделать в словесной или графической форме. Графическая форма
дает понять сколько столбцов может влезть на лист.
◦ Описание критериев выбора данных и полей отчета. Приводится описание того какие данные
выводятся в отчете, как используются вводимые параметры (каждый параметр должен быть упомянут
хотя бы один раз).
Требования к отчетности и интерфейсам помогают спроектировать логическую модель данных
на следующих этапах.

52. 52
Пример документа с требованиями [15/20]
Нефункциональные требования
◦ Требования описываются в виде измеримых сценариев (всегда должна быть цифра,
описывающая данную характеристику качества!);
◦ Сценарий состоит из следующих частей:
◦ Источник события (внешняя система, оператор ...)
◦ Событие (некоторый факт, повлиявший на систему)
◦ Артефакт (то на что конкретно повлияло событие)
◦ Условия, при которых происходит событие
◦ Реакция на событие (то что хотим достичь для нормальной работы системы)
◦ Измеримая величина характеризующая реакцию.
◦ Сценарии должны иметь сквозной приоритет (все показатели качества сделать максимальными
не удастся).

53. Пример документа с требованиями [16/20]
Требования к надежности
53
◦ Содержание:
Описываются сценарии сбоя в работе системы и временные требования к
восстановлению системы.
Сценарии строятся по принципу: сбой, реакция на сбой, сбой устранен.
◦ Обоснование:
Абсолютно надежных систем не бывает, даже если все ПО функционирует безотказно
сбой может произойти в аппаратной части.

54. Пример документа с требованиями [17/20]
Требования к производительности
54
◦ Содержание:
Описываются требования по нагрузке, которые предъявляются к системе. Описываются
сценарии и производительности системы в рамках данных сценариев.
Сценарии строятся по принципу: элементарный сценарий или прецендент, скорость работы
сценария или прецендента.
◦ Обоснование:
Требования к производительности присутствуют всегда, чем раньше о них будет заявлено,
тем лучше для успеха проекта.

55. Пример документа с требованиями
[18/20]
55
Требования к безопасности
◦ Содержание:
Описываются сценарии проверки прав безопасности. Описываются требования к наличию
прав у ролей на те или иные функции системы.
Сценарии строятся по принципу: описание атаки, время восстановления после атаки
◦ Обоснование:
В случае, если в системе должно работать более одного человека - разделение прав
безопасности единственный способ организации нормальной коллективной работы с
системой.

56. Пример документа с требованиями [19/20]
Требования к удобству использования
56
◦ Содержание:
Описываются требования к взаимодействию системы с оператором. Указываются бизнес приоритеты и
специфика работы операторов.
Сценарии строятся по принципу: оператор хочет произвести действие, оператор получает наблюдаемый
эффект от действия. Например, в качестве приоритетов может быть уменьшение ошибок при работе с
системой или ускорение ввода необходимой информации. В качестве специфики работы, например
может указываться что операторы имеют плохое зрение (пожилые люди) или плохо управляются с
манипулятором Мышь.
◦ Обоснование:
Для некоторых проектов, таких как Web, удобство использования - самый главный фактор успеха. В любом
случае, ПО пишется для людей.

57. Пример документа с требованиями [20/20]
Требования к модифицируемости
57
◦ Содержание:
Описываются требования к внесению изменений в программу. Обычно после
начала эксплуатации программная система развивается, реализуя новые бизнес-
процессы. Очень важно понимать как она будет развиваться дальше.
◦ Обоснование:
Процесс внесение изменений в систему является одним из факторов влияющим
на бизнес компании. Чем быстрее может меняется система, тем быстрее
компания получает бизнес-отдачу от нового функционала.

58. НЕМНОГО ПРАВИЛ
ИНТЕРФЕЙСЫ С ПОЛЬЗОВАТЕЛЕМ
58

59. Общие принципы
1. Интерфейс должен быть интуитивно понятным. Таким, чтобы
пользователю не требовалось объяснять как им пользоваться.
2. Для упрощения процесса изучения необходима справка. Буквально —
графическая подсказка, объясняющая значение того или иного ЭИ.
Полное руководство должно быть частью интерфейса, доступной в
любой момент.
59

60. Общие принципы
1. Возвращайте пользователя в то место, где он закончил работу в прошлый
раз. Зачем нажимать все заново?
2. Чаще всего, пользователи в интерфейсе сначала ищут
сущность(существительное), а затем действие(глагол) к ней. Следуйте
правилу «существительное -> глагол». Например, шрифт -> изменить.
60

61. Общие принципы
Чем быстрее человек увидит результат — тем лучше. Пример — «живой» поиск, когда
варианты, в процессе набора поискового запроса. Основной принцип: программа должна
взаимодействовать с пользователем на основе наименьшей значимой единицы ввода.
Используйте квазирежимы. Например, ввод заглавных букв с зажатой клавишей shift — это
квазирежим. С включенным capslock — режим. Основное отличие в том, что человек
может забыть в каком режиме он находится, а в квазирежиме(с зажатой доп. клавишей)
это сделать гораздо сложнее.
61

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

63. Создание Элементов Интерфейса
1. Разработка интерфейса обычно начинается с определения задачи или набора задач, для которых продукт предназначен.
2. Простое должно оставаться простым. Не усложняйте интерфейсы. Постоянно думайте о том, как сделать интерфейс проще и
понятнее.
3. Пользователи не задумываются над тем, как устроена программа. Все, что они видят — это интерфейс. Поэтому, с точки
зрения потребителя именно интерфейс является конечным продуктом.
4. Интерфейс должен быть ориентированным на человека, т.е. отвечать нуждам человека и учитывать его слабости. Нужно
постоянно думать о том, с какими трудностями может столкнуться пользователь.
5. Думайте о поведении и привычках пользователей. Не меняйте хорошо известные всем ЭИ на неожиданные, а новые делайте
интуитивно понятными.
6. Разрабатывайте интерфейс исходя из принципа наименьшего возможного количества действий со стороны пользователя.
63

64. Какой должен быть дизайн ЭИ?
https://color.adobe.com/ru/explore/newest/?time=all
Цвет. Цвета делятся на теплые(желтый, оранжевый, красный), холодные(синий, зеленый), нейтральные(серый).
Обычно для ЭИ используют теплые цвета. Это как раз связано с психологией восприятия. Стоит отметить, что
мнение о цвете — очень субъективно и может меняться даже от настроения пользователя.
Форма. В большинстве случаев — прямоугольник со скругленными углами. Или круг. Полностью прямоугольные
ЭИ, лично мне нравятся меньше. Возможно из-за своей «остроты». Опять же, форма как и цвет достаточно
субъективна.
Основные ЭИ(часто используемые) должны быть выделены. Например размером или цветом.
Иконки в программе должны быть очевидными. Если нет — подписывайте. Ведь, по сути дела, вместо того чтобы
объяснять, пиктограммы зачастую сами требуют для себя объяснений.
Старайтесь не делать слишком маленькие элементы — по ним очень трудно попасть
64

65. Как правильно расположить ЭИ на
экране?
Есть утверждение, что визуальная
привлекательность основана на
пропорциях. Помните известное число
1.62? Это так называемый принцип
Золотого сечения. Суть в том, что весь
отрезок, относиться к большей его части
так, как большая часть, относиться к
меньшей. Например, общая ширина сайта
900px, делим 900 на 1.62, получаем
~555px, это ширина блока с контентом.
Теперь от 900 отнимаем 555 и получаем
345px. Это ширина меньшей части:
65

66. Как правильно расположить ЭИ на
экране?
Перед расположением, ЭИ следует упорядочить(сгруппировать) по значимости. Т.е. определить, какие наиболее
важны, а какие — менее.
Обычно(но не обязательно), элементы размещаются в следующей градации: слева направо, сверху вниз. Слева в
верху самые значимые элементы, справа внизу — менее. Это связано с порядком чтения текста. В случае с
сенсорными экранами, самые важные элементы, располагаются в области действия больших пальцев рук.
Необходимо учитывать привычки пользователя. Например, если в Windows кнопка закрыть находиться в правом
верхнем углу, то программе аналогичную кнопку необходимо расположить там же. Т.е. интерфейс должен иметь
как можно больше аналогий, с известными пользователю вещами.
Размещайте ЭИ поближе там, где большую часть времени находиться курсор пользователя. Что бы ему не
пришлось перемещать курсор, например, от одного конца экрана к другому.
Элемент интерфейса можно считать видимым, если он либо в данный момент доступен для органов восприятия
человека, либо он был настолько недавно воспринят, что еще не успел выйти из кратковременной памяти. Для
нормальной работы интерфейса, должны быть видимы только необходимые вещи — те, что идентифицируют
части работающих систем, и те, что отображают способ, которым пользователь может взаимодействовать с
устройством.
Делайте отступы между ЭИ равными или кратными друг-другу.
66

67. Как ЭИ должны себя вести?
Пользователи привыкают. Например, при удалении файла,
появляется окно с подтверждением: «Да» или «Нет». Со временем,
пользователь перестает читать предупреждение и по привычке
нажимает «Да». Поэтому диалоговое окно, которое было призвано
обеспечить безопасность, абсолютно не выполняет своей роли.
Следовательно, необходимо дать пользователю возможность
отменять, сделанные им действия.
Если вы даете пользователю информацию, которую он должен
куда-то ввести или как-то обработать, то информация должна
оставаться на экране до того момента, пока человек ее не
обработает. Иначе он может просто забыть.
Избегайте двусмысленности. Например, на фонарике есть одна
кнопка. По нажатию фонарик включается, нажали еще раз —
выключился. Если в фонарике перегорела лампочка, то при нажатии
на кнопку не понятно, включаем мы его или нет. Поэтому, вместо
одной кнопки выключателя, лучше использовать
переключатель(например, checkbox с двумя позициями: «вкл.» и
«выкл.»).
67

68. Как ЭИ должны себя вести?
Делайте монотонные интерфейсы. Монотонный интерфейс — это интерфейс, в котором
какое-то действие, можно сделать только одним способом. Такой подход обеспечит
быструю привыкаемость к программе и автоматизацию действий.
Не стоит делать адаптивные интерфейсы, которые изменяются со временем. Так как для
выполнения какой-то задачи, лучше изучать только один интерфейс, а не несколько.
Пример — стартовая страница браузера Chrome.
Если задержки в процессе выполнения программы неизбежны или действие
производимое пользователем очень значимо, важно, чтобы в интерфейсе была
предусмотрена сообщающая о них обратная связь. Например, можно использовать
индикатор хода выполнения задачи (status bar).
ЭИ должны отвечать. Если пользователь произвел клик, то ЭИ должен как-то отозваться,
чтобы человек понял, что клик произошел.
68

69. Юзабилити-тестирование
Юзабилити-тестирование (проверка эргономичности) — исследование, выполняемое с
целью определения, удобен ли некоторый искусственный объект (такой как веб-страница,
пользовательский интерфейс или устройство) для его предполагаемого применения. Таким
образом, проверка эргономичности измеряет эргономичность объекта или системы.
Проверка эргономичности сосредоточена на определённом объекте или небольшом
наборе объектов, в то время как исследования взаимодействия человек-компьютер в
целом — формулируют универсальные принципы.
Проверка эргономичности — метод оценки удобства продукта в использовании,
основанный на привлечении пользователей в качестве тестировщиков, испытателей и
суммировании полученных от них выводов.

70. «Грабли»
Usability-тестирования [1/2]
1.Hawthorne Effect. "Когда пользователи знают, что за ними наблюдают они склонны
проявлять другое поведение, чем обычно. На заводе Хоторн с1927 по 1932 года проводили
эксперименты по улучшению производительности труда. Экспериментаторы обнаружили
более высокую производительность чем обычно, просто потому что за ними наблюдали.
Это часто называют эффектом наблюдателя.
2.Task-Selection Bias. Когда Вы ставите задачу пользователям, то эта задача выполнима (и
пользователи об этом знают). В обычной жизни пользователь может не знать, возможно
что-то сделать или нет.
3.Социальный эффект. Пользователи обычно любят говорить, то что от них хотят услышать,
а не то что они думают. Это может повлиять на результаты исследования.
4.Доступность. Обычно у пользователя есть 1-2 часа, что бы добровольно поучаствовать в
тестировании. Это усложняет процесс, в том случае если Вам нужны сильно-занятые и
труднодоступные специалисты.
70

71. «Грабли»
Usability-тестирования [2/2]
1.Гонорар. Платить пользователю за участие в исследовании – это нормально. Однако гонорар может
стать единственным мотивом пользователя для выполнения работы. Это может повлиять на то, как
он её выполняет.
2.«Если Вы спрашиваете – значит это важно». Часто пользователи не имеют своего мнения по каким-
либо вопросам и действуют интуитивно. Но если их спросить, почему они так действуют? То они
постараются придумать какое-то мнение, потому что считают, что это важно.
3.Заметки. Иногда пользователей пугает, если Вы что-то записали в процессе проведения
тестирования. Они считают, что где-то ошиблись и это влияет на их поведение.
4.Техническая сложность. Иногда, если Вы проводите тестирование на технически-сложных
устройствах, это может быть проблемой для слабо-подкованных в технике людей.
5.Эффект новизны. Это эффект, когда первое впечатление имеет больший эффект на пользователя,
чем последующая работа в схожих интерфейсах. Это может влиять на обратную связь от
пользователя. Обычно для сглаживания этого эффекта дают задачи пользователям в разных
порядках.
71

72. Что почитать для углубленного понимания?
1.Software Requirements, Second Edition
by Karl E. Wiegers ISBN:0735618798
Microsoft Press © 2003 (516 pages)
2. Джеф Раскин, «Интерфейс: новые
направления в проектировании компьютерных
систем»
3. Алан Купер, «Об интерфейсе. Основы
проектирования взаимодействия»
4. Алан Купер, «Психбольница в руках
пациентов»
5. Оригинал статьи
http://habrahabr.ru/post/208966/
72

73. Спасибо!