[1과목 - 1장] 소프트웨어 설계 - 요구사항 확인

1. 소프트웨어 생명 주기

🔎 1) 소프트웨어 생명 주기

• 소프트웨어 개발 방법론의 바탕이 되는 것

  	*소프트웨어 개발 방법론: 소프트웨어 개발과 유지보수 등에 필요한 여러 작업들의 수행 방법과     	
       작업들을 효율적으로 수행하기 위해 기법, 도구를 체계적으로 정리하여 표준화한 것

• 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

• 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임이라고도 함

• 문제 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용

• 소프트웨어 공학: 소프트웨어의 위기 극복을 위해 연구하는 학문으로 소프트웨어의 품질과 생산성 향상을 목적으로 함

  	*소프트웨어 공학의 형태	
    	 1. IEEE의 소프트웨어 공학 표준 용어사전: 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 
                                         체계적 접근 방안
       2. Fairley: 지정된 비용과 기간 내에 소프트웨어를 체계적으로 생산하고 유지보수하는 데 관련된 기술
       3. Boehm: 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것
       
      *소프트웨어 공학의 기본 원칙
       1. 현대적 프로그래밍 기술을 계속적으로 적용해야함
       2. 소프트웨어의 품질이 유지되도록 지속적인 검증 필요
       3. 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록 유지
       
       

1-1) 폭포수 모형 (Waterfall Model) - 고전적 생명 주기 모형

• 소프트웨어 개발에서 이전 단계로 돌아갈 수 없다는 전제하에 개발하는 방법론
• 각 단계를 확실히 매듭짓고 결과를 검토하여 승인 과정을 거친 후 단계를 진행
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로 경험과 성공 사례가 많다
• 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형으로 두 개 이상의 과정이 병행되지 않는다.
• 제품의 일부가 될 매뉴얼을 작성해야 한다.
• 폭포수 모형의 진행 과정
  
  

1-2) 프로토타입 모형 (Prototype Model) - 원형 모형

• 사용자의 요구사항을 정확히 파악하기 위해 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 폭포수 모형의 단점을 보완하기 위한 모형
• 프로토타입 모형의 진행 과정
  

1-3) 나선형 모형 (Spiral Model) - 점진적 모형

• 보헴(Boehm)이 제안한 것으로 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형으로 위험을 관리하고 최소화하는 것을 목적으로 함
• 나선을 따라 돌듯 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
• 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며 유지보수 과정이 필요없음
• 나선형 모형의 진행 과정
  
  
  

1-4) 애자일 모형 (Agile Model)

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 개발과정을 진행하는 모형

• 좋은 것을 빠르고 낭비없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론

• 스프린트(Sprint) / 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복

• 고객의 요구를 적극 수용하며 요구사항마다 우선순위를 부여하여 작업 진행

• 소규모 프로젝트, 숙달된 개발자, 급변하는 요구사항에 적합하며 기업 활동 전반에 사용

• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형:

   *스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), 
    *ASD(Adaptive Software Development), 기능 중심 개발(FDD; Feature Driven Development), 
    *DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery)

• 애자일 모형의 진행 과정
  

• 애자일 개발의 4가지 핵심 가치

     1. 프로세스, 도구보다 [개인과의 상호작용]에 가치를 둠
      2. 문서보다 [실행되는 소프트웨어]에 가치를 둠
      3. 계약 협상보다 [고객과의 협업]에 가치를 둠
      4. 계획을 따르기 보다 [변화에 반응하는 것]에 가치를 둠
      
      - 애자일 개발은 개발 막바지라도 요구사항 변경을 적극 수용한다.
      - 몇 주 단위로 실행되는 소프트웨어를 제공한다.
      - 개발의 진척도를 확인하는 1차 기준은 작동하는 소프트웨어다.
      - 단순화를 추구한다.
      
      

  📌 폭포수 모형과 애자일 모형의 비교
  
  
  
  
  

2. 스크럼 (Scrum) 기법

🔎 1) 스크럼 (Scrum)

• 스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 서로 대치해 있는 대형을 말하며 이처럼 팀이 중심이 되어 개발의 효율성을 높이는 것을 목적으로 함

• 팀원 스스로가 스크럼 팀을 구성(Self-organizing)해야하며, 개발에 관한 모든 것을 스스로 해결(Cross-functional)할 수 있어야 함

• 스크럼 팀의 구성:

• (1) 제품 책임자 (PO: Product Owner)

  • 이해관계자들 중 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정 (주로 개발 의뢰자나 사용자)
  • 제품에 대한 요구사항이 담긴 백로그를 작성하고 우선순위를 지정함
  • 팀원들이 백로그에 스토리를 추가할 수는 있지만 우선순위 지정은 X

    * 이해관계자: 소프트웨어 개발 의뢰자 / 소프트웨어 개발자 / 소프트웨어 사용자
     * 백로그: 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여한 목록
     * 스토리: 백로그에 고객의 요구사항을 서술하는 형태로 작성한 것
    

• (2) 스크럼 마스터 (SM: Scrum Master)

  • 객관적인 시각에서 조언을 해주는 가이드 역할
  • 일일 스크럼 회의를 주관하여 진행 사항을 점검하고 발생된 장애 요소를 공론화

• (3) 개발팀 (DT: Development Team)

  • 책임자와 마스터를 제외한 모든 팀원으로 참여하는 모든 사람이 대상이 됨
  • 최대 인원은 7~8명이 적당하다.

🔎 2) 스크럼 개발 프로세스

• (1) 제품 백로그 (Product Backlog)

  • 개발에 필요한 모든 요구사항(User story)을 우선순위에 따라 나열한 목록
  • 백로그에 작성된 스토리를 기반으로 전체 일정 계획인 릴리즈 계획(Release Plan)을 수립한다.

• (2) 스프린트 계획 회의 (Sprint Planning Meeting)

  • 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
  • 개발자들이 나눠서 작업할 수 있도록 태스크(Task)라는 작업 단위로 분할 후 개발자별로 수행할 작업 목록인 스프린트 백로그(Sprint Backlog)를 작성

• (3) 스프린트 (Sprint)

  • 실제 개발 작업을 진행하는 과정 (보통 2~4주)

  • 백로그에 작성된 태스크를 대상으로 속도(Velocity)를 추정한 후 개발 담당자에게 할당

     * 속도(Velocity): 한 번의 스프린트에서 한 팀이 감당할 수 있는 제품 백로그의 양에 대한 추정치

  • 개발자가 원하는 태스크를 직접 선별하여 담당할 수 있도록 하는 편이 좋다.

• (4) 일일 스크럼 회의 (Daily Scrum Meeting)

  • 매일 약속된 시간에 진행 상황을 점검

  • 진행되지 않은 남은 작업 시간은 소멸 차트 (Burn-down Chart)에 표시

  • 스크럼 마스터는 장애 요소를 해결하도록 도와줌

    	* 소멸 차트(Burn-down Chart): 수행할 작업의 진행 상황을 확인할 수 있도록 시간 경과에 따라  
    	                            남은 작업 시간을 그래프로 표현한 것
                               

• (5) 스프린트 검토 회의 (Sprint Review)

  • 완성 제품을 사용자가 포함된 참석자 앞에서 테스팅
  • 제품 책임자는 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그 업데이트

• (6) 스프린트 회고 (Sprint Retrospective)

  • 주기를 되돌아보며 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록
  • 스프린트가 끝난 시점 또는 일정 주기로 수행

3. XP (eXtreme Programming) 기법

🔎 1) XP (eXtreme Programming)

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객 참여와 개발 과정의 반복을 극대화하여 생산성을 향상시키는 방법
• 목적: 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여로 소프트웨어를 빠르게 개발하는 것
• 상식적인 원리와 경험을 최대한 끌어 올려 프로그래밍을 구동시킴
• 릴리즈 기간을 짧게 반복하며 요구사항 반영에 대한 가시성을 높임
• 소규모 인원의 개발 프로젝트에 적합

    *릴리즈(Release): 몇 개의 요구사항이 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것
     *가시성(Visibility): 대상을 확인할 수 있는 정도를 의미하며, 고객의 요구사항이 잘 반영되고 있음을 
                        직접적으로 알 수 있다는 의미
                        

• XP의 5가지 핵심 가치
  (1) 의사소통 (Communication)
  (2) 단순성 (Simplicity)
  (3) 용기 (Courage)
  (4) 존중 (Respect)
  (5) 피드백 (Feedback)
  

🔎 2) XP 개발 프로세스

• (1) 사용자 스토리 (User Story)
  • 고객의 요구사항을 간단한 시나리오로 표현한 것
  • 내용은 기능 단위로 구성하며, 간단한 테스트 사항(Test Case)도 기재 가능
    
    
• (2) 릴리즈 계획 수립 (Release Planning)
  • 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 릴리즈의 계획 수립
  • 개발 완료 시점에 대한 일정 수립
    
    
• (3) 스파이크 (Spike)
  • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
  • 처리할 문제 외의 다른 조건은 모두 무시하고 작성
    
    
• (4) 이터레이션 (Iteration)
  • 릴리즈를 더 세분화 한 단위로 일반적으로 1~3주 정도의 기간으로 진행됨
  • 새로운 스토리가 작성될 수 있으며 진행 중인 이터레이션 혹은 다음 이터레이션에 포함 가능
    
    
• (5) 승인 검사 (Acceptance Test, 인수 테스트)
  • 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
  • 테스트 사항에 대해 고객이 직접 수행하며 테스트 이후 새로운 요구사항의 추가나 요구사항의 우선순위가 변경될 수 있다.
    
    
• (6) 소규모 릴리즈 (Small Release)
  • 고객의 반응을 기능별로 확인할 수 있고, 요구사항에 좀 더 유연하게 대응 가능
  • 진행된 이터레이션이 모두 완료되면 고객에 의한 최종 테스트 후, 최종 결과물을 고객에게 전달
  • 릴리즈가 최종 완제품이 아닌 경우는 다음 릴리즈 일정에 맞춰 개발 진행
    
    

🔎 3) XP의 주요 실천 방법

• (1) Pair Programming (짝 프로그래밍): 다른 사람과 함께 프로그래밍을 수행하며 개발에 대한 책임을 공동으로 나눠 갖는 환경
  

• (2) Collective Ownership (공동 코드 소유): 개발 코드에 대한 권한과 책임을 공동으로 소유
  

• (3) Test-Driven Development (테스트 주도 개발): 개발자가 코드 작성 전 테스트 케이스를 먼저 작성하기 때문에 무엇을 해야할지 정확히 파악하고, 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크) 사용
  

• (4) Whole Team (전체 팀): 모든 구성원들은 각자 역할과 책임이 있다.
  

• (5) Continuous Intergration (계속적인 통합): 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합된다.
  

• (6) Design Improvement (디자인 개선) / Refactoring (리팩토링): 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작이나 기능의 변경 없이 단순화, 유연성 강화를 통해 내부 시스템을 재구성

• (7) Small Release (소규모 릴리즈): 릴리즈 기간을 짧게 반복하여 고객의 요구 변화에 신속히 대응

4. 현행 시스템 파악

🔎 1) 현행 시스템 파악 절차

• 새로 개발하려는 시스템의 개발 범위를 명확히 설정하고자 시행
  
• (1) 시스템 구성 파악
  • 조직의 주요 업무를 담당하는 기간 업무 + 이를 지원하는 지원 업무로 구분
  • 각 업무에 속하는 단위 업무 정보시스템들의 명칭과 주요 기능 명시 (어떤 기능을 제공하는 시스템인지)
    
    
• (2) 시스템 기능 파악
  • 단위 업무 시스템이 제공하는 기능들을 주요 기능 / 하부 기능 / 세부 기능으로 구분하여 계층형으로 표시
    
    
• (3) 시스템 인터페이스 파악
  • 시스템 간에 주고받는 데이터 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시
  • 데이터 형식: XML, 고정 포맷, 가변 포맷 등
  • 통신규약: TOP/IP, X25 등
  • 연계 유형: EAI, FEP 등
    
    
• (4) 아키텍처 구성 파악
  • 업무 수행에 어떤 기술 요소들이 사용되는지 최상위 수준부터 계층별로 표현한 아키텍처 구성도로 작성
  • 아키텍처가 시스템별로 다른 경우에는 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 표현

    *시스템 아키텍처: 시스템 내부에서 각각의 하위 시스템들이 어떤 관계로 상호 작용하는지 파악할 수 있도록 
                   구성이나 동작 원리를 표현한 것

    
    
• (5) 소프트웨어 구성 파악
  • 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시
  • 상용 소프트웨어의 경우 라이선스 적용 방식 기준과 보유한 라이선스 파악이 중요

    *상용 소프트웨어: 정식으로 대가를 지불하고 사용해아 하는 소프트웨어
    *라이선스 적용 방식: 사이트, 서버, 프로세서(CPU), 동시 사용, 코어(Core), 사용자 수 등
    *코어(Core): 각종 연산을 수행하는 CPU의 핵심 요소 (개수가 많을수록 처리속도가 빠름)

• (6) 하드웨어 구성 파악
  • 서버의 주요 사양과 수량, 이중화의 적용 여부 명시
  • 서버의 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부 결정
  • 현재 이중화가 적용된 경우 새 시스템에도 이중화가 필요하므로 비용 증가, 구축 난이도가 높아질 가능성 고려

    *서버의 주요 사양: CPU 처리 속도, 메모리 크기, 하드디스크 용량 파악
    *서버의 이중화(Replication): 운용 서버 장애 시 서비스를 계속 유지할 수 있도록 서버의 자료 변경이 
                              예비 서버에도 동일하게 복제되도록 관리하는 것

• (7) 네트워크 구성 파악
  • 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성
  • 서버들의 물리적 위치 관계를 파악 가능하고, 보안 취약성을 분석하여 적절한 대응 가능
  • 장애가 발생한 경우 발생 원인을 찾아 복구하기 위한 용도로 활용 가능
    
    
    
    

4. 개발 기술 환경 파악

🔎 1) 개발 기술 환경의 정의

• 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야할 사항을 기술하고 오픈 소스 사용 시 주의해야 할 내용 제시

   *미들웨어(Middle Ware): 운영체제와 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 
                          추가적 서비스를 제공하는 소프트웨어

  
  
• (1) 운영체제 (OS, Operating System)
  • 컴퓨터 시스템의 자원들을 효율적으로 관리하며 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
  • 사용자와 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종
    • 컴퓨터 운영체제: Windows, UNIX, Linux, Mac OS
    • 모바일 운영체제: iOS, Android

• (2) 운영체제 관련 요구사항 식별 시 고려사항
  

   *메모리 누수: 응용 프로그램이 사용하지 않는 메모리를 반환하지 않고 계속 점유하고 있는 현상
    *오픈 소스: 소스 코드를 공개해 누구나 무료로 사용이 가능한 소프트웨어
    *총 소유 비용: 어떤 자산을 획득하려고 할 때, 지정된 기간 동안 발생할 수 있는 모든 직간접 비용
    

🔎 2) 데이터베이스 관리 시스템 (DBMS)

• DBMS(DataBase Management System) 는 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성하고 데이터베이스를 관리해주는 소프트웨어
• 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템으로 모든 응용 프로그램이 데이터베이스를 공용할 수 있도록 관리
• 데이터베이스의 구성, 접근 방법, 유지관리에 대한 모든 책임을 진다.
• DBMS 종류: Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis...

    *응용 프로그램: 데이터베이스에 접근하여 운용되는 프로그램으로, 
                 데이터베이스는 여러 개의 응용 프로그램들이 공동으로 사용 

• (1) DBMS 관련 요구사항 식별 시 고려사항
  

   *JDBC(Java DataBase Connectivity): 자바에서 데이터베이스에 접근할 수 있도록 연결해주는 인터페이스
    *ODBC(Open DataBase Conectivity): 응용 프로그렘에서 데이터베이스에 접근할 수 있도록 
                                      연결해주는 인터페이스
                                      

🔎 3) 웹 애플리케이션 서버(WAS; Web Application Server)

• 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

• 주로 데이터베이스 서버와 연동해서 사용하며 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공한다.

• WAS의 종류: Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLosic, WebSphere 등

• (1) 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
  

  *가비지 컬렉션(Garbage Collection): 가용 공간 리스트에 반환되지 않는 메모리 공간인 가비지를 
    								  강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법

🔎 4) 오픈 소스 사용에 따른 고려사항

• 오픈소스를 사용하는 경우 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야함
  
  
  
  

6. 요구사항 정의

🔎 1) 요구사항의 개념 및 특징

• 요구사항은 소프트웨어가 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다.
• 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게하므로 이해관계자들 간 의사소통을 원활하게 도와줌

  	*이해관계자: 소프트웨어 개발 의뢰자, 개발자, 사용자 등

🔎 2) 요구사항의 유형

• (1) 기능 요구사항 (Functional requirements)

  • 시스템이 어떤 기능을 하는지
  • 시스템의 입출력으로 무엇이 포함되어야 하는지
  • 어떤 데이터를 저장하거나 어떤 연산을 수행해야 하는지
  • 시스템이 반드시 수행해야 하는 기능
  • 사용자가 제공받기를 원하는 기능
    
    

• (2) 비기능 요구사항 (Non-functional requirements)

  • 시스템 장비 구성 요구사항: 하드웨어, 소프트웨어, 네트워크 등 장비 구성
  • 성능 요구사항: 처리 속도 및 시간 등
  • 인터페이스 요구사항
  • 데이터 요구사항
  • 테스트 요구사항
  • 보안 요구사항
  • 제약사항
  • 프로젝트 관리 및 지원 요구사항
  • 품질 요구사항
    • 가용성: 언제라도 사용할 수 있는 정도
    • 정합성: 데이터의 값이 일관되게 일치하는 정도
    • 상호 호환성: 다른 소프트웨어와 정보를 교환할 수 있는 정도
    • 대응성: 발생한 상황에 대처하는 정도
    • 이식성: 다양한 하드웨어 환경에서도 쉽게 수정될 수 있는 정도
    • 확장성: 규모나 범위를 넓힐 수 있는 정도
      
      

• (3) 사용자 요구사항 (User requirements)

  • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
  • 친숙한 표현으로 이해하기 쉽게 작성
    
    

• (4) 시스템 요구사항 (System requirements) - 소프트웨어 요구사항

  • 개발자 관점에서 본 시스템이 제공해야 할 요구사항
  • 전문적이고 기술적인 용어로 표현
  
  

🔎 3) 요구사항 개발 프로세스

• 요구사항을 체계적으로 도출하고 분석한 후 분석 결과를 명세서에 정리한 다음 확인, 검증하는 일련의 구조화된 활동으로 요구공학의 한 요소이다.

   *요구공학: 요구사항의 변경 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 
   		   프로젝트 실패를 최소화하는 것을 목표로 하는 학문

• 요구사항 개발 프로세스 진행 전 비즈니스 목적에 부합하는지, 예산은 적정한 지 등에 대한 타당성 조사(Feasibility Study)가 선행되어야 함
  

• (1) 요구사항 도출 (Requirement Elicitation, 요구사항 수집)

  • 소프트웨어가 해결해야 할 문제를 이해하는 첫 단계로, 이 단계에서 개발자와 고객 사이의 관계가 형성되어 이해관계자(Stakeholder)가 식별된다.

  • 소프트웨어 개발 생명주기(SDLC; Software Development Life Cycle)동안 지속적으로 반복

  • 요구사항 도출 기법: 청쥐와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등

    	*브레인스토밍(Brain Storming): 3인 이상이 자유롭게 의견을 교환하며 
    							    독창적인 아이디어를 산출해내는 방법
        *프로토타이핑(Prototyping): 프로토타입을 통해 요구 분석을 수행하며 명세서를 산출하는 작업으로 
        						 가장 단순한 형태는 종이에 형태를 그려 보여주는 것이다.
        *유스케이스(Use case): 사용자의 요구사항을 기능 단위로 표현하는 것

• (2) 요구사항 분석 (Requirement Analysis)

  • 사용자의 요구사항 중 모호하여 이해되지 않는 부분을 발견하고 걸러내기 위한 과정
  • 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약 설정
  • 중복되거나 상충되는 요구사항이 있으면 중재하는 과정
  • 이를 토대로 소프트웨어의 범위를 파악
  • 요구사항 분석 도구: 자료 흐름도(DFD), 자료 사전(DD) 등
    
    

• (3) 요구사항 명세 (Requirement Specification)

  • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 과정

  • 기능 요구사항은 빠짐없이 완전하고 명확하게 기술하며, 비기능 요구사항은 필요한 것만 명확하게 기술해야함

  • 사용자가 이해하기 쉬우며 개발자가 효과적으로 설계할 수 있도록 작성

  • 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 한다.

  • 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있음

    
    

    📌 소프트웨어 요구사항 명세서 (SRS; Software Requirement Specification)
    - 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건 명시
    - 성능 보안, 사용성과 같은 품질도 기술해야함
    - 프로젝트 유형에 맞게 양식을 만들어 사용

    📌 요구사항 명세 기법
    

• (4) 요구사항 확인 (Requirement Validation, 요구사항 검증)

  • 개발 자원을 할당하기 전 명세서가 정확하고 완전하게 작성되었는지 검토하는 활동
  • 내용이 이해하기 쉬운지, 일관성 있는지, 회사 기준에 맞는지, 누락된 기능이 없는지 등을 검증
  • 요구사항 문서는 이해관계자들이 검토해야함
  • 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리를 수행

    	*형상 관리(SCM; Software Configuration Management): 
         소프트웨어의 개발 과정에서 만들어지는 형상들의 변경 사항을 관리하는 일련의 활동
    	*형상: 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 문서, 데이터 등

7. 요구사항 분석

🔎 1) 요구사항 분석의 개요

• 소프트웨어 개발의 실제적인 첫 단계로 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동

• 요구사항 분석 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 정확하고 일관성있게 분석하여 문서화해야함

• 소프트웨어 분석가에 의해 수행되며 이 단계를 요구사항 분석 단계라고 함

• 요구사항 분석 도구: UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등
  
  

• (1) 구조적 분석 기법

  • 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
  • 도형 중심의 분석용 도구와 분석 절차를 이용하여 요구사항을 문서화
  • 분석가와 사용자 간의 대화가 용이한 방법
  • 위에서 아래로 단계별로 분리하여 모델링하는 하향식 방법을 사용하여 시스템을 세분화하고 중복을 배제할 수 있다.
  • 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해할 수 있다.

• (2) 자료 흐름도(DFD; Data Flow Diagram)
  • 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
  • 자료 흐름 그래프, 버블 차트 라고도 함
  • 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다.
  • 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화한다.
  • 자료는 처리(Process)를 거쳐 변환될 때마다 새로운 이름이 부여되며 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출함
    
    • 프로세스(Process): 원이나 둥근 사각형으로 표시하고 안에 프로세스 이름 기입
    • 자료 흐름(Flow): 화살표 위에 자료의 이름 기입
    • 자료 저장소(Data Store): 도형 안에 자료 저장소 이름 기입
    • 단말(Terminator): 도형 안에 이름 기입

• (3) 자료 사전(DD; Data Dictionary)
  • 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것으로, 데이터의 데이터 또는 메타 데이터(Meta Data) 라고 함
    

8. 요구사항 분석 CASE와 HIPO

🔎 1) CASE(자동화 도구)

• 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구
  
  

• CASE의 이점

  • 표준화와 보고를 통한 문서화 품질 개선
  • 모두 데이터베이스를 이용 가능하다는 점에서 분석자들간의 적절한 조정
  • 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이성
  • 변경의 영향 추적의 용이성
  • 유지보수 비용 축소
    
    

• CASE의 종류

  • SADT(Structured Analysis and Design Technique): SoftTech사에서 개발한 것으로 블록 다이어그램을 채택한 구조적 분석 및 설계 자동화 도구

  • SREM(Software Requirements Engineering Methodology): TRW사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구 (RSL/REVS 사용)　

  • RSL(Requirement Statment Language): 요소, 속성, 관계, 구조를 기술하는 요구사항 기술 언어

    *요구: 요구사항 명세를 개발하기 위해 사용되는 개체와 개념
     *속성: 요소를 수정하거나 수식하기 위한 것
     *관계: 개체들 간의 관계
     *구조: 정보 흐름을 묘사하기 위한 것

  • REVS(Requirement Engineering and Validation System): RSL로 기술된 요구사항을 자동으로 분석하여 명세서를 출력하는 분석기

  • PSL/PSA: 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구

    • PSL(Problem Statement Language): 문제(요구사항) 기술 언어
    • PSA(Problem Statement Analyzer): PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기

  • TAGS(Technology for Automated Generation of Systems): 시스템 공학 방법 응용에 대한 자동 접근 방법으로, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

🔎 2) HIPO

• HIPO(Hierarchy Input Process Output): 분석 및 설계나 문서화할 때 사용되는 기법
• 입력, 처리, 출력으로 구성되며 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표의 사용으로 보기 쉽고 체계적인 문서 관리 가능
• 기능과 자료의 의존 관계를 동시에 표현 가능
• 변경, 유지보수가 용이
  
  
• HIPO Chart: 시스템의 기능을 여러 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것
  • 가시적 도표(도식 목차 - Visual Table of Contents): 시스템의 전체적 기능과 흐름을 보여주는 계층(Tree) 구조도
  • 총체적 도표(총괄도표, 개요 도표 - Overview Diagram): 프로그램 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
  • 세부적 도표(상세 도표 - Detail Diagram): 총체적 도표에 표시된 요소를 상세히 기술하는 도표

9. UML(Unified Modeling Language)

🔎 1) UML(Unified Modeling Language)의 개요

• UML: 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화(Unified)한 대표적인 객체지향 모델링 언어(Modeling Language)

  	*모델링 언어: 우리가 만들고자 하는 것을 시각적으로 표현할 수 있는 표기법, 도구 

• Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합

• 객체 기술에 관한 국제표준화기구 OMG(Object Management Group)에서 표준으로 지정

• 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있다.

🔎 2) UML의 구성요소

• (1) 사물(Things)

  • 모델을 구성하는 가장 중요한 기본 요소로 다이어그램 안에서 관계가 형성될 수 있는 대상
    
    

  • 구조 사물(Structural Things): 시스템의 개념적, 물리적 요소를 표현

    • 클래스(class), 유스케이스(use case), 컴포넌트(component), 노드(node) 등

      			*컴포넌트: 문서, 소스코드, 파일 등과 같은 모듈화된 자원으로 재사용 가능

  • 행동 사물(Behavioral Things): 시간과 공간에 따른 요소들의 행위

    • 상호작용(interaction), 상태 머신(state machine) 등

  • 그룹 사물(Grouping Things): 요소들을 그룹으로 묶어서 표현

    • 패키지(package)

  • 주해 사물(Annotation Things): 부가적인 설명이나 제약조건

    • 노트(note)

• (2) 관계(Relationships)
  • 사물과 사물 사이의 연관성을 표현하는 것

  ---

📌연관(Association): 2개 이상의 사물이 서로 관련되어 있음을 표현

• 실선으로 연결하여 표현하며 방향은 화살표로 표현
• 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결
• 연관에 참여하는 객체의 개수를 의미하는 다중도(Multiplicity)를 선 위에 표기

---

📌집합(Aggregation): 하나의 사물이 다른 사물에 포함되어 있는 관계

• 모든 사물은 서로 독립적이다
• 포함되는 쪽(부분,part)에서 포함하는 쪽(전체, whole)으로 속이 빈 마름모를 연결하여 표현
  

---

📌포함(Composition): 상위 사물의 변화가 하위 사물에게 영향을 미치는 특수한 집합 관계의 형태

• 사물들은 서로 독립될 수 없고 생명주기를 함께한다.
• 포함되는 쪽(부분,part)에서 포함하는 쪽(전체, whole)으로 속이 채워진 마름모를 연결하여 표현
  

---

📌일반화(Generalization): 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

• 보다 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)라고 함
• 하위 사물에서 상위 사물 쪽으로 속이 빈 화살표를 연결하여 표현
  

---

📌의존(Dependency): 사물에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

• 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
• 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우의 관계
• 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표로 연결
  

---

📌실체화(Realization): 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 그룹화 할 수 있는 관계

• 한 사물이 다른 사물에게 기능을 수행하도록 지정하는 의미적 관계
• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
  

---

• (3) 다이어그램(Diagram): 사물과 관계를 도형으로 표현한 것
  • 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 행위 다이어그램을 사용

---

📌구조적(Structural) 다이어그램

• 클래스 다이어그램(Class Diagram): 클래스가 가지는 속성, 클래스 사이의 관계를 표현
  • 시스템의 구조를 파악하고 구조상의 문제점 도출 가능
• 객체 다이어그램(Object Diagram): 클래스에 속한 객체(인스턴스)를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 럼바우(Rumbaugh) 객체지향 분석 기번에서 객체 모델링에 활용
• 컴포넌트 다이어그램(Component Diagram): 컴포넌트 간 관계나 인터페이스를 표현
  • 구현 단계에서 사용되는 다이어그램
• 배치 다이어그램(Deployment Diagram): 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현
  • 노드의 의사소통(통신) 경로로 표현 / 구현 단계에서 사용
• 복합체 구조 다이어그램(Composite Structure Diagram): 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
• 패키지 다이어그램(Package Diagram): 모델 요소들을 그룹화한 패키지들의 관계 표현

---

📌행위(Behavioral) 다이어그램

• 유스케이스 다이어그램(Use Case Diagram): 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용
  • 사용자(Ador)와 사용 사례(Use Case)로 구성되며 사용 사례 간에는 여러 형태의 관계로 이루어짐
• 순차(Sequence) 다이어그램: 상호 작용하는 시스템이나 객체들이 주고받는 메세지를 표현
• 커뮤니케이션(Communication) 다이어그램: 시스템, 객체들이 주고받는 메세지 표현(순차 다이어그램)과 객체들 간의 연관까지 함께 표현
• 상태(State) 다이어그램: 객체가 자신이 속한 클래스의 상태 변화나 다른 객체와의 상호 작용에 따라 상태가 변하는 모습을 표현
  • 럼바우 객체지향 분석 기법에서 동적 모델링에 활용
• 활동(Activity) 다이어그램: 시스템이 어떤 기능을 수행하는지 객체의 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
• 상호작용 개요(Interaction Overview) 다이어그램: 상호작용 다이어그램 간의 제어 흐름을 표현
• 타이밍(Timing) 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현

---

• 📝 스테레오 타입(Stereotype): UML에서 표현하는 기본 기능 외에 추가적 기능을 표현하기 위해 사용
  • 길러멧(Guilemet)이라고 부르는 겹화살괄호 ≪ ≫사이에 표현할 형태를 기술
    

10. 주요 UML 다이어그램

🔎 1) 유스케이스(Use Case) 다이어그램

• 유스케이스 다이어그램은 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점(View)에서 표현한 것

• 외부 요소와 시스템 간의 상호 작용 확인 가능

• 사용자의 요구사항을 분석하기 위한 도구

• 시스템의 범위 파악 가능
  
  

• 유스케이스 다이어그램의 구성 요소: 시스템 범위 / 액터 / 유스케이스 / 관계

  • 시스템(System) / 시스템 범위(System Scope): 시스템 내부 기능을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현

  • 액터(Actor): 시스템과 상호작용을 하는 모든 외부 요소 → 사람, 외부 시스템 등

       * 주액터: 시스템을 사용함으로써 이득을 얻는 대상 → 사람 (사용자 액터) 
        * 부액터: 시스템에 서비스를 제공하는 외부 시스템 → 조직이나 기관 (시스템 액터)

  • 유스케이스(Use Case): 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스, 기능을 표현한 것

  • 관계(Relationship): 액터-유스케이스, 유스케이스-유스케이스 사이의 관계로 연관 관계, 포함 관계, 확장 관계, 일반화 관계를 표현 가능

    	*포함(include) 관계: 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우 → 원래의 유스케이스에서 새로운 유스케이스 쪽으로 점선 화살표 연결 후 화살표 위에 ≪include≫라고 표기
    	*확장(extend) 관계: 유스케이스가 특정 조건에 부합하여 기능이 확장 될 때의 관계 → 확장될 유스케이스에서 원래 유스케이스 쪽으로 점선 화살표를 연결 후 화살표 위에 ≪extends≫라고 표기

• 📝 연동: 2개 이상의 시스템이 상호 간의 동작에 영향을 줄 수 있도록 연결망을 구성하는 것
  
  

🔎 2) 클래스(Class) 다이어그램

• 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 이에 대한 제약조건, 클래스 사이의 관계를 표현한 것

• 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램

• 시스템 구성요소를 문서화하며 시스템을 모델링하는 데 자주 사용

• 클래스 다이어그램의 구성 요소: 클래스 / 제약조건 / 관계

  • 클래스(Class): 각 개체들이 갖는 속성과 오퍼레이션(기능, 동작)을 표현

    • 3개의 구획(Compartment)으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기

      *속성(Attribute): 클래스의 상태나 정보
       *오퍼레이션(Operation): 클래스가 수행하는 동작 (함수-메소드)

  • 제약조건: 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 적는다.

  • 관계(Relationships): 클래스와 클래스 사이의 연관성

    • 연관 관계 / 집합 관계 / 포함 관계 / 일반화 관계 / 의존 관계

• 📝 접근제어자: 속성과 오퍼레이션에 동일하게 적용
  

🔎 3) 순차(Sequence) 다이어그램: 시스템이나 객체들이 시간의 흐름에 따라 상호작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것 - (동적 다이어그램)

• 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있다.

• 클래스 내부에 있는 객체들을 기본 단위로 하며 그들의 상호작용을 표현

• 주로 기능 모델링에서 작성한 유스케이스 명세서를 하나의 표현 범위로 하지만, 하나의 클래스에 포함된 오퍼레이션을 하나의 범위로 표현하기도 함

• 순차 다이어그램의 구성 요소: 액터 / 객체 / 생명선 / 실행 / 메시지

  • 액터(Actor): 시스템으로부터 서비스를 요청하는 외부 요소 → 사람, 외부 시스템
  • 객체(Object): 메시지를 주고받는 주체
  • 생명선(Lifeline): 객체가 메모리에 존재하는 기간, 객체 아래쪽에 점선으로 표현
  • 실행 상자(Active Box): 객체가 메시지를 주고받으며 구동되고 있음을 표현
  • 메시지(Message): 객체가 상호 작용을 위해 주고받는 것

---

🖍 예상문제 오답정리 <62p - 64p>

Q8. 소프트웨어 생명 주기 모형 중 Prototype 모형의 가장 큰 장점은?
A8. 요구사항의 정확한 파악 → 견본품으로 미리 테스트하기 때문에

Q9. xP의 5가치 가치?
A9. 용기 / 의사소통 / 피드백 / 존중 / 단순성

Q13. 데이터 흐름도(DFD)의 구성 요소는?
A13. Process(프로세스) / Data Flow(자료 흐름) / Data Store(자료 저장소) / Terminator(단말)

Q14. UML 모델에서 사용하는 structural diagram의 종류는?
A14. class diagram / object diagram / component diagram / deployment diagram / composite structure diagram / package diagram

Q15. 스크럼에 대한 설명으로 잘못된 것은?
A15. 스프린트 검토 회의에서 개선할 사항에 대한 피드백이 정리되면 스크럼 마스터는 이를 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트한다? → 스크럼 마스터가 아닌 *제품 책임자*의 역할

Q17. 오픈 소스 사용에 따른 고려사항은?
A17. 라이선스의 종류 / 사용자 수 / 기술의 지속 가능성

Q19. 요구사항 분석 시에 필요한 기술은?
A19. 청취와 인터뷰 질문 기술 / 분석과 중재기술 / 관찰 및 모델 작성 기술

Q21. CASE의 주요 기능은?
A21. · s/w 라이프 사이클 전 단계의 연결
 	 · 모델들 사이의 오류 검사
     · 모델의 오류 검증
     · 자료 흐름도 등의 다이어그램 작성
     · 다양한 소프트웨어 개발 모형 지원
     · 시스템 문서화 및 명세화를 위한 그래픽 지원

Q22. 기본 유스케이스 수행 시 특별한 조건을 만족할 때 수행하는 유스케이스는?
A22. 확장 - 유스케이스가 특정 조건에 부합하여 기능이 확장 될 때의 관계 ≪extends≫

Q26. 나선형(Spiral) 모형의 주요 태스크는?
A26. 계획 수립 → 위험 분석 → 개발 → 평가

Q27. 애자일 개발 방법론과 관련한 설명으로 틀린 것은?
A27. 정확한 결과 도출을 위해 계획 수립과 문서화에 중점을 둔다? → *실행되는 소프트웨어*에 중점을 둔다!

Q30. 요구사항의 정의 및 분석, 설계의 결과물을 표현하기 위한 모델링 과정에서 사용되는 다이어그램이 아닌 것은? 
A30. AVL diagram (이진 탐색 트리에서 활용되는 다이어그램)
     *(Data Flow diagram / UML diagram / E-R diagram 사용)*