1장 - 요구사항 확인 핵심 요약

2024년도 시나공 필기 책 내용 정리

---

섹션1 소프트웨어 생명주기

 

1. 소프트웨어 공학

 

• 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 소프트웨어의 개발, 운용, 유지보수에 대한 체계적인 접근 방법
• 소프트웨어의 품질과 생산성을 향상시킬 목적으로함
• 경제적인 비용을 들여 신뢰성 높은 소프트웨어를 개발하기 위해 공학적 원리를 정립하고 이를 적용하는 것

2. 소프트웨어 공학의 기본 원칙

 

• 현대적인 프로그래밍 기술을 계속적으로 적용해야 함
• 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지 해야함

3. 폭포수 모형(Waterfall Model)

 

• 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
• 보헴이 제시한 고전적 생명 주기 모형
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
• 개발 과정에서 발생하는 요구사항을 반영하기 어려움

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

 

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발 될 소프트웨어에 대한 견본(시제)품을 만들어 최종 결과물을 예측하는 모형
• 시제품은 의뢰자나 개발자 모두에게 공동의 참조 모델이 됨
• 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 됨
• 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어를 구현하는 방법
• 단기간 제작 목적으로 인하여 비효율적인 언어나 알고리즘이 사용될 수 있음

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

 

• 보헴이 제안한 것으로, 폭포수 모형과 프로토 타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
• 계획수립 -> 위험분석 -> 개발 및 검증 -> 고객평가 과정이 반복적으로 수행됨
• 핵심 기술에 문제가 있거나 사용자의 요구사항이 이해하기 어려운 경우 적합한 모델

6. 애자일 모형(Agile Model)

 

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행
• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형
  
  • 스트럼(Scrum)
  • XP(eXtreme Programming)
  • 칸반(kanban)
  • 린(Lean)
  • 크리스탈(Crystal)
  • ASD(Adaptive Software Development)
  • 기능 중심 개발(FDD: Feature Driven Development)
  • DSDM(Dynamic System Development Method)
  • DAD(Disciplined Agile Delivery) 등

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

 

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

---

섹션2 스크럼(Scrum)기법

 

1. 스크럼팀

• 제품 책임자(PO: product Owner)
  
  • 이해관계자들 중 개발된 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당
  • 이해관계자들의 의견을 종합하여 제품에 대한 요구 사항을 작성하는 주체
  • 요구사항이 담긴 백로그를 작성하고 백로그에 대한 우선순위를 지정
• 스크럼 마스터(SM: Scrum Master)
  
  • 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행
• 개발팀(DT: Development Team)
  
  • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
  • 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 됨

2. 스크럼 개발 프로세스

 

• 제품 백로그(Product Baklog) : 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
• 스프린트 계획 회의(Sprint Planning Meeting) : 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
• 스프린트(Sprint) : 실제 개발 작업을 진행하는 과정으로 보통 2 ~ 4주 정도의 기간 내에서 진행
• 일일 스크럼 회의(Daily Scrum Meeting) : 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검
• 스프린트 검토 회의(Sprint Review) : 부분 또는 전체 완성제품이 요구사항에 잘 부합하는지 사용자가 포함된 참석자 앞에서 테스팅을 수행
• 스프린트 회고(Sprint Retrospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록

---

섹션3 XP(eXtreme Programming) 기법

 

1. XP 개요

 

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 대표적인 애자일 개발 방법론 중 하나
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함
• 자동화된 테스팅 도구를 사용하여 테스트를 지속적으로 수행

2. XP의 핵심가치

 

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

3. XP 개발 프로세스

 

• 사용자 스토리(User Story) : 고객의 요구사항을 간단한 시나리오로 표현한 것
• 릴리즈 계획 수립 (Release Planning) :  몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함
• 스파이트(Spike) : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
• 이터레이션(Iteration) : 하나의 릴리즈를 더 세분화 한 단위를 이터레이션이라고 함
• 승인검사(Acceptance Test, 인수테스트) : 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
• 소규모 릴리트(Small Release) : 릴리즈를 소규모로 하게되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응할 수 있음

4. XP의 주요 실천 방법

 

• Pair Programming(짝 프로그래밍) : 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성
• Collective Ownership(공동 코드 소유) : 개발 코드에 대한 권한과 책임을 공동으로 소유함
• Continuous Intergration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합됨
• Refactoring(리펙토링) : 프로그램의 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템의 내부 구조를 재구성함

---

섹션4 현행 시스템 파악

 

1. 현행 시스템 파악 절차

 

• 1단계 : 시스템 구성 , 시스템 기능 , 시스템 인터페이스 파악
• 2단계 : 아키텍처 구성, 소프트웨어 (DBMS, 운영체제 등) 구성 파악
• 3단계 : 하드웨어 구성, 네트워크 구성 파악

---

섹션5 개발 기술 환경 파악

 

1. DBMS 분석 시 고려사항

 

• 가용성
• 성능
• 기술지원
• 상호 호환성
• 구축비용

2. WAS(Web Application Sever)

 

• 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
• 종류 : Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등

---

섹션6 요구사항 정의

 

1. 기능 요구사항

 

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

2. 비기능 요구사항

 

• 성능 요구사항 : 처리속도 및 시간, 처리량 등의 요구사항
• 보안 요구사항 : 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
• 품질 요구사항 : 품질 평가 대상에 대한 요구사항

3. 요구사항 개발 프로세스

 

• 도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)

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

 

• 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
• 요구사항 도출 기법 : 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스

5. 요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반 모델 기반	상태/기능/객체 중심
작성방법	수학적 기호, 정형화된 표기법	자연어를 기반으로 작성 다이어그램으로 작성
특징	요구사항을 정화하고 간결하게 표현	일관성이 떨어짐 의사소통이 용이함
종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER모델링, State Chart(SADT) 등

 

6. 요구사항 확인(검증)

 

• 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인하는 것이 필요
• 요구사항이 실제 요구를 반영하는지, 서로 상충되는 요구사항은 없는지 등을 점검
• 개발이 완료 된 후 문제가 발견되면 재작업 비용이 발생할 수 있으므로 요구사항 검증은 매우 중요함
• 요구사항 검증 과정을 통해 모든 문제를 확인할 수 있는 것은 아님

---

섹션7 요구사항 분석

 

1. 요구사항 분석의 개요

 

• 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미
• 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지를 결정
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 사용자의 요구사항은 예외가 많고 지속적으로 변하므로 열거와 구조화가 어려움
• 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 중재하는 과정
• 요구사항 분석을 위해 UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD),  상태 전이도(STD), 제어 명세서 등의 도구를 이용

2. 자료 흐름도의 구성 요소

 

• 프로세스(process)  : 원
• 자료흐름(data flow) : 화살표
• 자료 저장소(data store) : 이중선
• 단말(terminator) : 네모

3. 자료 흐름도 작성 지침

 

• 자료 흐름은 처리(process)를 거쳐 변환될 때마다 새로운 이름을 부여
• 어떤 처리(process)가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생 해야함
• 상위 단계의 처리(process)와 하위 자료 흐름도의 자료 흐름은 서로 일치 되어야 함
• 입력 화살표가 있다고 하여 반드시 출력 화살표가 있어야 하는 것은 아님

4. 자료 사전의 표기 기호

기 호	의 미
=	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
(  )	자료의 생략 : 생략 가능한 자료(Optional)
[ | ]	자료의 선택 : 또는(or)
{  }	자료의 반복 : Iteration of
*  *	자료의 설명 : 주석 (Comment)

---

섹션8 요구사항 분석 CASE(자동화도구)와 HIPO

 

1. SADT

 

• SoftTech 사에서 개발한 구조적 분석 및 설계 도구
• 블록 다이어그램을 채택한 자동화 도구

2. HIPO

 

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타냄
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉬움
• 기능과 자료의 의존 관계를 동시에 표현할 수 있음
• 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 함
• HIPO Chart의 종류 : 가시적 도표(Visual Table of Contents), 총제적 도표(Overview Diagram), 세부적 도표(Detail Diagram)

---

섹션9 UML(Unified Modeling Language)

 

1. UML 개요

 

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• 구성요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)

2. 사물 (Things)

 

• 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말함
• 종류 : 구조사물(Structural Things), 행동사물(Behavioral Things), 그룹사물(Grouping Things), 주해사물(Annotation Things)

3. 의존(Dependency)관계

 

• 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
• 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계

4. 실체화(Realization)관계

 

• 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
• 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계

5. 일반화(Generalization)관계

 

• 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
• 예를 들어 차는 버스, 트럭, 택시보다 일반적인 개념이고 버스, 트럭, 택시는 차보다 구체적인 개념

6. 구조적(정적)다이어그램의 종류

 

• 클래스 다이어그램
• 객체(Object) 다이어그램
• 컴포넌트 다이어그램
• 배치(Deployment) 다이어그램
• 복합체 구조(Composite Structure) 다이어그램
• 패키지 다이어그램

7. 행위(동적) 다이어그램의 종류

 

• 유스케이스 다이어그램
• 순차(Sequence) 다이어그램
• 커뮤니케이션 다이어그램
• 상태(State) 다이어그램
• 활동(Activity) 다이어그램
• 상호작용 개요(Interaction Overview) 다이어그램
• 타이밍 다이어그램

8. 상태(state) 다이어그램

 

• 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
• 객체들 사이에서 발생하는 이벤트(event)에 의한 객체들의 상태 변화를 그림으로 표현
• 럼바우(Rumbaugh)객체지향 분석 기법에서 동적 모델링에 활용됨

9. 활동 다이어그램

 

• 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
• 오펴레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 단계적으로 표현

10. 스테레오 타입

 

• UML에서 표현하는 기본기능 외에 추가적인 기능을 표현하기 위해 사용
• 길러멧(Guilemet)이라고 부르는 겹화살괄호<< >> 사이에 표현할 형태를 기술

---

섹션10 주요 UML 다이어그램

 

1. 유스케이스 다이어그램

 

• 시스템 / 시스템 범위 : 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
• 액터 : 시스템과 상호작용을 하는 모든 외부요소로 사람이나 외부 시스템을 의미
• 주액터 : 시스템을 사용함으로써 이득을 얻는 대상(주로 사람)
• 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템(조직이나 기관 등이 될 수 있음)
• 유스케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것
• 관계(Relationship) : 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있고 연관관계, 포함관계, 확장관계, 일반화 관계를 표현할 수 있음

2. 유스케이스 확장관계

 

• 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계

3. 클래스 다이어그램 - 오퍼레이션(Operation)

 

• 클래스가 수행할 수 있는 동작으로 함수(메소드, Method)라고도 함

4. 순차 다이어그램의 개요

 

• 시스템이나 객체들이 메세지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메세지 등의 요소를 사용하여 그림으로 표현한 것
• 순차 다이어그램은 시스템이나 객체들의 상호 작용과정에서 주고받는 메세지를 표현
• 순차 다이어그램에서 수직방향은 시간의 흐름을 나타냄

5. 순차 다이어그램의 구성요소

• 액터(Actor)
• 객체(Object)
• 생명선(Lifeline)
• 실행 상자(Active Box)
• 메시지(Message)
• 회귀 메시지(Reply / Return Message)
• 제어 블록(lㅣoop)