ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [모각코 23-1] 4회차- OOAD(2)
    학교생활/23-1 '모여서 각자 코딩' 2023. 4. 6. 16:35
    728x90

    목차

    Beginning


    Beginning

    Inception in a sentence :

    System 의 scope, 비전, 비즈니스 모델링을 구상한다. 이때 stakeholde(이해당사자) 의 기본적인 동의와 투자가 있어야 한다.

    Inception 의 의도 :

    실현 가능 여부 조사, decide if it is worth to do.

    Inception focuses on...

    - requirement!

    • - functional requirements --> Use case 모델링
    • - nonfunctional requirements

    - UI 구현

    - 타당성 구현

     

    요구사항 분석

    - 요구사항을 찾아서 문서화하고 유지하는 프로세스

    - 이 또한 반복적iterative 으로 도출된 결과가 시스템에 적용된다.

    더보기

    1. 이해관계자의 요구사항 정의 => also applied to SYSTEM

    |  1의 결과는 2가되어

    2. 요구사항 분석 => also applied to SYSTEM

    |  2의 결과는 3에 쓰인다.

    3. 아키텍쳐 디자인 => also applied to SYSTEM

     

    * 3->1, 3->2, 2->1 어느 방향으로든 back 할 수 있다.

     

    Requirements

    ㄴ functional requirements

    ㄴ nonfunctional requirements

     

    Functional Requirements

    시스템이 제공해야하는 서비스에 대한 설명이 적혀있다.

    시스템이 특정 입력에 어떻게 반응해야 하는지, 특정 상황에서 작동하는 방식이 적혀 있다.

    즉, 시스템의 행동 양식을 Use Case 에 기록하고 확장한다.

     

     Nonfunctional Requirements 

    시스템이 제공하는 서비스 또는 기능에 대한 제약

    시스템 전체에 적용되는 품질 요구사항

     

     

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

    - funcitional : 기능이 무엇인가 (input, output이 무엇인가?)
    - Usability : 사용성
    - Reliability : 신뢰성 (오류율 낮은지 등)
    - Performance : 성능 (응답시간, 속도 등)
    - Supportability : 유지보수 용이한지 등
     
    - U, R, P, S 등의 성격들을 non-functional requirements라고 한다.
    - non-functional requirements를 만족하지 못하면 기능이 동작하더라도 아무 쓸모가 없다. 따라서 대체적으로 non-functional requirements가 더 중요시 된다.
    - 실시간 응답 속도가 중요하다, 24시간 돌아가야 한다, 보안이 중요하다 등의 프로젝트 특성에 따라 non-functional requirements이 요구 된다. 이 요구사항 만족을 위해서 기능 측면에서의 제한도 있을 수 있다.

     

    requirement 산출물 : use case, 보충 명세서, 용어사전, 비전, 비즈니스 규칙

     

    Use case

    use case 는 모든 이해 관계자가 쉽게 목표가 무엇인지 이해할 수 있도록한 스토리 텔링이다.

    Process Sale : 고객이 구매할 품목을 가지고 계산대에 도착합니다. 계산원은 구매한 각 품목을 기록하기 위해 포스 시스템을 사용합니다. 시스템은 실행 중인 total 과 아이템을 보여줍니다. 고객이 결제 정보를 입력하면 시스템이 이 정보를 확인하고 기록합니다. 시스템이 인벤토리를 업데이트합니다. 고객은 시스템으로부터 영수증을 받은 다음, 물품을 가지고 갑니다.

     

    Scenario

    = use case instance

    시나리오는 행위자와 시스템 간 구체적인 행위 연속과 상호작용을 작성한다.

    성공적인 시나리오 : 고객이 반품할 물품을 가지고 계산대에 도착합니다. 출납원은 포스 시스템을 사용하여 반품된 각 품목을 기록합니다.

    대안 시나리오 : 고객이 신용카드로 지불했는데, 신용 계좌로 환불 거래가 거절되면, 고객에게 알리고 현금으로 지불합니다.

    시스템에서 바코드를 읽을 수 없는 경우, 출납원에게 알리고, 바코드 숫자를 수동으로 입력할 것을 제안합니다.

    시스템이 외부 회계 시스템과의 통신 실패를 감지하는 경우 ...

     

    728x90
Designed by Tistory.