#систематика /// Потребности, требования, ограничения
У надсистемы (по отношению в ЦС), а точнее у её, надсистемы, проектных ролей, есть какие-то потребности.
Эти потребности проявляются / преобразуются / выражаются как требования к ЦС.
И здесь важна их трассировка — связывание потребностей надистемы с требованиями к ЦС.
Когда формулируются требования, то они формулируются к ЦС без рассмотрения её, целевой системы, свойств и устройства. В таком случае ЦС рассматривается как чёрный ящик. Это предпочтительный вариант.
Требования обязательно должны быть увязаны с главной функцией системы.
Но если вместе с потребностями транслируются также требования к внутреннему устройству ЦС или принципам её работы, то тогда ЦС рассматривается как прозрачный ящик, и тогда требования, выдвигаемые к внутреннему устройству ЦС есть ограничения. Если такая ситуация случилась, то стоит торговаться насчёт ограничений, потому что это ограничения конструкторской свободы команды проекта, реализующей ЦС.
Все эти потребности, требования и ограничения являются описанием системы:
потрбености для над-системы и систем в окружении;
требования и ограничения для целевой системы.
Сначала рассматривают окружение и надсистему (главное действие) и лишь затем ЦС и цепочки обеспечения!
Потребности и требования обязательно трассируются, то есть сводятся "концы с концами".
Не должно оставаться потребностей, не переведенных в требования — потребности не будут удовлетворены, система не будет успешной.
Не должно быть требований, не относящихся к потребностям — это будет лишняя работа, которая может помешать другим требованиям и воплощению системы.
___
#потребности #требования #ограничения #чёрный_ящик #прозрачный_ящик #описание
У надсистемы (по отношению в ЦС), а точнее у её, надсистемы, проектных ролей, есть какие-то потребности.
Эти потребности проявляются / преобразуются / выражаются как требования к ЦС.
И здесь важна их трассировка — связывание потребностей надистемы с требованиями к ЦС.
Когда формулируются требования, то они формулируются к ЦС без рассмотрения её, целевой системы, свойств и устройства. В таком случае ЦС рассматривается как чёрный ящик. Это предпочтительный вариант.
Требования обязательно должны быть увязаны с главной функцией системы.
Но если вместе с потребностями транслируются также требования к внутреннему устройству ЦС или принципам её работы, то тогда ЦС рассматривается как прозрачный ящик, и тогда требования, выдвигаемые к внутреннему устройству ЦС есть ограничения. Если такая ситуация случилась, то стоит торговаться насчёт ограничений, потому что это ограничения конструкторской свободы команды проекта, реализующей ЦС.
Все эти потребности, требования и ограничения являются описанием системы:
потрбености для над-системы и систем в окружении;
требования и ограничения для целевой системы.
Сначала рассматривают окружение и надсистему (главное действие) и лишь затем ЦС и цепочки обеспечения!
Потребности и требования обязательно трассируются, то есть сводятся "концы с концами".
Не должно оставаться потребностей, не переведенных в требования — потребности не будут удовлетворены, система не будет успешной.
Не должно быть требований, не относящихся к потребностям — это будет лишняя работа, которая может помешать другим требованиям и воплощению системы.
___
#потребности #требования #ограничения #чёрный_ящик #прозрачный_ящик #описание
#дизайн /// Требования в UI-задачах
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.
Эта заметка — выжимка из более крупной заметки про требования в UX/UI-задачах.
В плане версии это пре-альфа и предстоит еще несколько итераций до полноценной альфы и тем более беты. Поэтому буду очень рад комментариям и вопросам.
1) Что изменится в мире с помощью этого UI?
Интерфейс == система обеспечения, найдите целевую систему — действие или продукт в физическом мире. Путь пользователя к состоянию этого действия/продукта зависят от интерфейса. Важно проследить цепочку событий, ведущих от действия в UI к целевому действию в физическом мире. Цепочка может быть представлена в виде связанных user stories (job stories). Цельная, логичная цепочка "сторей" без противоречий у стейкхолдеров — хорошие требования.
2) Присутствуют ли в постановке задачи ограничения?
В мире UI очень часто передаются предполагаемые решения в виде требований; явный пример: указание на компонент вместо требуемой функции ("выбор чекбоксами" вместо "возможность множественного выбора"). Это — ограничение, их надо отслеживать и снимать: затребовать искомую функцию (в цепочке "сторей"), и уже к функции подобрать подходящий компонент.
3) Задачу какого уровня в данный момент надо решить?
Разложите задачи на спектре [общие решения - - - - конкретные решения]. Общие решения необходимо принять в первую очередь, их можно назвать архитектурными решениями, от них зависят более детальные требования и решения — на уровне / уровнях ниже. Регулярно сверяйтесь с уровнем, на котором сейчас работаете, важно в моменте решать задачу, соответствующу уровню.
4) Как я формально пойму, что решение удовлетворяет требованиям?
В итоге работы по первым трем пунктам у вас есть список задач
- в виде сфорулированных требований ("стори")
- со снятыми ограничениями
- декомпозированный по уровням и "сторям"
Формулируйте их так, чтобы из них легко было понять последовательность решения задач и критерии, по которым решение проверяется.
Далее, при наличии требований, разработайте решение и участвуйте в приемке; об этом в следующих заметках (и в полной версии заметки).
Четыре пункта выявления требований (аналитика) и два пункта разработки (синтетика) — итеративный процесс.
___
#целевая #требования #интерфейс #ограничения #проверка #системное_разбиение
[[+ Целевая, наша, над-, под- системы в окружении]] — работая с UI необходимо помнить, что это работа над системой обеспечения, и важно держать в голове фокус на целевую физическую систему: продукт или процесс.
[[+ Главное действие]] — все действия пользователя в UI есть часть цепочки действий, ведущих к главному действию в физическом мире; определение родительской системы/сценария есть важнейший шаг по построению этой цепочки.
[[+ Потребности, требования, ограничения]] — в работе над UI часто встречаются органичения; их важно снимать, выявляя вместо решений требования; это необходимо для построение цельной цепочки до целевого действия.
[[+ Часть-целое, разбиение, эмерджентность]] — при работе над UI сохраняется принцип системного разбиения, только чаще всего подсистемами/надсистемами являются физические процессы.