Software Engineering 4 - FURPS+ & Use case

 Core application logic과 UI element와 연결되는 방식 - Domain object layer
* Inception phase : vision, cost, feasibility 등등을 판별하는 프로젝트 시작 전의 약 일주일 정도 과정. 이는 짧고 iteration 하지 않으며 requirement analysis가 아니고 해당 작업을 수행하지도 않는다. (RA는 elaboration phase에서 발생한다)
이 과정에서 business-case, use-case model 등이 만들어진다. 단, 모두 만들어지는 것은 아니고 대략적인 use-case 들의 이름들과, 약 10% 정도의 중요한 것들의 detail 정도만 제작된다. 이외에도 non-functional requirement(supplementary specification), glossary(용어집), risk management plan/prototype, development case등등을 만들 수 있다. 다만, 이 것들을 모두 만드는 것이 아니라 필요한 것만 시행한다.
이 과정은 UML diagram을 많이 사용하지 않고 text form의 use-case 정도만 사용한다.

Requirements in UP
requirement : 제작할 시스템이 만족해야 하는 capabilities & conditions(기능적, 비기능적 요구사항을 모두 포함)
UP의 특성상 반복적이고 체계적으로 requirement를 분석하게 된다. 이는 use-case나 데모 등을 통해 사용자와 개발자의 소통을 중시하고, 피드백을 받아 구현하게 된다. 

FURPS+ : UP의 requirements
- Functional
- Usability
- Reliability
- Performance
- Supportability
- Constraints : implements, interface, operation, packaging, legal(licensing)

F와 +를 제외한 URPS는 Quality requirement라 하며 이들은 아키텍처 디자인의 중요한 기반이 된다. Functional Requirement(FR)을 제외한 나머지 (URPS+)는 Non-functional requirement(NFR)라 하기도 한다. (따라서 소프트웨어 공학의 requirement는 FR과 NFR로 나눌 수 있다.)
Use-case model은 주로 FR(behavioral)을 표기하는데 사용된다. NFR은 supplementary specification에 포함된다.




Software Requirements

F : 기능과 시스템 서비스를 명세함. 특정 input이나 상황에 대해 어떤 output을 내고 어떻게 행동해야 하는지(behavior in particular situation), 시스템이 어떤 서비를 제공하는지 등을 나타낸다.
URPS+ : 상기한 것을 제외하고 나머지 모든 것. system이나 domain의 property를 나타내며 이는 quality attribute와 constraint로 나눠지게 된다. (단, quality attribute는 특정 상황에서 희생되거나 강화되는 것이 있을 수 있지만 constraint는 반드시 지켜져야 한다) 일반적으로 NFR이 FR보다 더 중요하게 여겨지며 작동하는 시스템이 있다 하더라도, 이런 요구사항이 지켜지지 않는다면 쓸모없게 되기 때문이다.

NFR : 시스템의 전체 아키텍쳐에 영향을 미치며 관련된 FR이 추가로 발생할 수 있다. (보안 관련 등) 또한 기존 requirement와 상충되어 어느 것 하나를 제한해야 하는 상황도 가능하다.
- Product requirements : 해당 제품이 반드시 행동해야 하는 방식 정의. (실행 속도, 신뢰성)
- Organizational requirements : consequence of organization, policies, procedures. (implementation requirement)
- External requirements : 시스템 외적인 부분, 개발 과정과 연관된 것들. (법률 등)
* NFR은 객관적으로 측정가능해야 하므로 (verifiable) 주로 speed, size, reliability, robustness 등등 일반적으로 측정가능한 measurement를 기준으로 성능을 체크해야 한다.
FR : use-case를 사용하여 요구사항을 분석한다.전통적으로는 각 요구사항을 실행하는 함수와 세부사항을 명세하였지만 이는 사용자 입장에서 각 함수를 유기적으로 연결하여 사용하기가 어렵다는 단점이 있다. (각 함수가 독립적으로 기술되어 있기 때문)
따라서 현대에는 요구사항 명세와 분석, 추출에 use-case를 더 많이 사용한다. 이 방식은 주로 interactive system에 잘 맞으며 전체 요구사항보다는 functional requirement에만 집중한다.

Requirements Validation
일반적으로 요구사항은 모두 사람에 의해 만들어지기 때문에 잘못 기술되거나 오해를 살 수 있다. 이런 defect들은 빨리 고칠 수록 비용이 적게 드므로 software requirement specification의 초기 단계에서 수정하는 것이 효과적이다.
많이 발생하는 에러는 omission(누락), inconsistency, incorrect, ambiguity 등등이 된다.
따라서 올바른 requirement analysis는 unambiguous, correct, complete, consistent, feasible(achievable), traceable(소스코드 변경을 추적 가능) 등의 속성이 만족되어야 한다.

Software requirement Specification(SRS)
개발될 소프트웨어 시스템에 대한 description. 각 개발 기구에 따라 서식이 다양하게 구성된다.
UP에서는 vision, glossary, supplementary spec 등등 각 분야 별로 필요한 문서(명세)를 다르게 적용한다.

Requirement Elicitation & Analysis
요구사항을 분석 및 추출하기 위해서는 시스템의 목적을 밝혀내고, 해당 시스템을 구성하기 위해서는 내외적으로 어떻게 구성해야 하는지를 알아내야 한다. 이를 해결하기 위해 elicitation은 사용자의 입장에서 시스템을 서술하는 방식을 취하고, analysis는 개발자의 입장에서 시스템을 기술한다. (analysis model)

- Use-case : actor(외부 사용자 & role) - System 사이의 interaction을 기술하여 시스템의 external behavior를 나타낸다. actor가 system을 사용하여 goal에 다다르는 과정을 textual stories로 나타내므로 일반적으로 textual form으로 구성되어 있으며 필요할 경우 diagram을 사용할 수 있다. 또한 사용자 입장에서 시스템을 분석하여 요구사항을 추출할 때도 사용될 수 있다.
- Use-case Model : UP에서는 모든 use-case 들과, 이들을 통해 나타낸 시스템의 functionality & environment(내외부를 분리)를 requirement discipline으로 정의한다. use-case model은 이해를 돕기 위해 그림으로 text를 그림으로 나타낸 use-case diagram을 포함할 수도 있다.
use-case format에는 3가지가 있으며, 각각 얼마나 많은 scenario를 기술하냐에 따라 달라진다. 이상적인 작동 시나리오만 서술하는 경우 brief가 되고, 오작동하는 몇 가지 alternate scenario를 포함하면 casual, 모든 step과 variation을 포함한다면 fully dressed 라 한다.

Actor : 우리가 목표 달성을 위해 설계한 system과 interaction하는 person/system
Primary actor : main actor initiates use-case
Supporting actor : system에 대한 service를 외부에서 제공하는 actor
offstage actor : use-case의 behavior와 연관되어 있지만 primary하지 않고 부가적이며 supporting 하는 것에 한정되어 있는 actor.

Scenario(use-case instance) : set of actions to achieve the goal under the condition. 이는 main success와 alternate로 나누어지는데 상황이 올바르게 흘러갈 때와 그렇지 않을 때를 구분하여 나타낸다. use-case는 이런 여러 시나리오의 결합으로 구성된다. (UC = collection of scenarios)

*로 표기되는 alternate scenario는 모든 step에서 발생될 수 있다는 것을 나타내며, 1a, 3b 등으로 표기되는 시나리오는 해당 번호 step의 여러 alternate를 나타낸다.
stakeholder(이해당사자) : use-case와 관련이 있는 모든 사람, 시스템 영향의 범위를 설정한다. (interest list)

Success Guarantee(postcondition) : system의 main success가 달성되었을 때 우리가 원하는 상황의 조건들. 예를 들어 포스기의 작동이 완료되었다면, 거래 내역이나 세금 등이 올바르게 지불되고, 재고가 업데이트 되는 작업 등이 이에 해당한다. 

Scope : system이 디자인 되는 범위. 어떤 시스템 혹은 비즈니스 단위(enterprise)의 범위를 설정하여 설계할 수도 있다.

level : user-goal level과 subfunction level로 구분되며 default는 user-goal level이다. 이는 primary actor가 goal을 달성하는 일련의 과정을 나타내는 것이다. sub function은 user goal을 달성하기 위한 substep들이 반복될 경우, 이를 함수화 하여 매번 다시 기술하지 않고 해당 함수를 불러오는 것으로 대체하는 것을 나타낸다. 예를 들어 어떤 상품이나 서비스를 결제할 때 카드를 사용하여 결제하는 과정이 있을 경우, 반복적으로 해당 결제를 모두 기술하지 않고, 카드를 사용하는 것을 하나의 sub function으로 만들어 놓는 것이 해당한다.
Main success scenario와 extension(alternate)를 합치면 거의 모든 stakeholder의 interest를 만족시킬 수 있다.

*Guideline
사용자의 구체적인 작업(어디에 무엇을 써넣고 무엇을 받는다 등)을 기술하게 되면, 해당 파트가 UI에 dependent하게 되어 좋지 않다. 따라서 요구분석 단계에서는 이런 concrete style보다는 사용자가 어떤 작업을 하는지 필수적인 것만 나타내는 Essential style을 사용하는 것이 좋다. (사용자가 신원을 식별한다, 시스템이 그것을 확인한다 등) 같은 맥락으로, 내부 작동원리를 세세하게 설명하는 것보다는 block-box style로 작성하는 것이 더 바람직하다.
user/actor에 초점을 맞춰 해당 사용자가 달성하고 싶은 goal과 situation을 중심으로 작성하는 것이 좋다.

procedure : choose system boundary - Identify primary actor - identify the goals for each actor - define use cases to satisfy the goals

이는  actor-goal list를 만들고 각 리스트에 해당되는 것들을 고려하여 use-case diagram을 그리는 방식으로 진행된다. 그리고 사용자가 어떤 활동을 하는지 보다는 어떤 goal을 성취하고, 그것을 측정할만한 것이 어떤 것이 있는지 알아내야 좀 더 정확한 시스템을 만들어 낼 수 있다. (사용자 자신도 어떤 것이 필요한 지 정확히 모르는 경우가 있을 수 있기 때문)
scope에 따라 primary actor는 바뀔 수 있다. 마찬가지로 use-case의 scope도 level에 따라 매우 세부적인(log in 등) 것 부터 거시적인 것 (B2B 협상 등)까지 다양하게 가능하다. 그렇지만 만드려고 하는 시스템의 사이즈에 따라 적절한 level을 선택해야 하므로 몇 가지의 테스트를 통해 적절한 level을 찾게 된다.

- Boss test : 해당 use-case로 나타내려는 작업이 상사의 관점에서 보았을 때 충분히 의미가 있는일인가 를 확인. 측정가능한 value가 있는 것이 좋다.
- Elementary Business Process(EBP) : 한 사람이 실행할 수 있는 일의 단위 정도를 의미하며 business event와 같은 맥락으로 어떤 측정가능한 value를 생산해 내야 한다. 따라서 어떤 시간에 어떤 사람이 시행하는 일 단위만큼을 use-case로 끊어 나타내는 것이다. 이는 single이 아니라 약 5~10개 정도의 step으로 구성된다.
- Size test : 상기한 것과 비슷하게, single step으로 구성되는 use-case는 별로 중요하지 않고 쓸데도 없으므로 여러 개의 task와 step으로 구성되는 use-case를 만드는 것이 좋다.
이런 test에 통과하지 못하더라도 필요성/중요성이 있는 task라면 use-case로 만들 수 있다. 앞서 말한 것 처럼 반복되는 기능을 sub function으로 빼 놓아 사용하는 것은 single step일 수 있지만 이를 통해 더 편리하게 기능 명세를 할 수 있으므로 사용하는 것이 좋다. 마찬가지로 하나의 step으로 보일지라도 복잡한 기능 구현이 필요한 경우에는 use-case를 사용하는 것이 좋을 수 있다.

Use-case Diagram
use-case의 text를 이해하기 쉽도록 정리하여 나타낸 UML. context를 이해하는데 도움을 주어야 하므로 최대한 간단하고 쉽게 그리는 것이 좋다.