[정보처리기사 실기] 요구사항 정의 요약

요구사항의 정의

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 해단 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다.

• 요구사항 유형
  • 기능 요구사항(Functional requirement)
    • 시스템이 무엇을 하는지, 어떤 기능을 하는지 등 사용자가 시스템을 통해 제공받기를 원하는 기능이나 시스템이 반드시 수행해야 하는 기능
  • 비기능 요구사항(Non-Functional requirement)
    • 품질이나 제약사항과 관련된 요구사항으로, 시스템의 장비 구성, 성능, 인터페이스, 테스트, 보안 등의 요구사항을 말한다.
  • 사용자 요구사항
    • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
  • 시스템 요구사항
    • 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

1. 소프트웨어 개발 방법론
   1. 소프트웨어 생명주기(SDLC)
   2. 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
   3. 소프트웨어 생명 주기 모델 종류 [폭프나반]
      • 폭포수 모델 : 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어간다.
      • 프로토타이핑 모델 : 프로토타입을 구현해, 고객의 피드백을 반영하여 만들어간다.
      • 나선형 모델 : 위험을 최소화하기 위해 점진적으로 개발한다.
        나선형 모델 절차 [계위개고] : 계획 및 정의 / 위험분석 / 개발 / 고객 평가
      • 반복적 모델 : 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발한다.
   4. 소프트웨어 개발방법론 종류
      • 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고 이를 통합한다. 나씨 슈나이더만 차트 사용
      • 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화
      • 객체지향 방법론 : 객체라는 기본 단위로 시스템 분석 및 설계
      • 컴포넌트 기반 방법론(CBD) : 컴포넌트를 조립해 하나의 새로운 운용 프로그램 작성
      • 애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발
      • 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발, 임베디드
   5. 애자일 방법론의 유형
      • XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
      • SCRUM : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 방법론
      • LEAN : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해 낭비 요소를 제거하는 방법론
   6. XP의 5가지 가치
      • 용기, 단순성, 의사소통, 존중, 피드백
   7. XP의 12가지 기본 원리
      • 짝 프로그래밍 : 개발자 둘이서 짝으로 코딩하는 원리
      • 지속적인 통합(CI) : 매일 여러 번씩 소프트웨어를 통합하고 빌드
      • 메타포어 : 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다.
      • 테스트 기반 개발(TDD) : 만들 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다.
      • 리팩토링(Refactoring) : 프로그램의 기능은 바꾸지 않고 중복제거, 단순화 등을 위해 시스템 재구성을 한다.
   8. 델파이 기법
      1. 전문간의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 기법
   9. 비용 산정 모형 종류
      • LoC 모형 : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정해 예측치를 구해 비용을 산정
      • Man Month 모형 : 한 사람이 1개월동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식
      • COCOMO 모형 : 보햄이 제안, 프로그램 규모에 따른 비용 산정
        • 조직형
        • 반 분리형
        • 임베디드형
      • 푸트남 모형 : 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, 생명주기 예측 모형
      • 기능점수 모형 : 요구 기능에 따른 가중치 부여
   10. 일정관리 모델
       • 주 공정법 : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정 계산
       • PERT : 일의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치를 이용
       • 주 공정 연쇄법 : 자원 제약사항을 고려해 일정 작성
2. 현행 시스템 분석
   1. 현행 시스템 파악
      1. 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악
   2. 소프트웨어 아키텍처
      1. 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요서 간의 관계를 표현하는 시스템의 구조나 구조체
   3. 소프트웨어 아키텍처 4+1 뷰 [유논프구배]
      고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
      
      • 유스케이스 뷰 : 다른 뷰를 검증하는데 사용
      • 논리 뷰 : 시스템의 기능적 요구사항 설명
      • 프로세스 뷰 : 시스템의 비기능적 요구사항 설명
      • 구현 뷰 : 모듈의 구성, 컴포넌트 구조, 의존성
      • 배포 뷰 : 어떻게 배치되는가.
   4. 유스케이스
      1. 시스템 요구사항이자, 사용자의 입장에서 바라본 시스템의 기능
   5. 소프트웨어 아키텍처 패턴
      1. 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
   6. 소프트웨어 아키텍처 패턴 유형
      • 계층화 패턴 : 시스템을 계층으로 구분해 구성하는 패턴
      • 클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴
      • 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용
      • 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들 원격 서비스 실행을 통해 상호작용 가능
      • 모델-뷰-컨트롤러 패턴(MVC)
        • 모델 : 핵심 기능과 데이터 보관
        • 뷰 : 사용자에게 정보 표시
        • 컨트롤러 : 사용자들로부터 요청 입력 받아 처리
   7. 소프트웨어 아키텍처 비용 평가 모델 종류 [SACAA]
      • SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능
      • ATAM : 아키텍처 품질 속성을 만족시키는지 판단
      • CBAM : ATAM 바탕의 시스템, 경제적 의사결정에 대한 요구 충족
      • ADR : 소프트웨어 아키텍처 구성요소 간 응집도 평가
      • ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중
   8. 디자인 패턴
      1. 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
   9. 디자인 패턴 구성요소 [패문솔 사결샘]
      1. 패턴 이름
      2. 문제
      3. 솔루션
      4. 사례
      5. 결과
      6. 샘플코드
   10. 디자인 패턴 유형[생구행]
       • 목적
         • 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식 구조화, 캡슐화 수행
         • 구조 : 클래스나 객체의 조합을 다루는 패턴
         • 행위 : 클래스나 객체들이 상호작용 하는 방법과 역할 분담을 다루는 패턴
       • 범위 : 클래스, 객체
   11. 디자인 패턴 종류
       • [생빌 프로 팩앱싱]
         생성 패턴 : 빌더 / 프로토타입 / 팩토리 메서드 / 앱스트랙 팩토리 / 싱글톤
       • [구 브데 퍼플 프록 컴 어]
         구조 패턴 : 브리지 / 데코레이터 / 퍼사이드 / 플라이 웨이트 / 프록시 / 컴포지트 / 어댑터
       • [행 미인이 템옵 스테 비커 스트 메체]
         행위 패턴 : 미디에이터 / 인터프리터 / 이터레이터 / 템플릿 메서드/ 옵져버 / 스테이트/ 비지터 / 커맨드 / 스트레티지 / 메멘토 / 체인 오브 리스판서빌리티
   12. 운영체제
       1. 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스 담당
   13. 운영체제 종류
       1. 윈도우, 유닉스, 리눅스, 안드로이드, ios
   14. 미들웨어
       1. 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
3. 요구사항 확인
   1. 요구공학
      1. 사용자의 요구가 반영된 시스템을 개발하기 위해서 사용자의 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
   2. 기능적 요구사항
      1. 시스템이 제공하는 기능, 서비스에 대한 요구사항(기능성, 완전성, 일관성)
   3. 비기능적 요구사항
      1. 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항, 품질, 시스템 환경, 프로젝트 계획에 관한 요구사항
   4. 요구사항 도출 단계 주요 기법
      • 인터뷰, 워크숍, 브레인스토밍, 설문조사
      • 델파이 기법
      • 롤플레잉
   5. 정형 기술 검토 동워인]
      • 동료 검토
      • 워크 스루
      • 인스펙션
4. UML 구성요소 [사관다]
   1. 사물
      구조 사물클래스, 유스케이스, 컴포넌트, 노드 등
      시스템의 개념적 물리적 요소를 표현
      1. 행동 사물
         시간과 공간에 따른 요소들의 행위를 표현
      2. 그룹 사물
         요소들을 그룹으로 묶어서 표현
      3. 주해 사물
         부가적인 설명이나 제약조건 등을 표현
   1. 관계
      1. 연관 관계
      2. 집합 관계
      3. 의존 관계
      4. 실체화 관계
   2. 다이어그램
      1. 구조적 다이어그램 [클객 컴배 복패]
         1. 클래스 다이어그램
         2. 객체 다이어그램
         3. 컴포넌트 다이어그램
         4. 배치 다이어그램
         5. 복합체 구조 다이어그램
         6. 패키지 다이어그램
      2. 행위 다이어그램 [유시커 상활타]
         1. 유스케이스 다이어그램
         2. 시퀀스 다이어그램
         3. 커뮤니케이션 다이어그램
         4. 상태 다이어그램
         5. 활동 다이어그램
         6. 상호작용 개요 다이어그램
         7. 타이밍 다이어그램

1. 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어다.
2. 유스케이스
   1. 클래스 다이어그램시스템을 구성하는 요소를 문서화하는 데 사용클래스, 제약조건, 관계 등으로 구성
   2. 코딩에 필요한 객체의 속성, 함수 등의 정보를 잘 표현하고 있어 시스템을 모델링 하는 데 자주 사용된다.
   3. 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램
3. UML/클래스 간의 관계 [연집복 일의실]
   • 연관 관계
   • 집합 관계 : 하나의 객체에 여러 개의 독립적인 객체들이 구성
   • 복합 관계 : 영구적, 집합 관계보다 더 강한 관계
   • 일반화 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
   • 의존 관계 : 하나의 클래스가 또 다른 클래스 사용
   • 실체화
4. UI 시나리오 문서의 작성 요건 [완일이가 추수]
   1. 완전성, 일관성, 이해성, 가독성, 추적 용이성, 수정 용이성