소프트웨어공학 - 6. Requirement, Use cases

1. Requirement

- UP에서 requirements를 나타내는 모델을 FURPS+ 모델이라고 한다.

- funcitional : 기능이 무엇인가 (input, output이 무엇인가?)

- Usability : 사용성

- Reliability : 신뢰성 (오류율 낮은지 등)

- Performance : 성능 (응답시간, 속도 등)

- Supportability : 유지보수 용이한지 등

- constraints : 이 기능이 수행되어야 하는 메모리, 시간 제한, 어느 운영체제 위에서 돌아가하는지, 디자인 제약 등

 

- U, R, P, S, C, security 등의 성격들을 non-functional requirements라고 한다.

- non-functional requirements를 만족하지 못하면 기능이 동작하더라도 아무 쓸모가 없다. 따라서 대체적으로 non-functional requirements가 더 중요시 된다.

- 실시간 응답 속도가 중요하다, 24시간 돌아가야 한다, 보안이 중요하다 등의 프로젝트 특성에 따라 non-functional requirements이 요구 된다. 이 요구사항 만족을 위해서 기능 측면에서의 제한도 있을 수 있다.

- 이런식으로 요구사항과 그 요구사항의 만족 여부를 측정하기 위한 방법들을 정의할 수 있다.

- ex) 사용성 : 사용자가 사용 과정에서 오류가 발생하는 횟수

- 우리가 분석한 요구사항들은

• 모호성이 없고,
• 사용자의 요구사항을 올바르게 반영하고 있으며,
• 사용자의 모든 요구사항을 파악했는지,
• 요구사항끼리의 모순은 없는지,
• 요구사항이 실제로 구현 가능한지,
• 개발이나 변경이 생겼을때 쉽게 요구사항 명세를 추적할 수 있는지

- 를 만족해야 한다.

2. Use cases 

- 개발하려는 functional requirement를 기술하고 파악하는데 많이 쓰이는 방법이다.

- interactive system을 묘사하는데 특히 효과적이다.

- 외부에서 관찰 가능한 기능을 중심으로 명세한다.

- 기본적으로 텍스트 형태를 띠나 보조용으로 diagram도 활용된다.

- actor가 system과의 interaction을 통해 goal을 성취하는 action을 main success scenario라고 한다. 

- 예외 사항에 따라 다르게 반응해야 하는 경우를 alternate scenario라고 한다.

- 즉 use cases는 다양한 scenario의 집합이다.

 

- use case를 정의하면 개발하려고 하는 프로젝트의 범위를 확립할 수 있다.

- 즉 내가 이 use case를 만드는 경우 어느 scope까지 담당해야 하는가?를 쉽게 알 수 있다.

- use case는 프로젝트의 여러 이해 관계자(stakeholders)들이 공유하기에도 용이하다.

 

- use case는 actor를 가정하고 system을 사용해서 목표를 달성하기 위해서 정리된 text stories이다.

- 요구사항을 파악하고 명세하는데 용이하다.

- Pos 시스템을 사용해서 sale을 수행하는 요구사항을 위처럼 명세할 수 있다.

 

Actor

- 우리가 개발하고자하는 시스템과 interact하는 사용자 혹은 다른 시스템을 말한다. (actor initiate use case)

- actor는 system의 일부가 아니라 system 밖에있는 대상이다.

- Primary Actor : user goal을 가지고 있는 actor (ex. 사용자)

- Supporting Actor : 시스템 외부에서 작업을 도와주는 actor (ex. api들)

- Offstage Actor : 그 외에 연관된, 직접적 interact는 없지만 관계가 있는 actor들

Scenario

- actor가 goal을 달성하기 위해 수행하는 일련의 action들을 말한다 (use case의 instance)

 

- 결국 use case는 scenario들을 다 모은 것을 말한다. success scenario도 있지만 failure scenario도 있다. (ex. 계산 성공 시나리오, 계산 실패 시나리오)

3. Use case example

- use case 1은 주식을 사는 기능을 명세하고 있다.

- 구매자와 company가 서로 원하는 결과가 있다. 구매자는 주식을 원하고 기업은 거래 정보를 원한다.

- use case가 시작되기 위해 필요한 조건인 account를 사용자가 가지고 있는지? 조건도 보인다.

- 사용자가 성공적으로 주식을 구매하는 시나리오와 구매에 실패했을 때 발생가능한 시나리오도 명세되어 있다.

4. Software Requirement Specification (SRS)

- 이렇게 파악한 requirement들을 document처럼 정리하는 것을 말한다.

- 다양한 방식으로 정리될 수 있다.

5. Use-case Model

- UP는 기본적으로 use case model을 discipline으로 정하고 있다.

- use cases들을 파악해 최종 use case model을 만든다.

- use case diagram들을 활용할 수 있다.

- 우리가 만들려는 시스템의 environment, functionality를 담고 있다.

6. Use case Format

- 명세하는 구체적인 정도에 따라 결과물이 다를 수 있다.

- brief : 간결하게 한 문단으로, main scenario 혹은 성공(happy path)시나리오만 명세

- casual : 여러 문단으로 구성, 성공, 실패 등 다양한 scenario를 내포

- 물건 반품 시나리오의 예시이다.

- fully dressed : 여러 제약과 명세 단계들을 포함한다.

- cashier가 물건을 판매하는 use case를 기술해보자.

- scope : 시스템 대상

- level : 사용자의 목적 달성(user-goal level), 다음 작업을 위해 중간 결과물이 필요한 경우(subfunction level)

- stakeholders and interest : 이 use case와 관계된 관계자들과 그들이 필요로하는 관심사항들

- preconditions : use case가 수행되기 전에 전제되어야 하는 상황 (ex. 로그인)

- success guarantee : use case 수행 후 기대하는 상황 (ex. 물품재고db업데이트 판매정보 기록 등)

- main success scenario와 그 외의 extensions(alternative flows)도 명시했다. 여기서 한가지 눈의 띄는 표기법은 1a이다. 성공 메인 시나리오 1번에서 다르게 발생할 수 있는 flow를 1a라고 표현했다.

7. use case 작성 가이드라인

- concrete style보다는 essential style로 작성하자.

- ui, 아이디 비밀번호 입력 방식등이 바뀔수도 있다. 그런 의존도를 최대한 낮추는 핵심 동작만 표현하자.

- 당연히 표현은 짧고 명확해야 한다.

- 요구사항과 결과만 집중하라. internal working이 어떻게 이루어지는지는 신경쓰지마라. 우리가 하고 있는 일은 요구사항만 파악하는 것이다.

- 요구사항이 파악되는 대로 순서대로 적어도 되지만 이렇게 actor마다의 goal list를 정하고 시작해도 좋다.

- domain이 확장될수록 primary actor가 다를 수 있다.

 

- 댓글달기 -> 글 작성 -> 사진 올리기 -> 로그인 -> 회원가입 처럼 low한 수준까지 use case를 파악하려고한다면 그게 오히려 일이 될 수 있다. 그렇다고 너무 high level로 잡으면 detail이 부족해진다. 

- use case가 잘 만들어졌는지 판단할 수 있는 세가지 test 방식을 알아보자.

The Boss Test

- boss가 use case를 봤을때 맘에 들어하겠냐?는 관점

The EBP Test

- Elementary Business Process를 줄인말이다.

- 한 사람이 한번에 한 곳에서 수행하는 task 단위로 use case를 파악하도록 한다.

The Size Test

- single step이 아니라 여러 step으로 구성된 use case가 유용하다.

 

- 예를 들면 로그인(boss test fail), 게임판에서 말 옮기기(size test fail, single step), 물품 판매(Good)

8. Use case diagram (뒤에서 더 자세히)

- text 형태의 use case(이게 메인임)를 보조하는 수준으로 쓰일 수 있다.

- 간단하고 심플한 그림을 활용한다.

- 시스템은 네모를 사용

- use case는 동그라미 사용

- actor는 보통 stick man을 많이 사용한다.

- actor와 use case는 반드시 연결되어야 하고 1..3처럼 여러명과의 관계를 나타낼수도 있다.

9. UP와 use case

- inception : 2일 짜리 워크샵을 통해 requirement들을 짧은 문단 단위로 전부 파악해본다. 여기서 risk가 높거나 architecture-centric하거나 business value가 높은 작업(10퍼센트정도)에 높은 우선순위를 부여해서 상대적으로 깊게 더 조사한다.

- elab1  :  inception에서 파악한 10퍼센트의 우선순위 높은 작업들을 먼저 수행한다. (개발)

- elab후반부 : 중요도가 좀 낮은, 자세하게 분석되지 않은 use case를 보강하고 개발한다.