Как оценить качество технического задания? Ну или иного метода работы с требованиями. На что смотреть? Что выбрать?
Что лучше -- use cases или user stories? User stories или job stories? Когда и как применять UML? А BDD-сценарии?
Есть такая штука: Когнитивные измерения. Cognitive dimensions. Не в смысле "померять", а в смысле - задающие пространство. Эти измерения, или шкалы применяются для оценки графических нотаций, языков программирования и пользовательских интерфейсов.
Нотации и языки близки к более-менее формализованным способам записи требований в техническом задании (или любой другой форме описания свойств системы). Так что эти шкалы можно применить и к форме спецификации требований.
На удивление, про когнитивные измерения даже есть статья на русском в Википедии (обычно такие статьи удаляют, как не несущие ценности).
Базируется подход к когнитивным измерениям на 6 базовых действиях с артефактом:
приращение (добавление ещё одного кусочка - строки кода, элемента, ещё одного требования),
транскрипция (можно сказать -- распаковка или превращение, для требований это будет -- воплощение требования в коде),
модификация (тут понятно),
эксплораторное проектирование (когда конечный результат неясен, и вырисовывается только в ходе его обдумывания при помощи нотации / языка),
поиск (тоже понятно -- как найти что-то в спецификации)
и эксплораторное понимание (как из последовательного знакомства с документом понять, о чем вообще речь).
Эти действия очень похожи на то, что мы обычно производим со спецификацией.
Из них авторы выводят 14 "измерений" -- характеристик нотации, языка или интерфейса. Измерения такие:
1. Вязкость. То есть, сопротивление изменениям. Измерить можно как число усилий, требующихся для изменения. Вязкость может быть кумулятивная -- то есть, изменения в одном месте нарушают целостность и влекут каскад изменений в других местах, возможно и на других уровнях абстракции; итеративная -- изменение требует множества мелких действий по внесению исправлений в других местах; вязкость масштабирования -- изменение размера входных данных приводит к изменениях в структуре.
2. Наглядность или видимость. Насколько легко найти требуемый элемент? Насколько легко понять, где искать?
3. Преждевременная фиксация. Вся ли нужная информация предоставлена и рассмотрена к тому моменту, когда зафиксировано решение? Это "N" в критериях INVEST -- требование можно обсуждать до момента реализации, не надо сразу выдавать какое-то решение, неизвестно на чем основанное. Плохой пример: описание конкретных элементов интерфейса в use case.
4. Скрытые зависимости. Как изменение этого требования повлияет на остальные требования? Видно ли это явно? Для спецификации это обычно решают трассировками (которые обычно, конечно же, забывают/забивают).
5. Выразительность ролей. Вот эта штука, которую мы сейчас описываем, она вообще про что? Она как соотносится с остальными частями спецификации? В идеале, когда мы открываем документ, мы должны сразу понять — ага, тут речь про API, или про модель назначения полномочий.
6. Подверженность ошибкам. Насколько используемая нотация или формат провоцирует ошибки? Или наоборот, не дает эти ошибки совершить? Формат требования "система должна X" вообще никак не избавляет от ошибок в формулировках, а вот [Условие срабатывания][субъект][действие][объект][ограничение] помогает выявить и описать поведение лучше.
7. Абстракция. Где границы по уровням абстракции для этой нотации или формата? Понятны ли они? К чему стремится описание в такой форме (иногда говорят о градиенте абстракции)? Например, те же юскейсы обычно сползают по градиенту к деталям реализации, а описания процессов слишком абстрактны.
8. Вторичные обозначения. Есть ли инструмент, позволяющий дать дополнительный контекст этой нотации? Выйти, так сказать, за пределы формального описания? Примечания там, разметка, теги, выделение цветом.
9. Близость соответствия. Насколько выбранное описание похоже на тот объект или действие, которое мы описываем? Похожи ли user stories на взаимодействие двух программных модулей?
Что лучше -- use cases или user stories? User stories или job stories? Когда и как применять UML? А BDD-сценарии?
Есть такая штука: Когнитивные измерения. Cognitive dimensions. Не в смысле "померять", а в смысле - задающие пространство. Эти измерения, или шкалы применяются для оценки графических нотаций, языков программирования и пользовательских интерфейсов.
Нотации и языки близки к более-менее формализованным способам записи требований в техническом задании (или любой другой форме описания свойств системы). Так что эти шкалы можно применить и к форме спецификации требований.
На удивление, про когнитивные измерения даже есть статья на русском в Википедии (обычно такие статьи удаляют, как не несущие ценности).
Базируется подход к когнитивным измерениям на 6 базовых действиях с артефактом:
приращение (добавление ещё одного кусочка - строки кода, элемента, ещё одного требования),
транскрипция (можно сказать -- распаковка или превращение, для требований это будет -- воплощение требования в коде),
модификация (тут понятно),
эксплораторное проектирование (когда конечный результат неясен, и вырисовывается только в ходе его обдумывания при помощи нотации / языка),
поиск (тоже понятно -- как найти что-то в спецификации)
и эксплораторное понимание (как из последовательного знакомства с документом понять, о чем вообще речь).
Эти действия очень похожи на то, что мы обычно производим со спецификацией.
Из них авторы выводят 14 "измерений" -- характеристик нотации, языка или интерфейса. Измерения такие:
1. Вязкость. То есть, сопротивление изменениям. Измерить можно как число усилий, требующихся для изменения. Вязкость может быть кумулятивная -- то есть, изменения в одном месте нарушают целостность и влекут каскад изменений в других местах, возможно и на других уровнях абстракции; итеративная -- изменение требует множества мелких действий по внесению исправлений в других местах; вязкость масштабирования -- изменение размера входных данных приводит к изменениях в структуре.
2. Наглядность или видимость. Насколько легко найти требуемый элемент? Насколько легко понять, где искать?
3. Преждевременная фиксация. Вся ли нужная информация предоставлена и рассмотрена к тому моменту, когда зафиксировано решение? Это "N" в критериях INVEST -- требование можно обсуждать до момента реализации, не надо сразу выдавать какое-то решение, неизвестно на чем основанное. Плохой пример: описание конкретных элементов интерфейса в use case.
4. Скрытые зависимости. Как изменение этого требования повлияет на остальные требования? Видно ли это явно? Для спецификации это обычно решают трассировками (которые обычно, конечно же, забывают/забивают).
5. Выразительность ролей. Вот эта штука, которую мы сейчас описываем, она вообще про что? Она как соотносится с остальными частями спецификации? В идеале, когда мы открываем документ, мы должны сразу понять — ага, тут речь про API, или про модель назначения полномочий.
6. Подверженность ошибкам. Насколько используемая нотация или формат провоцирует ошибки? Или наоборот, не дает эти ошибки совершить? Формат требования "система должна X" вообще никак не избавляет от ошибок в формулировках, а вот [Условие срабатывания][субъект][действие][объект][ограничение] помогает выявить и описать поведение лучше.
7. Абстракция. Где границы по уровням абстракции для этой нотации или формата? Понятны ли они? К чему стремится описание в такой форме (иногда говорят о градиенте абстракции)? Например, те же юскейсы обычно сползают по градиенту к деталям реализации, а описания процессов слишком абстрактны.
8. Вторичные обозначения. Есть ли инструмент, позволяющий дать дополнительный контекст этой нотации? Выйти, так сказать, за пределы формального описания? Примечания там, разметка, теги, выделение цветом.
9. Близость соответствия. Насколько выбранное описание похоже на тот объект или действие, которое мы описываем? Похожи ли user stories на взаимодействие двух программных модулей?