[Object Oriented S/E] Chapter 7 - Deriving Use Cases from Requirements

# 범위

172 page ~

# 내용

## 7 Deriving Use Cases from Requirements

• 요구사항은 시스템이 반드시 제공해야하는 기능이다.
• 요구사항 선언문은 시스템이 무슨 기능을 제공해야하는지에 관한 선언문이며, 어떻게 시스템이 그것들을 전달한것인지에 대한 것이 아니다.
• Use-case는 비즈니스 도메인에 대해서 부족한 통찰력과 이해로 생기는 유저와의 불일치에 대한 해답을 제공한다.

 

## 7.1 WHAT IS AN ACTOR?

• 시스템은 요청을 받고 유저로부터 입력등 받는다. 그리고 결과를 유저에게 전달한다.
• 전통적으로 유저는 "human(인간)"유저를 나타냈다. 더 넓은 스코프에서 유저는 인간과 비인간 모두를 나타낸다. 그리고 이를 표현하는 중립적인 단어가 필요하다.
• Actor는 역할을 한다. 외부 시스템 그리고 시스템과 상호작용을 하는  엔티티나 이해당사자들이다.

## 7.2 WHAT IS A USE CASE?

• ATM의 사용 예제들 든 후, 이러한 일련의 과정은 business process를 묘사하고, 어떻게 유저가 system을 수행해나가는지에 대해서 알 수 있다. 시스템 개발은 이러한 business processes 명확히 하는데 초점을 두어야 하고, 그것이 use cases로 모델링 되어지는 것이다.
• use case는 business process이다. 이것은 actor로 시작해서 actor로 끝내야 한다. 그리고 actor의 비즈니스를 작업을 성취한다.
• use case는 business processes이며 ATM예제에서 돈 입출금, Check Balance와 송금이 이에 해당했다.
• actor에 의해서 수행을 시작한다.
• actor에 의해서 수행이 끝난다.
• actor를 위한 business task를 수행시킨다.

 

## 7.3 BUSINESS PROCESS, OPERATION, AND ACTION

• use case는 과정이지 명령이나 행위가 아니다. 
• 예를들어 데이터베이스와 동기화 하는 과정이나, 은행 서버에 연걸하는 것, 패스워드를 입력하는 것은 use case가 아니다.
• 이것은 login process의 과정중 하나이다. login process가 use case가 된다.
• 이러한 것들을 구분하기 위해서 아래의 원칙을 따른다.
  • [비즈니스 프로세스는 (특정 비즈니스 목적을 가진) 전체 비즈니스 작업을 수행하는데 필요하고 충분한 일련의 정보 처리 단계이다]
  • [Operation은 비즈니스 프로세스의 한단계를 달성하기 위한 일련의 조치이다]
  • [Action은 작업 수핸중에 수행되는 분리할 수 없는 행위이다]
• operation은 business task를 완수하지 않는다. 그것은 오로지 business process의 일부 과정을 성취하기 위한 것이다. 그러므로 이것들은 use case가 아니게 되는 것이다.

 

## 7.4 STEPS FOR DERIVING USE CASES FROM REQUIREMENTS

1. Identifying use cases. ( use cases를 파악해라 )
   • 요구사항으로부터 비즈니스 프로세스를 파악해라
   • actor를 끌어내라
   • 요구 명세서에서 동사-명사어구를 찾아라
2. Specifying use case scopes. ( use case의 스코프를 특정해라)
   • 고수준의 use case를 특정해라. 그리고 해당 member들이 언제 시작하고 언제 어디에서 끝나는지 알아내라
   • wicked problem은 no stopping rule이었기 때문에, 팀원들은 이걸 언제 멈춰야 하는지 알아야 한다.
   • 고수준의 use case는 해결책을 제시한다.
   • [고수준의 use case는 언제 어디서 use case가 시작되고 끝내는지를 구체화 해준다, 즉 use case의 범위를 지정해준다]
3. Visualizing use case contexts.( 시각화해라)
   • 실제 세계에서의 어플리케이션은 많은 use case와 actor, subsystem들이 존재하기 때문에, 문자로 표현하기에는 한계가 있으며 UML을 사용해서 시각화 해야 한다.
   • [상속은 한 개념이 다른 개념의 일반화가 되는 두 개념 사이의 이진 관계입니다.]
4. Reviewing the use cases and diagrams. (리뷰해라)
5. Allocating the use cases to iterations. ( 반복작업에 use case를 할당해라)
   • use case를 배포하고 개발하기 위한 스케줄을 생성하는 것이 단계이다.
   • 고수준의 use-case는 고객의 비즈니스 요구와 우선순위를 충족 할 수 있도록 가능한 빨리 수행해야한다.

 

## 7.5 GUIDELINES FOR USE CASE DERIVATION

• [use case는 기능적 requirement에서 도출해야한다]
• [use case는 비기능적 요구사항에서 도출될 수 도 있다]
• [동사-명사구를 신중하게 선택하여 actoreㅡㄹ이 정확히 어떤 결과를 가져올지 전달해야 한다]
• [고수준의 use case는 actor가 달성하고자 하는 것으로 끝나야 한다.]
• [use case는 actor에게 정확히 하나의 비즈니스 과제(기능적 응집)을 수행해야한다.
• [고수준의 use case는 background processing activites를 처리하지 않아야 한다]
• [하나의 다이어그램에 많은 use case가 있는 것을 피하고, use case간의 많은 관계가 있는 것을 피하고, 전반적으로 다이어그램이 복잡해지는 것을 피해야 한다.]
• [actor 상속을 통해서 연결을 줄인다]

 

## 7.6 APPLYING AGILE PRINCIPLES

• [고객과 가깝게 일하고, 고객이 원하는 비즈니스 프로세스를 명확히 이해야한다.]
• [팀멤버는 use case를 파악하기 위해 함께 일해야 한다.]
• [요구 사항은 변화하지만, timescale은 고정되야 한다.]
• [작은 증가들의 잦은 전달에 중점을 준다]
• [최적화된 set을 전달하려 하지말고, Good enough is enough임을 명심해라 ]