Меня мучают сомнения правильно ли я составляю развернутое описание прецедента, не слишком ли это подробно (на алгоритм уже тянет) ? или так и надо - чем подробнее тем лучше в развернутом описании...

Мне кажется, что ты пытаешься рассмотреть все возможные случаи, в то время, как пользы это никакой не принесёт.



А как же вариант «Система зависла»  ? Шучу. Я думаю, что всё это можно запросто опустить или в случае крайней необходимости просто объединить в один пункт.




Это хреновый текст. Нет, правда. Ты когда-нибудь видел, чтобы люди производили попытки добавления номеров купонов? Мне кажется, что сценарии гораздо полезнее подобных детализованных описаний юз-кейсов. Напиши литературным языком два-три сценария, о том, как Мэт сидит и пьёт кофе со сливками, когда к нему в офис вламывается клиент с просроченным купоном. Или про Пегги, которую опять бросил парень, и про то, как она, рассерженная, пытается вбить в систему размер скидки клиента. И тому подобное. Эти сухие описания ужасны.

+1

сценарии-рассказы намного легче воспринимать

Надеюсь что понял   

К примеру если я буду испоьзовать метод  система как "Черный ящик" и описывать лиш взаимодействие актер - система, ситема - актер то прецеденты будут лучше ?

Продолжая тему купонов




Очень хочется увидеть Прецеденты с Мэтом и Пегги    

В общем получилась такая тема:



P.S.:

Попробовал составлять веселые сценарии-рассказы...
По мне так они больше годятся для «Функционального» программирования, чем для последующего анализа, или я опять что то недопонял   

Это сообщение отредактировал(а) SLeN - 17.2.2008, 16:04

Ну Мэт и Пегги в данном случае представляют экземпляры каких-либо классов, Мастер, Клиент, Клерк и т.д (выделяем объектную модель). То есть при достаточно детализированном описании их деятельности можно определить, что является их сферой деятельности - то бишь выделить методы классов, которые будут нужны в проектируемой системе. Аналогично в рассказе наверняка промелькнет взаимодействие наших героев с другими участниками бизнес-процесса, Начальником например. А те бумажки, которые Пегги будет заполнять по ходу рассказа - документооборот внутри компании, то бишь потоки данных. Их также можно и нужно анализировать. Ну и т.д. Непринужденный стиль - это не самоцель, он служит именно для облегчения восприятия, потому что когда читаешь сухие казенные фразы, то заснуть хочется на второй строчке. У Акоффа (который Рассел) подобные изложения в казенном стиле (например постановка задачи, которую он когда-то решал) как правило дальше расписаны в доступном изложении и он сам называет это "В переводе на человеческий язык". Оставим казенные фразы бюрократам  

  

SLeN, внимательно не читала - в целом описание хорошее (степень детализации оптимальная, ни мало ни много), но над ним еще предстоит поработать.

В-частности:

1. "Система не записывает в заказ номер купона" - таких формулировок быть не должно. Нас интересует, что система ДЕЛАЕТ, а не чего она не делает. Если она чего-то не делает - просто не пишите ничего.

2. Система проверяет бизнес правила ( можно ли добавить купон к заказу )
      2.а Бизнес правила Запрещают добавление номера купона к заказу
          1. Мастер Приносит свои соболезнования клиенту
      2.б Система не может проверить бизнес правила
Где вариант: "Бизнес-правила разрешают добавление номера купона к заказу"?... Вы должны описать ВСЕ возможные ветви алгоритма, иначе возникнет исключительная ситуация, которую непонятно как обрабатывать.

3. 1. Мастер производит попытку добавить номер еще 1го купона
Такие формулировки также лучше не использовать: лучше "Мастер добавляет номер еще одного купона" (проверка того, можно ли это сделать, должна осуществляться ПЕРЕД действием).

Бегло вроде все.

Потом может посмотрю внимательнее, еще что-то напишу.

Это сообщение отредактировал(а) ida - 25.3.2008, 17:09

ida,  Спасибо!

Буду ждать вниматеьного просмотра =)

Нашла у себя книгу "Современные методы описания функциональных требований к системам" (в оригинале "Writing effective use cases"), автор Алистер Коберн.

Она вышла каким-то невероятно маленьким тиражом, но можно поискать в Интернете.
Это как раз про варианты использования.

SLeN, вот что еще пишет А.Коберн в своей книге, возможно, это будет вам интересно.

Большинство хорошо написанных вариантов использования имеют от 2 до 8 шагов (неясно, имеются ли в виду и альтернативные сценарии - скорее всего нет).

Если в варианте использования более 10 шагов, то скорее всего туда включены действия более низкого уровня абстракции. Т.е. его надо пересмотреть.

Можно еще пользоваться правилом "7+-2" - емкость краткосрочной памяти человека.