[정보처리기사] 1장. 요구사항 확인

소프트웨어 생명 주기

소프트웨어 생명 주기(Software Life Cycle)

• 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
• 소프트웨어 생명주기는 소프트웨어 개발 단계와 각 단계별 주요 활동 그리고 활동의 결과에 대한 산출물로 표현
• 대표적인 생명주기 모형
  • 폭포수 모형
  • 프로토타입 모형
  • 나선형 모형
  • 애자일 모형

폭포수 모형(Waterfall Model)

• 폭포수 모형은 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명주기 모형
• 고전적 생명주기 모형이라고도 함
• 모형을 적용한 경험과 성공 사례가 많음
• 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함

프로토타입 모형(Prototype Model, 원형 모형)

• 프로토타입 모형은 사용자의 요구사항을 파악하기 위해 실제 개발된 소프트웨어애 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발

나선형 모형(Spiral Model, 점진적 모형)

• 나선형 모형은 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
• 보헴(Bohem)이 제안하였음
• 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 누락되거나 추가된 요구사항을 첨가할 수 있음
• 유지보수 과정이 필요 없음
• 4가지 주요 활동
  • [계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가]를 반복

애자일 모형(Agile Model)

• 애자일은 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
• 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭
• 기업 활동 전반에 걸쳐 사용됨
• 대표적인 개발 모형
  • 스크럼(Scrum)
  • XP(eXtreme Programming)
  • 칸반(Kanban)
  • Lean
  • 기능 중심 개발(FDD: Feature Driven Development)

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

• 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둠
• 방대한 문서보다는 실행되는 SW에 더 가치를 둠
• 계약 협상보다는 고객과의 협업에 더 가치를 둠
• 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둠

소프트웨어 공학

• 소프트웨어 공학(SE: Software Engineering)은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 함
• 소프트웨어 공학의 기본 원칙
  • 현대적인 프로그래밍 기술을 계속적으로 적용해야 함
  • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함
  • 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함

XP(eXtreme Programming) 기법

XP(eXtreme Programming)

• XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함
• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임

XP의 5가지 핵심가치

• 의사소통(Communication)
• 단순성(Simplicity)
• 용기(Courage)
• 존중(Respect)
• 피드백(Feedback)

XP 개발 프로세스

출처 : https://blog.skby.net/xp-extreme-programming/

프로세스	내용
릴리즈 계획 수립 (Release Planning)	- 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것 - 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함
이터레이션 (Iteration, 주기)	- 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도 기간으로 진행됨
승인 검사 (Acceptance Test, 인수 테스트)	- 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
소규모 릴리즈 (Small Release)	- 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것

XP의 주요 실천 방법(Practice)

실천 방법	내용
Pair Programming (짝 프로그래밍)	- 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성함
Collective Ownership (공동 코드 소유)	- 개발 코드에 대한 권한과 책임을 공동으로 소유함
Test-Driven Development (테스트 주도 개발)	- 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악함 - 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크)를 사용함
Whole Team (전체 팀)	- 개발에 참여하는 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함
Continuous Integration (계속적인 통합)	- 모듈 단위로 나눠서 개발된 코드들을 하나의 작업이 마무리 될 때마다 지속적으로 통합됨
Refactoring (리팩토링)	- 프로그램 기능의 변경 없이 시스템을 재구성함 - 목적 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함
Small Releases (소규모 릴리즈)	- 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있음

요구사항 정의

요구사항

• 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건
• 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공
• 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 줌
• 요구사항의 유형
  • 기능 요구사항(Functional requirements)
  • 비기능 요구사항(Non-functional requirements)
  • 사용자 요구사항(User requirements)
  • 시스템 요구사항(System requirements)

기능 요구사항(Functional requirements)

• 기능 요구사항은 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항임
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
• 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능

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

• 비기능 요구사항은 품질이나 제약사항과 관련된 요구사항임
• 시스템 장비 구성 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 데이터를 구축하기 위해 필요한 요구사항
• 테스트 요구사항
• 보안 요구사항
• 품질 요구사항: 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등
• 제약사항
• 프로젝트 관리 요구사항
• 프로젝트 자원 요구사항

사용자 요구사항(User requirements)

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

시스템 요구사항(System requirements)

• 시스템 요구사항은 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
• 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현됨
• 소프트웨어 요구사항이라고도 불림

요구사항 개발 프로세스

요구사항 개발 프로세스

• 요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
• 요구사항 개발 프로세스가 진행되기 전에 타당성 조사(Feasibility Study)가 선행되어야 함
• 요구사항 개발은 요구공학(Requirement Engineering)의 한 요소임
• 요구사항 개발 프로세스
  • [도출 → 분석 → 명세 →  확인]

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

• 요구사항 도출은 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
• 개발자와 고객 사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별됨
• 소프트웨어 개발 생명 주기(SDLC)동안 지속적으로 반복됨
• 요구사항을 도출하는 주요 기법
  • 청취와 인터뷰
  • 설문
  • 브레인스토밍
  • 워크샵
  • 프로토타이핑
  • 유스케이스

요구사항 분석(Requirement Analysis)

• 요구사항 분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 서로 상충되는 요구사항이 있으면 이를 중재하는 과정
• 요구사항 분석에 사용되는 대표적인 도구
  • 자료 흐름도(DFD)
  • 자료 사전(DD)

요구사항 명세(Requirement Specification)

• 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미
• 기능 요구사항을 빠짐없이 기술함
• 비기능 요구사항은 필요한 것만 기술함
• 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있음

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

• 요구사항 확인은 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
• 이해관계자들이 검토해야 함
• 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리(SCM)를 수행함

요구공학(Requirement Engineering)

• 요구공학은 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
• 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 함

요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화된 표기법	일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
특징	- 요구사항을 정확하고 간결하게 표현할 수 있음 - 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있으므로 완전성 검증이 가능함 - 표기법이 어려워 사용자가 이해하기 어려움	- 자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라 다를 수 있어 일관성이 떨어지고, 해석이 달라질 수 있음 - 내용의 이해가 쉬어 의사소통이 용이함
종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER모델링, State Chart(SADT) 등