Бизнес-аналитика подавай?

[singalen]

Вот почему программисты считают, что требования должен писать кто-то другой?

Ну, то есть, я знаю, почему. Потому что мы хотим колбасить код и больше ничего.

Требования вырабатывают ВМЕСТЕ.
А то сваливаем их на нетехнического специалиста, у которого есть ещё и совсем другие обязанности, а потом сами же на них косим стрелки - мол, неполны, противоречивы и реализуются через место, не именуемое головой.

Бывает, что лучше всех написать требования можешь именно ты.

Если вы, ребята, профессионалы, то сотрудничайте с людями, с которыми работаете.

Comments

[klizardin.livejournal.com]

книжка хоть и старая, но позволяет планамерно сформировать требования в достаточном объеме и надостаточном уровне как для вас как разработчика так и дать понять о том, что вы будете делать PM-у и заказчику. конечно, далее нужно изучать карнеги))) чтобы уметь тонко допытываться у заказчика, что же именно ему нужно в его манере).

[singalen]

А если на пальцах - что именно он предлагает? :)

[klizardin.livejournal.com]

1. предлагает достаточно хороший формат для написания вариантов использования.
2. рассматривает этот формат формулируя наилучшие подходы к формированию вариантов использования.

фактически, четко очерчивает нужные и не нужные, хорошие и плохие подходы в написании варантов использования, или описании поведенческой части требований.

в том числе формулирует достаточно важное замечание

Разрабатываемая система -- это механизм для выполнения соrлашения между участниками. Варианты использования обеспечивают поведенческую часть этоrо coглашения. Каждое предложение в варианте использования описывает действие,
защищающее некоторый интерес какоrо-либо участника. Предложение может описывать взаимодействие двух действующих лиц или внутренние действия системы, которые она должна выполнять для защиты интересов участников.

Формулирует правила/техники хорошего описания/написания вариантов использования.

Например.

Полный список основных действующих лиц дает еще три преимущества:
* Он фокусирует наши мысли на людях, которые будут использовать систему. В документе, содержащем требования, мы фиксируем, Koro предполаrаем в качестве основных действующих лиц, описание их работы, их типичную подrотовку и навыки.

Мы делаем это, чтобы разработчики системы и интерфейса пользователя моrли обеспечить соответствие системы этим характеристикам.

* Он определяет структуру списка Действующее лицо/Цель, которая будет использована для расстановки приоритетов и распределения работы.

* Он нужен для разбиения orpoмнoгo множества вариантов использования на пакеты, которые можно распределить между различными rруппами разработчиков.

или

цель пользователя -- это та цель, которую преследует основное действующее лицо, пытаясь добиться от системы выполнения определенной работы, либо пользователь, работающий с системой.

цели Обобщенного уровеня -- выше уровня моря, белый вариант использования.

цели уровня подфункций -- это цели, достижение которых требуется для реализации целей пользователей.

[klizardin.livejournal.com]

книга дает этакий базис самого подхода к разработке требований. чем и полезна.

или еще выписанные фрагменты

[klizardin.livejournal.com]

Выявление правильной цели пользователя -- труднейшая вещь в вариантах использования. Сосредоточьтесь на следующих правилах:
* Выявите цель пользователя.
* Используйте от трех до 10 шагов на вариант использования. (т.е. не пишите очень длинных/детальных сценариев)


--Выявление цели пользователя--
Спросите себя, является ли это тем, чего действительно сейчас Хочет от системы основное действующее лицо?

Очень часто начинающие набрасывают подводные варианты использования, думая, что те находятся на уровне моря. Чтобы обнаружить цель более выcoкoго уровня, задайте себе любой из этих вопросов:
* Чеro на самом деле хочет действующее лицо?
* Почему действующее лицо это делает?

[klizardin.livejournal.com]

ну и также этот базис близок разработчику.

[singalen]

Ага, спасибо. Я такие инсайты от Лармана получал, помнится.