요구분석
SW개발의 목적 -개발된 SW의 고객 만족 -고객 만족을 위한 특성 -적시성: 빠른 출시를 통한 시장의 점유 -유연성: 다양한 환경에서의 적응성 -통합: 기존 시스템과의 쉬운 통합 -고객만족의
iskull-dev.tistory.com
요구분석 - 요구사항의 표현
iskull-dev.tistory.com/123 요구분석 SW개발의 목적 -개발된 SW의 고객 만족 -고객 만족을 위한 특성 -적시성: 빠른 출시를 통한 시장의 점유 -유연성: 다양한 환경에서의 적응성 -통합: 기존 시스
iskull-dev.tistory.com
유스케이스
-요구 사항을 발견하고 기록하기 위해(목적을 달성하기 위해) 널리 사용되는 텍스트로 작성된 스토리
-다이어그램: 한 응용프로그램의 전체 기능을 보여 주는데 유용하다
-유스케이스는 객체지향과는 관련이 없다
-엑터
-이 시스템을 통해 어떤 이익을 얻을 수 있는 것(사람, 컴퓨터 시스템 등), 어떤 행위를 갖는 어떤것
-주요 엑터: 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>>로 정의되어 있는 유스케이스를 실행할 경우에는 반드시 베이스 유스 케이스가 필요함
-일반화: 기본적으로 기능의 추가 관계를 나타낸 것이 아니다. 개념만 공유할 뿐 완전히 새로운 유스케이스를 정의한다.
유스케이스 정의서
