[SW설계 요구사항 분석 및 설계_2]

CS·2025년 7월 11일

SW설계

목록 보기
13/13
  • EARS 방식으로 차량 네비게이션 시스템의 새로운 요구사항에 대해 작성

  1. 다차선 정보 제공 (Ubiquitous)
    The Navigation system shall provide real-time multi-lane guidance, including the number of lanes and recommended lane changes before maneuvers.
    🡺 기존 내비에서 차선 안내는 있지만, 실시간으로 여러 차선의 정보와 정확한 현재 차선 표시까지는 없는 경우가 많음.

  2. 도로 공사 구간 자동 회피 (Optional)
    If a road construction zone is detected on the planned route, the Navigation system shall recalculate an alternate path to avoid the construction area.
    🡺 실시간 공사 구간 회피는 대부분 제공되지 않음.

  3. 도로 경사도 안내 (Ubiquitous)
    The Navigation system shall display road gradient information to the driver during navigation.
    🡺 경사도(언덕 정보 등)는 보통 표시되지 않음.

  4. 야간 시야 확보를 위한 주변 밝기 안내 (Optional)
    If the vehicle is operating at night and the surrounding area has poor lighting, the Navigation system shall alert the driver to reduced visibility conditions.
    🡺 주변 조도 기반 주의 알림은 일반적인 내비에는 없음.

  5. 운전자 맞춤 경로 추천 (Optional + State-driven)
    If the driver has a preferred driving style profile set (e.g., fastest, scenic, fuel-saving), and a matching route is available, the Navigation system shall prioritize that route.
    🡺 개인화된 경로 추천 기능은 대부분 부재.

  6. 날씨 기반 경로 변경 제안 (Optional)
    If severe weather conditions are detected along the route, the Navigation system shall suggest an alternative safer route.
    🡺 기상 조건 반영한 경로 우회는 아직 일부 고급 시스템에만 있음.

  7. 운전자 피로도 고려한 휴게소 추천 (State-driven)
    While the vehicle has been driving continuously for over 2 hours, the Navigation system shall recommend nearby rest areas or service stations.
    🡺 연속 주행 시간 기반 휴식 유도는 고급 기능으로 아직 널리 퍼지지 않음.

  8. 복수 목적지 자동 최적화 기능 (Optional)
    If multiple destinations are registered, the Navigation system shall optimize the visit sequence to minimize total travel time or distance.
    🡺 목적지 순서 자동 최적화는 일반 내비에서는 제공되지 않음.

  • 요구사항 추출 :

요구사항을 발견하기 위한 첫 번째 Process
요구 공학(요구 사항을 찾는 과정)
기반으로 하면 어느정도 신뢰보장(Reasonable)
개인 의견(Opinion)이 아닌 신뢰도가 있는 기존 검증 방식을 쓰는게 낫다.

Coder가 아닌 설계를 중요시 해야됨

고객은 추상적인 요구(needs)를 하고(요구사항 x)
이해관계자들은 잘 협의해서 구체적 요구사항(Candidate Requirements)으로 만든다.

고객과 협의할 땐 Prototype(주요 기능만)으로 소통하는게 좋으나,
Prototype도 Paper -> SW로 단계가 구분됨.

비지니스(고객) - IT(설계/개발)간 Missmatch를

  1. 비지니스 분석
  2. 도출
  3. 요구사항 모델링

을 통해 고객 얘기를 바탕으로 가치가 있는지,
경쟁사 대비 동일 기술에 가치를 전달하는게 중요함.
대신 예전처럼 고객한테 직접 듣기보다, Data Mining, 분석, 크롤링을 통해 가치를 찾음.

User Requirement에 집중하면 되나, 이는 Business Requirment로 부터 도출됨.

User/Customer Requirement를 통해 기능/비기능 요구사항을 중요시 봐라. 계층구조로 있음.

Business 기반 요구사항 추출 원칙

  1. Business Requirement 정의
  2. 그걸로 Stakeholder 식별
  3. 거기서 User Requirement 추출(개수 제한없이 막 뽑음)
  4. Requirement Modeling
    (중복제거/Breakdown/인과관계/불명확/선후조건/암시적은 어떤게 있는지) check
  • Business Requirement :

조직의 비지니스 목적, 목표, Needs를 고수준으로 기술. (상세 기술x)
목표, 목적, needs를

Proect scpoe + Business Impact를 정해 합쳐 정하게 됨.

그래서 시작전에 두개에 대한 분석이 필요

회사의 성공요소들과 고객의 소리가 연결됨.
즉, 고객의 소리를 제하고 시작하는 것이 아님.
실 구현이 불가능하더라도 고객의 소리에 최대한 맞춰 주는 단계

  • SGS Cycle :

Business Goal을 확인하기 위해 Iteration을 가짐.

  • 이해관계자(고객/프로젝트 관련 사람들) 중심 요구사항 추출

이해관계자를 범위 잘 조정하고 관점/협의를 어떻게 이끌어낼까

Stakeholder Focus :
비지니스가 1개 이상의 이해관계자 그룹에 초점을 두고 운영
조직 구조에 의해 제일 첫 번째로 SW 구조가 결정됨.
팀에 따라 생성되는 SW 특성이 상이함.

목표나 문제점 특징이 같다면 하나의 Stakeholder 그룹으로 묶어
대표자를 선발함. 표본 추출의 문제

대표자들을 통해 각 그룹의 needs를 파악

조직 내 사람들은 회사 내부 Stakeholder(공동 목표의 1그룹)
일반적으로 Stakeholder는 회사 외부 인원들을 얘기함.

요구사항 분석가는, 내/외부 모두의 Stakeholder들의 요구사항을 수렴해 Project를 진행하도록 계획/ 혹은 설득

의뢰인은 고객이 아니고, 사용자가 고객이다. Stakeholder들을 펼쳐놓고 그룹화 해놓으면 양 쪽 모두 만족시킬 수 있음.

  • 이해관계자 우선순위
  1. Project의 Stakeholder들에게 가중치를 둬 우선순위를 갖게함
    (돈을 더 낸 사람 / 사용자 등)
  2. 자원은 한정되어 있기에 우선순위를 할당해줘야함.
    (충돌시 낮은 우선순위를 제거해야 함)
  3. 테스트를 다 할 수 없는 상황이니까

즉, 모든 Stakeholder들의 요구사항을 들어줄 수는 없음.
또한, Stakeholder들은 단계별로 참여하는 시기나 길이가 다를 수 도 있다.

  • 차량 네비게이션의 Stakeholder 도출해보기.

하지만, 그룹이라고 무조건 같은 목표를 갖고 있는 것은 아니고
사용자도 연령별/운전/동승 등등에 따라 굉장히 세분화 할 수 있음.

내부적인 Stakeholder보다, 외부의 Stakeholder를 잘 구분해놓는게 좋다.

Requirement를 Knapsack문제처럼, 최단 기간 최소 비용으로 최대의 이익을 뽑을 수 있도록 최적의 Set을 잡아야 한다.

1번보다 2,3,4가 더 이익이 높다면 2,3,4를 Set으로 잡음

  • Stackholder의 요구사항 도출 활동은 :
    반복을 요구, 타 Process들도 반복해 초기 Miss를 최소화하는 것을 중요시 여김.

도출 기법과 어떤 사람들이 참가하는지가 Process보다 더 중요하다.

  • Selection of Requirement Elicitation Technique
  1. 요구사항 크기
  2. 프로젝트 복잡도
    둘다 클수록 Stakeholder 증가
  3. 적용 도메인(if 전장/방산 -> Detail하고 오래 도출, 게임->간단)
  4. 포함 인원

사회적 제약 :
어떤 참여자 그룹이 포함?
그들의 배경은 무엇?

구조적 제약 :
어떤 시스템과 Interface되는가?

조직적 제약 :
개발에 부여된 시간/비용/개인적 요소는 무엇인가?

문제 기반 요소 :
개발될 영역의 성숙도/표준에 대한 사용가능성은 어느정도인가?

  • 이해관계자 요구사항 추출 기법의 선정
  1. 전통적인 방법 (보통 많이 사용)
  2. 시각화/모델링 방법
  3. 사용자 관점 추출 방법
  4. 창의적인 추출 방법

정답이 없어서, 여러개 섞어 쓰는 것을 권장하나
사실은 이들도 정확하지 않아 요새는
AI를 통해 크롤링/Mining/분석을 사용하게 됨
돈이나 시간은 더 줄어들고 정확도는 훨씬 높아짐.
또 생성형 AI들도 사용함.

기본적으로는 위 4개의 Factor를 사용하나,
참여자의 성숙도나 레벨에 따라 선정이 달라짐.

  1. Interview :
    상세 정보 추출 가능
    소수 인원이 많은 정보를 알고 있을때(표본이 많으면 못함)
    다수여도 대표자 표본 추출해 진행 가능은 함.
    모든 관점을 고려해 많은 정보 획득
    구조가 없어 분석이 어려움

중립 입장, 심문이 아닌 질문, 분석가 의도대로 이끄는 질문 피하고
상대의 의도를 표면화(기록x), 이유 탐색

  1. Brainstorming :

새롭고, 다양하고, 광범위한 대안들을 생성
향후 분석에 대한 테마를 도출
상황에 맞게 인원 조정(Group Section 진행)

2-1. 생성 단계
많은 아이디어를 내고 적고 연결, 최고 선정

2-2. 통합 단계
정리하여 의견 명확/구조/우선순위화

  1. Survey/Questionare :
    결과를 통계적 분석을 돌려 추이와 미래 예측을 하기 위해 진행
    최소 30개의 설문지를 확보해야 신뢰도를 만들 수 있음.

  2. Observation :
    어떤식으로 설거지하나 관찰. 마이닝/처리 전엔 가장 많이 쓰던 방법
    고객의 needs를 파악하기 가장 좋았던 방법임
    "그냥 평소 행실을 관찰 or 사용을 관찰"
    이후 문제점을 찾아냄.

  • 이해관계자 중심 요구사항 추출
  1. VORE(Viewpoint Oriented RE)
profile
CS
학습
이전 포스트

[SW 요구사항 분석 및 설계_1]

0개의 댓글