Форум Сообщества Аналитиков

×


подскажите новичку по матрице трассируемости(Прочитано 8569 раз)
Здравствуйте, уважаемые аналитики!

просветите меня пож-та вот по такой ситуации:

 - в Rational Rose есть use-case_диаграмма, на которой 2 прецедента: "Получить наличные" и "Идентифицироваться" (это для банкомата), причем
   "Получить наличные" (более высокий уровень) -- <<включает (include)>> --> "Идентифицироваться" (уровнем ниже);

 - создаю требования в RequisitePro из модели прецедентов Rational Rose (импортирую: associate model to RequisitePro);

Вот теперь в чем вопрос:

 в RequisitePro трассировочная матрица (функциональные требования-use-case_ы) должна быть такой (вар. 1):

   FUNC1: Реализовать прецедент "Получить наличные"            (трассируется на USC2: Получить наличные)
      FUNC1.1: реализовать процедуру идентификации владельца карты      (трассируется на USC1: Идентифицироватся)
      FUNC1.2: реализовать процедуру запроса суммы наличных
      ..
   FUNC2: Реализовать прецедент "Идентифицироваться"            (трассируется на USC1: Идентифицироватся)
      FUNC2.1: ..A..
      FUNC2.2: ..B..
   ..

 либо такой (вар. 2):

   FUNC1: Реализовать прецедент "Получить наличные"            (трассируется на USC2: Получить наличные)
      FUNC1.1: Реализовать прецедент "Идентифицироваться"         (трассируется на USC1: Идентифицироватся)
         FUNC1.1.1: ..A..
         FUNC1.1.2: ..B..
         ..
      FUNC1.2: реализовать процедуру запроса суммы наличных
      ..

На мой взгляд, если реализовывать вар. 1, будут проблемы в случае, когда  use-case "Идентифицироваться" включается в другие use-case_ы
(придется дублировать функц. требования в трассировочной матрице несколько раз).
Если можно, нельзя ли аргументы в пользу выбранного Вами варианта (может быть есть 3-й вариант).



Здравствуйте, уважаемые аналитики!

просветите меня пож-та вот по такой ситуации:

 - в Rational Rose есть use-case_диаграмма, на которой 2 прецедента: "Получить наличные" и "Идентифицироваться" (это для банкомата), причем
   "Получить наличные" (более высокий уровень) -- <<включает (include)>> --> "Идентифицироваться" (уровнем ниже);

 - создаю требования в RequisitePro из модели прецедентов Rational Rose (импортирую: associate model to RequisitePro);

Вот теперь в чем вопрос:

 в RequisitePro трассировочная матрица (функциональные требования-use-case_ы) должна быть такой (вар. 1):

   FUNC1: Реализовать прецедент "Получить наличные"            (трассируется на USC2: Получить наличные)
      FUNC1.1: реализовать процедуру идентификации владельца карты      (трассируется на USC1: Идентифицироватся)
      FUNC1.2: реализовать процедуру запроса суммы наличных
      ..
   FUNC2: Реализовать прецедент "Идентифицироваться"            (трассируется на USC1: Идентифицироватся)
      FUNC2.1: ..A..
      FUNC2.2: ..B..
   ..


На мой взгляд, если реализовывать вар. 1, будут проблемы в случае, когда  use-case "Идентифицироваться" включается в другие use-case_ы
(придется дублировать функц. требования в трассировочной матрице несколько раз).
Если можно, нельзя ли аргументы в пользу выбранного Вами варианта (может быть есть 3-й вариант).

Да, есть третий вариант :-). Он заключается в том, что не нужно давать собственную интерпретацию того, что есть функциоанальные требования, и что есть юзкейсы ... а просто использовать уже готовое и изложенное в книгах и в том же RUP. Т.е. вы не верно понимаете что такое функциональные требования и что есть шаги юзкейса. Из-за этого у вас и возникает такой вопрос.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



а в чем суть? как быть, может дадите ссылочку?
наскока я понимаю, use-case_ы именуются целями осн. действ. лица; т.е. функц. требования происходят от use-case_ов.



выдержка из рупа
Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration. These are often best described in a use-case model and in use cases. Functional requirements thus specify the input and output behavior of a system.

т.е. у меня все ок



1 функц требование == 1 шаг




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19