Каков лучший способ формального выражения требований удобства использования?
Я думаю, вы должны попробовать что-то вроде этого:
private void setTimeLimit(Object timeLimit) {
if (Objects.isNull(this.timeLimit)) {
this.timeLimit = timeLimit;
}
}
Однако, я рекомендую вам изменить структуру классов, чтобы инициализировать только один раз в первый раз.
6 ответов
Обычно, мы пытаемся долго обсудить специализированное определение 'простых в использовании'. Например, для нашего текущего проекта, простых в использовании средств:
- Все задержки системы, дольше, чем.5 секунд произведут диалоговое окно, которое говорит, "Ожидают".
- Возможно достигнуть любой данной системной функции из главного окна меньше чем в 3 щелчках.
- Возможно выполнить любую данную задачу только с клавиатурой без мыши.
- Все кнопки в системе будут придерживаться установленной конвенции кнопки (свяжитесь с установленной конвенцией кнопки относительно размера, именования, положения, и т.д.),
- Все экраны будут иметь кнопку справки. Каждая кнопка справки на данном экране должна обеспечить по крайней мере одну 'тему' для каждого управления на экране.
- и т.д.
Эти виды вещей являются тестируемыми, и взятые вместе, составляют 'довольно хороший' стандарт удобства использования. Тем не менее ничто не заменяет фактических пользователей, испытывающих его.
Требования удобства использования трудны, потому что единственный способ знать, применима ли Ваша система, при наличии реальных пользователей, испытывают его. Как Вы будете знать, отвечали ли Вашим требованиям? Чтобы сделать это, Вам нужны формальные метрики для удобства использования. Те метрики должны так или иначе быть извлечены из результатов тестирования удобства пользования, и если Вы абстрагируете свое тестирование удобства пользования до такой степени, когда, Вы просто выводите метрики, Вы пропускаете его полноценность.
Некоторые объекты как "должны смочь сделать X с Y, многие нажимают" or "система, должен ответить в миллисекундах Z, или меньше" полезно, но они - на самом деле функциональные требования, которые имеют отношение к удобству использования, не требованиям удобства использования в себе. Это довольно возможно (если вряд ли), что можно разработать и реализовать систему, которая отвечает всем таким формальным требованиям и все еще печальна для пользователей. Снова, единственный способ знать посредством тестирования удобства пользования.
Ну, 'Система должна быть простой в использовании', точно вид документации, которая расстраивает и разработчиков и разработчиков, поэтому давайте посмотрим, можем ли мы сделать немного лучше, чем это, буду мы?:)
Прежде всего, можно найти полезным сесть и вообразить точно, кто предполагаемый пользователь. Дайте им фон, дайте им немного цвета, затем отправьте их в свое предполагаемое приложение и попытайтесь выяснить, как они как люди хотели бы взаимодействовать с ним.
Помните, различные пользователи обеспокоены различными аспектами удобства использования. Только сконцентрируйтесь на пути истории, Вы думаете, что следовали бы при использовании приложения.
Затем могло бы быть полезно разломать сайт на компоненты удобства использования. Это имеет много изображений? Если так, что является лучшим способом представить много изображений пользователю. Это имеет глубоко вложенную структуру меню? Мог бы быть лучший путь, чем sitetree, чтобы помочь Вашим пользователям переместиться по своему пути вокруг? Скороговорки дизайна удобства использования помогут Вам здесь. Хороший ресурс для шаблонов разработки для удобства использования может быть найден здесь и здесь. Шаблоны разработки хороши, потому что они ясно объясняют всем, включил, как определенная функциональность, как предполагается, работает.
Уделите минуту для рассмотрения доступности в сочетании с удобством использования. Как работа сайта с выключенным JavaScript всегда является очень хорошим местом для запуска и может быть большой справкой к разработчикам, которые склонны становиться очень усталыми от наблюдения их еще одной палки разработчика <a> ссылка на странице, которая испытывает необходимость для представления формы.
Помните, удобство использования о ясности, и это начинается с четкой связи с людьми, создающими систему. Если Вы не можете говорить ясно о том, что Вы хотите созданный, как Вы ожидаете, что разработчики создадут что-то функциональное? Займите дополнительное время для заворачивания в бумагу прототипа, если Вы имеете к.
Мой ответ может быть немного слишком 'веб-' сфокусированный, чтобы иметь огромное применение для Вас, но я надеюсь, что это обеспечивает несколько полезных лакомых кусочков среди моего разглагольствования.
Вот документация GNOME относительно человеческого взаимодействия через интерфейс. Это предназначается как пример того, как указать, не, что указать (поскольку я не соглашаюсь со всем, что они говорят там).
Самый однозначный способ включать требования удобства использования в документ требований, чтобы я мог найти: сделайте много экранных макетов (и соедините их с "потоком" выполненных действий, например, при наличии точки стрелки от одного объекта в image1 к соответствующему следующему объекту на image2 и т.д.). Если люди на самом деле видят, как что-то, как предполагается, работает, это легче понять и оставляет меньше комнаты для интерпретации.
Метрики и Варианты использования.
У нас есть много персон, которые инкапсулируют наши различные клиентские типы.
У нас есть пользователь poweruser (George, он - тормозной, университетский тип), нетехнический человек (Frank, который может едва использовать калькулятор) и кто-то промежуточный (Susie, она знает, как бродить по сети и может говорить с технической поддержкой, но не спрашивает ее, что emacs).
На основе этого мы говорим:
- Для функции X, George должен смочь получить доступ к нему, не используя справку или приостановившись дольше, чем несколько секунд, Suzie, возможно, должна посмотреть на справку, но вероятно не будет и если Frank делает это лучше быть настоящий ясный, потому что у него нет большого терпения.
Теперь, для метрик, у нас также есть инструкции по исследованию удобства использования, как из 10 человек, 8 должен смочь получить доступ к Функции Y, не смотря на справку или смочь сделать это с 30 секундами.
Это действительно субъективно, но это могло бы помочь Вам начать к в правильном направлении. Плюс, это может помочь Вам говорить с типами неразработчика, кто "просто хочет, чтобы это работало и было легко".
Не повредило бы читать Joel на статьях программного обеспечения также.