Madison Digital Garden

Search

SearchSearch

03. 요구사항 분석

Jan 05, 2025, 23 min read

충남대학교 컴퓨터공학과 김현수 교수님의 "소프트웨어 공학" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

요구사항 분석 과정

  • ”어떻게 구현할지”가 아닌 “무엇을 구현할지”에 관심을 가져야 한다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image1.png

  • 그래서 뭐 뻔한얘기지만
  • 일단 문제가 무엇인지를 파악하기 위해 문제가 발생하게된 배경과 그 문제의 성격, 문제가 미치는 범위에 대해 파악한다
  • 그리고 사용자가 소프트웨어에 대해 어떤 것을 필요로 하는지 취합 하고
  • 취합한 요구사항을 분석하고 문서로 작성한 후
  • 사용자가 요구한 사항과 일치하는지 검토하고 일치하지 않는다면 다시 취합하는 과정부터 반복한다
  • 조금 더 자세히 알아보면

도메인 분석

  • 일단 도메인은 다음의 예로 이해하는 것이 최고다
  • ATM을 개발한다고 할 때의 도메인은 은행 업무 이고 도메인 전문가는 은행원 이 된다
  • 즉, 도메인이라는 것은 해당 소프트웨어를 사용할 고객이 일하는 분야(비즈니스, 기술)를 일컫는 것이고
  • 도메인 전문가는 그 도메인의 업무를 잘 알고 이해하고있는 사람을 일컫는 것이다
  • 도메인 분석을 통해 얻을 수 있는 이점은 다음과 같다
    1. 일단 이해당사자(고객 / 사용자, 개발자, 관리자)들 간 더욱 효과적으로 소통할 수 있고
    2. 따라서 빠르게 요구사항을 취합할 수 있어 개발기간이 단축될 수 있다
    3. 또한 문제를 더 심도있게 이해할 수 있기 때문에 더 좋은 결과물을 낼 수 있고
    4. 따라서 트렌드를 예측할 수 있어 미래를 예측해 볼 수 있기 때문에 확장성이 높은 결과물을 낼 수 있게 된다

도메인 분석서의 구조

  1. 개요 - 이 글이 무엇에 대한 것인지, 이 글을 읽을 대상은 누구인지 등등
  2. 용어 - 이 글에서 등장하는 용어들에 대한 설명
  3. 개괄적 지식 - 도메인 전문가가 알고 있는 해당 도메인에 대한 지식(뭐 이 비즈니스가 어떻게 돌아간다던지, 어떤 기술을 이용한다던지, 기술이 어떻게 동작한다던지 등등)
  4. 고객과 사용자 - 이 소프트웨어를 누가 의뢰했는지(고객), 그리고 이 소프트웨어를 누가 사용할 것인지(사용자)
  5. 환경 - 소프트웨어가 구동될 환경
  6. 작업과 수행절차 - 해당 프로젝트에 동원되는 인력들에 대해 그들이 담당하는 작업과 절차, 그리고 (특히 도메인 전문가에 대해) 그들만이 알고있는 노하우(쉬운 방법)
  7. 경쟁 소프트웨어 - 이미 시장에서 판매되어 사용되고 있는지의 여부와 장단점
  8. 다른 도메인과의 유사성 - 우리가 다루고 있는 도메인과 유사한 도메인이 있다면 그것과의 공통점과 차이점
    • 예를들어 도서 대출시스템과 영화 대출 시스템 등

문제 정의

  • 문제라는 것은 고객이나 상요자가 직면한 어려움이고
  • 이 문제를 해결하는 것은 일반덕으로 소프트웨어의 개발을 필요로 하고
  • 문제의 해경른 생산성이나 매출을 높일 수 있는 기회가 되기도 한다

범위 설정

  • 범위를 설정한다는 것은 우리가 개발하고자 하는 소프트웨어가 해결할 수 있는 모든 문제들을 생각해 보는 것이다
  • 만약 범위가 너무 크다면, 일부는 배제해야 할 것이고
  • 범위가 너무 좁다면 해당 소프트웨어가 우리의 궁극적으로 해결하고자 하는 문제 파악하고 이를 해결 할 수 있는지 검토해 봐야 한다

요구사항 추출

  • 요구사항 : 짧고 간결하게 표현된, 관련자들이 동의한, 문제를 해결하기 위한, 소프트웨어가 제공해야 할 기능

요구사항에 따른 프로젝트의 분류

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image2.png

  • 요구사항이 결정되지 않은 A와 C의 경우에는 보통 상업용 SW인 경우가 많고
  • 고객에 의해 요구사항이 결정된 B와 D의 경우에는 의뢰 SW인 경우가 많다

요구사항의 분석

  • 기능적 요구사항은 결과물이 제공해야 할 기능을을 말하는 것이다
    • 입력 기능 : 사용자 혹은 다른 시스템으로부터 어떤 정보를 입력할 수 있는 지
    • 출력 기능 : 사용자 혹은 다른 시스템에게 어떤 정보를 출력할 수 있는 지
    • 저장 기능 : 시스템이 어떤 정보를 저장할 수 있는 지
    • 컴퓨팅 기능 : 시스템이 어떤 연산을 할 수 있는 지
    • 타이밍과 동기화 : 특히 하드웨어 장치제어나 리얼타임 프로젝트의 경우, 즉각적인 반응이 가능한지
  • 비기능적 요구사항은 기능이 아닌 성능이나 효율, 반응시간, 품질등을 말하는 것이다
    • 얘네는 객관적인 지표(수치)로 검증이 가능해야 하며, 구현 이후 검증절차가 반드시 이루어져야 함
    • 소프트웨어의 품질 특성 측면
      • 반응시간 : 요청에 대한 결과가 얼마나 빠르게 나오는 지
      • 처리량 : 분당 처리 트랜잭션의 수가 몇개인지
      • 자원 사용량 : 사용하는 메모리, 전기 등의 자원은 얼마정도인지
      • 신뢰성 : 시스템이 고장나지 않고 제대로 동작할 가능성은 얼마나 되는지
      • 가용성 : 시스템이 실행되고 준비되어있는 시간은 얼마나 되는지 - Down-Time(DT) 은 기준 시간(예를들어 1년) 중에 얼마나 되는지
      • 고장에서의 회복 : 고장으로 인해 발생할 수 있는 피해의 최대치는 어느정도인지
      • 유지보수, 확장, 재사용성의 허용 : 유지보수나 시스템의 확장, 그것을 재사용하는 것이 어느 정도까지 가능한지
    • 환경과 기술적 측면
      • 플랫폼 : 소프트웨어가 돌아가는 환경 - 뭐 예를 들면 최소 램 4Gb짜리 윈도우 컴퓨터에서 돌아갈 수 있도록 해라
      • 사용 기술 : 소프트웨어를 만드는데 사용할 프로그래밍 언어나 프레임워크, 라이브러리 등의 기술 - 뭐 예를 들어 전자정부 프레임워크를 이용해 자바로 개발해라
    • 계획과 방법론적인 측면
      • 방법론 : 사용할 개발 프로세스(방법론) - 뭐 애자일을 이용해라 등
      • 비용과 납기일 : 얼마를 이용해서 개발해라, 언제까지 개발해라 - 보통 계약서에 많이 명시됨
  • 예시 보고 기능적 / 비기능적 요소 구별하는 문제는 안나온댄다

요구사항 추출 방법

  1. 관찰 : 사용자의 업무를 관찰하는 것 - 숨겨진 문제를 파악하기에 좋음
  2. 인터뷰 : 관련 당사자를 만나 인터뷰함 - 요구사항의 오해를 줄일 수 있음
  3. 브레인스토밍 : 아이디어를 정제하지 않고 쏟아내는 것 - 요구사항의 고려 범위가 넓어질 수 있음
  4. 프로토타이핑 : 시범적인 시스템 구현 - 요구사항에 대한 빠르고 현실적인 피드백을 받을 수 있음
  5. 유스케이스 분석 : 시스템 외부 기능 파악 - 체계적 요구사항 분석 - 뭔지 모르겠음

관찰

  • 사용자의 업무를 관찰하고 기록
  • 숨겨진 문제를 파악하기에 좋고 자세한 설명도 들을 수 있음
  • 예를 들어 비디오 촬영을 하며 기록할 수 있다
  • 하지만 시간이 많이 소요된다는 단점이 있다

인터뷰

  • 관련자 뿐만 아니라 경쟁 제품 이용자나 마케팅 담당자와 같은 관련 없는 사람들에게도 인터뷰를 진행함
  • 그리고 인터뷰 대상자들의 여유시간에 진행 - 시간에 쫒기면 안된다네
  • 대상자 선정 → 일정 계획 → 질문 작성 → 인터뷰 → 분석 및 정리의 과정으로 이루어진다
  • 또한 양질의 질문을 마련해놓는 등 미리 철저히 계획하여야 효율적으로 많은 정보를 얻어낼 수 있음

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image3.png

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image4.png

  • 위의 경우는 좀 알아둘 필요가 있음 - 일단 최소한으로 시스템이 갖춰야 할 것이 뭔지 먼저 파악하고, 그리고 다른 부가 기능들에 대해 질문을 하는 것이 좋다 - 이런 우선순위에 대한 고민 없이 그냥 물어보면 너무나도 많은 아이디어가 나올 가능성이 있어 쓸데없는 기능이 시스템에 포함될 가능성이 있다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image5.png

  • 이것도 걍 보고 읽어도 될듯

브레인스토밍

  • 뭔지는 알제? 걍 생각나는 아이디어 다 쏟아내는거
  • 하지만 회의가 약간 산으로 갈 수도 있기 때문에 훈련된 요원이 진행을 맡는 것이 좋댄다
  • Joint Application Development(JAD) : 브레인 스토밍의 한 방법으로 시스템 개발에 대해 논의할 때 개발자들끼리 하는 것이 아닌 최종 사용자를 포함시켜 같이 브레인스토밍을 해 요구사항을 정의해 나가는 것
    • 보통 카페같은 별도의 장소를 마련해 모여서 집중적으로 브레인스토밍을 하는 방식으로 진행된다
  • 브레인스토밍의 과정은 다음과 같다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image6.png

  • 저기 보면 5번 문항이 뭔 소린가 할 수 있는데 종이 한장을 마련하고 질문을 던진 후 한사람부터 시작해 그 질문과 관련된 아이디어를 하나 적고 다음사람으로 넘겨줌. 그럼 다음사람은 그걸 받고 전사람이 적은 것을 참고하거나 아니면 새로운 아이디어를 하나 적고 다음사람에게 넘겨주는 방식으로 진행됨
  • 그니까 5번 문항의 종이 한장에 하나의 아이디어를 적으라는 것은 내차례가 오면 한가지의 아이디어만 적으라는 소리다
  • 저기 토론을 유도할 질문이라는 게 있는데 그건 아래 사진 참고해라

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image7.png

  • 토론을 유도할 질문이기 때문에 예 아니오로 답변할 수 있는 단순한 질문이 아닌 아이디어가 나올 수 있는 질문을 마련해야 된다

프로토타이핑

  • 프로토타입은 뭐 알겠지만 시스템의 예상 가능한 기능 몇가지를 빠르고 단순하게 만들어 본 것이다
  • Paper prototype : UI를 종이에 그리고 화살표 등으로 사용 시나리오를 보여주는 형태
    • 이러한 프로토타입을 보고 있으면 또 새로운 아이디어가 떠오르기도 하고, 다양한 피드백들을 받을 수 있기 때문에 단순하지만 효율적이다
    • 또한 작성방법이 쉽기 때문에 각자의 관점에 따른 여러가지의 프로토타입을 병행하여 작성해 비교하는 방식으로 진행하는 것도 가능하다
  • Mock-up the UI : 프로토타이핑 전용 언어로 프로그램을 작성해 작동 과정을 좀 더 동적으로 보여주는 것
    • 하지만 작동 과정만 시나리오에 따라 보여주기 때문에 컴퓨팅이나 DB, 다른 시스템과의 상호작용 등은 불가능하다
  • 또한 시스템의 알고리즘이나 데이터베이스같은 특별한 측면에 대해서 실현가능성 등을 보기 위해 프로토타입을 만들어보기도 한다

요구사항 문서화

  • 요구사항을 문서화 할때는
  • 요구사항의 outline만 대강 잡는 식으로 간단하게 문서화하기도 하고
  • 수천 페이지의 복잡하고 자세한 명세를 하는것도 가능하다
  • 또한 대규모 시스템의 경우에는 시스템을 서브시스템으로 나누어서 계층적으로 정리하기도 한다

상세 수준 정하기

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image8.png

  • 위에서 개발을 위한 계약부분은 외주 계약의 경우에는 우리가 원하는 것을 자세하게 적어줄 필요가 있고, 정부기관 계약의 경우에는 정해진 양식이 있어 그거에 따라 적어야 될 경우도 있다는 것을 말하고 있는 것이다.

문서의 구성

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image9.png

  • 일단 명세서의 구성을 자세히 살펴보면 위와 같다
  • Introduction 부분에는 문서의 목적, 범주, 용어 등을 적어주면 된다
  • 그리고 External Interface Requirements부분을 좀 보면
    • User Interface는 니가 아는 그 UI를 말하는 거고
    • Hardware Interface는 잘 이해 안되는데 SW가 탑재되어 작동하게 될 HW에 대한 인터페이스를 말한댄다
    • Software Interface는 해당 시스템과 다른 시스템이 어떻게 상호작용 하는지를 말하는 거고
    • Communication Interface는 걍 통신 인터페이스다
  • 그리고 System Feature에는 기능적 요구사항이 주로 들어간다고 보면 되고
  • Other Nonfunctional Requirements에는 비기능적 요구사항
  • Other Requirements는 위의 항목에 넣기 애매한 그 외의 제약조건들이 들어간다

Introduction

  • 다음의 네가지가 들어간다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image10.png

  • Stakeholder 는 프로젝트와 금전적 등의 이익관계가 있는 사람들을 말한다
    • 뭐 고객, 사용자, 개발자, 관리자 등

External Interface Requirements

  • 위에서 말한거처럼 소프트웨어와 사용자, 하드웨어, 다른 시스템 등등과의 소통에 있어 필요한 인터페이스를 설명하는 부분 이다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image11.png

  • UI 는 걍 한번 읽어봐라

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image12.png

  • Hardware Interface 는 위에서 말한거처럼 시스템이 작동하게 될 하드웨어에 대해 기술하는 부분이라고 생각하면 될거같다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image13.png

  • 솔직히 필기하는것보다는 설명 한번 읽어보고 사례를 통해 감을 잡는게 나을거같다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image14.png

  • 위에서 간력한 설명만 보면 Software Interface와 Communication Interface와 무슨 차이점이 있는건지 헷갈릴 수 있는데
  • 사례와 자세한 설명을 보면 Software Interface는 어떤 외부 시스템과 어떠한 flow를 통해 어떤 것을 소통할 것인지가 중점인 반면, Communication Interface는 시스템에서 사용할 HTTP와 같은 표준 프로토콜이나 API 형식 등에 대해 논하고 있는 것을 알 수 있다.

System Feature

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image15.png

  • 그리고 아래의 사례에서도 계속 확인할 수 있는 내용인데 각 요구사항은 일련 번호나 태그 등의 식별자로 유일하게 식별되야 한다더라

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image16.png

  • 사례도 한번 읽어봐라

Other Nonfunctional Requirements

  • 비기능적 요구사항인데
  • 비기능적 요구사항들 중에 해당 비기능에 대해 요구사항이 없으면 생략할 수도 있다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image17.png

  • 우선 성능 제약 조건인데 읽으면 된다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image18.png

  • 신뢰성 제약 조건에 대한 내용이다.

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image19.png

  • 보안 제약 조건에 대한 내용이다.

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image20.png

  • 위처럼 다영한 측면의 품질에 대해서 제약조건(요구사항)을 마련할 수 있다.

Other Requirements

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image21.png

  • 하드웨어 제약조건의 예시로 하드와 램의 크기에대해 요구사항을 명시하거나 통신 대역폭에 관한 내용을 명시할 수도 있다

요구사항 검토

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image22.png

  • 저기서 80대 20 법칙은 20의 투자로 80의 문제를 해결 할 수 있느냐이다
    • 즉, 80대 20 법칙을 만족하는 것은 우선순위가 높은 것이고 그렇지 않으면 우선순위가 낮아지게 되는 것으로 생각할 수 있다
  • 그리고 마지막 설계 제한은 요구사항 명세를 할 때에는 요구사항의 구현보다는 어떤 요구사항이 있을지에 더 포커스를 맞추고 있기 때문에 구현의 관점때문에 요구사항을 너무 적게 잡은 것은 아닌지 등을 검토해 볼 필요가 있는 것

요구사항 변경 관리

  • 비즈니스가 변한다던가, 기술이 변경된다던가, 문제를 더 심도있게 이해했다거나의 이슈를 통해 요구사항은 계속해서 바뀔 수 있다

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB04%20-%20%E1%84%8B%E1%85%AD%E1%84%80%E1%85%AE%E1%84%89%E1%85%A1%E1%84%92%E1%85%A1%E1%86%BC%20%E1%84%87%E1%85%AE%E1%86%AB%E1%84%89%E1%85%A5%E1%86%A8%2012f12474277a4d9d8a660c4b5b610685/image23.png

  • 고려해야될 점은 위와 같다
  • 저 중에서 마지막 위장된 확장은 요구사항의 명세는 보다 나은 시스템의 구축에 집중해야 하기 때문에 시스템의 규모를 확장하는 것은 되도록이면 피하는게 좋다는 것이다.
    • 즉, 기능을 늘리기보다는 지금 있는 기능을 더 좋게 하는 것이 목적이 되어야 한다는 것이다

Graph View

Backlinks