요구 분석 - 유스케이스 다이어그램

iskull-dev.tistory.com/123

요구분석

iskull-dev.tistory.com/124

요구분석 - 요구사항의 표현

유스케이스

  -요구 사항을 발견하고 기록하기 위해(목적을 달성하기 위해) 널리 사용되는 텍스트로 작성된 스토리

  -다이어그램: 한 응용프로그램의 전체 기능을 보여 주는데 유용하다

  -유스케이스는 객체지향과는 관련이 없다

  -엑터

    -이 시스템을 통해 어떤 이익을 얻을 수 있는 것(사람, 컴퓨터 시스템 등), 어떤 행위를 갖는 어떤것

    -주요 엑터: SuD(System under Discussion)을 사용해 사용자의 목적을 수행

    -지원 엑터: Supporting actor: SuD에 서비스를 지원

    -숨겨진 엑터: 주요 액터나 지원 액터가 아니면서, 유스케이스 행위에서 이해 관계를 가짐

  -시나리오

    -엑터와 시스템 사이의 활동, 상호 작용에 대한 명확한 순서

    -시스템을 사용하는데 있어서 하나의 특정 스토리

    -유스케이스 내를 흘러가는 하나의 경로

  -유스케이스

    -엑터가 목적을 달성하기 위해 시스템을 사용할 때 발생 가능한 성공 시나리오들과 실패 시나리오 들의 집합

  -유스케이스 모델: 유스케이스들 + 다이어그램

    -유스케이스는 요구사항을 표현-> 주로 기능적 또는 행위적 요구사항을 표현

유스케이스 명세 항목 - 기타

  -기타:

    -특수 요구사항

       -주로 비기능적 요구사항을 기술

       -현재 유스케이스에서 성능, 신뢰성, 사용성과 같은 품질에 관련된 요구사항을 기술

     - 기술, 데이터 변동 리스트

       -기술적 변화나 데이터 구조의 변동 등을 기술

  유스케이스 작성 가이드 라인

    -UI와 관련된 상세한 부분은 언급하지 않는 것이 중요

    -블랙박스 유스케이스를 작성

      -유스케이스는 시스템의 책임을 상세히 기술해야 한다.

         -'What' the system should do를 기술한다

         -'how'the system will implement the solution의 기술은 피해야 한다.

    -한 엑터와 엑터-목적 관점을 고려

       -RUP의 유스케이스 정의

           -유스케이스 인스턴스들의 집합. 인스턴스는 특정 액터가 인식할 만한 의미 있는 결과를 얻게 하기 위해 시스템이 수행해야 하는 활                동들의 순서이다

       -요구사항 분석에서 중요한 자세

          -사용자의 목적과 전형적인 상황에 대해 질문하면서 시스템의 사용자나 액터에 초점을 맞추어 요구사항을 작성하라

          -액터에게 의미 있는 결과가 무엇인지를 이해하느 것에 초점을 맞춰라

       -유스케이스를 찾는 방법

          -유스케이스 정의 절차

            1. 시스템 경계 결정

                 경계가 명확하지 않다면: 외부 주요 액터 또는 지원 액터 찾기

            2. 주요 액터와 목적 찾기

                 -주요 액터: 시스템이 서비스를 이용해 목적 달성

                 -지원 액터: 시스템에 서비스 제공

                 -액터와 목적을 찾기 위한 질문

           -액터와 목적을 구성하는 방법

                1. 액터와 목적을 발견할 때 마다 유스케이스로 목적을 명명하고 다이어그램을 그린다.

                2, 액터-목적 리스트를 작성한다.

          4.유스케이스 정의

               -하나의 목적을 하나의 유스케이스로 정의

  -유스케이스 수준 식별을 위한 테스트

    -boss 테스트

    -EBP(elementary business process) test

        -측정할 만한 비즈니스 가치를 내고, 일관된 상태로 데이터를 남기는 비즈니스 업무로 한번에 한 장소에서 한 사람에 의해 수행되는 업           무

    -size 테스트

       

유스케이스 다이어그램이란

  -유스케이스: 모델화 대상이 외부에 제공하는 서비스. 액터가 이용함

  -관계 정의: 관련된 액터와 유스케이스. 관계 정의는 관련성을 나타낼 뿐 액터가 유스케이스의 행위자는 아님

  -시스템 경계: 시스템화 대항 범위

사용처:

  -모델화 하려고 하는 대상의 대략적인 내용을 간결하게 나타낼 수 있기 때문에 제일 먼저 작성

  -모델화 대상의 내부 구조를 파악하기 보다는 외부에서 보았을 때 대략 어떻게 구성되어 있는지를 알 수 있다.

  - 유스케이스 수에 따라 대상에 대한 규모를 예측할 수 있다.

주의사항

  -목적(독자)를 확인한다. 독자에게 의미가 있는가?

  -명명법에 주의한다. 

     -추상도: 대상이 제공하는 서비스를 문장으로 설명할 경우 사용하는 정도의 추상도가 적당한다. 유스케이스 명은 사용자 메뉴얼 ㅁㄱ차                 수준으로 작성

    -정확성: 작성자의 의도가 정확하게 전달 되도록 명명. 서비스의 대상과 서비스가 제공해야 될 것을 명시(목적어 + 동사형)

    -표현의 통일: 동일한 의미에 대해 여러개의 용어를 사용하지 말것

  -규모를 동일하게 한다(CRUD가 동일하게 배부되야 한다.)

    -규모: 유스케이스가 나타내는 서비스의 크기

    -규모를 동일하게 함으로써 유스케이스의 수를 통해 시스템 전체의 작업 규모를 예측할 수 있음

  -기능 분할을 하지 않는다

    -기능 분할 유스케이스: 대상이 제공하는 서비스가 아니라 대상이 가지고 있는 기능을 추출. 서비스가 아닌, 서비스를 실현하기 위해 필요         한 기능을 다이어그램으로 정의한것

    -기능 단위로 분할되면 유스케이스의 규모가 너무 작아 모델화한 대상이 어떠한 서비스를 제공하고 있는지 알 수 없음

    -유스케이스의 규모가 너무 작으면 액터에게 의미 있는 서비스가 아닌, 이용 목적을 알 수 없는 하나의 기능이 됨

  -<<include>>, <<extend>>, 일반화 관계를 혼동하지 않는다

      -<<include>>: 베이스 유스케이스를 실행하기 위해서는 <<include>>로 연결되 있는 유스케이스가 반드시 필요하다

      -<<extend>>: 베이스 유스케이스를 실행하기 위해 <<extend>>로 정의되어 있는 유스케이스를 실행할 경우에는 반드시 베이스 유스                    케이스가 필요함

     -일반화: 기본적으로 기능의 추가 관계를 나타낸 것이 아니다. 개념만 공유할 뿐 완전히 새로운 유스케이스를 정의한다.

유스케이스 정의서