Ch4 요구 분석

학습목표

• 요구 분석의 필요성과 어려운 점을 알아본다.
• 요구 사항을 표현하는 방법을 익힌다.
• 요구 분석 명세서를 살펴본다.

1. 요구 사항과 요구 분석 명세서의 이해

소프트웨어 개발의 궁극적인 목적

• 고객을 만족하도록 하는 것이다.
• 사용자의 요구를 만족하도록 하기위해서 다음과 같은 특성을 만족 시켜야한다.
  • 적시성(time to market): 사용자는 매우 복잡한 업무라도 빠른 시간에 만들기를 원하고 있다.
  • 유연성: 급변하는 환경에도 잘 적응할 수 있는 시스템을 원하고 있다.
  • 통합(intergration): 기존의 시스템과도 쉽게 통합할 수 있어야 한다.
• 고객 만족을 위해서는 원하는 품질의 제품을 정해진 개발 기간과 주어진 예산 범위 안에서 개발해야 한다.
• 그러려면 먼저 사용자의 요구 사항을 정확히 파악하고 분석하는 작업이 필요하다.

요구사항

• 사전적 의미: 이용자가 어떤 문제를 풀거나 목표를 달성하기 위해 필요한 조건이나 능력 이다.
• 소프트웨어 개발에서 요구 사항은 이와 유사하게 사용자와 개발자 간에 합의한 개발 범위에서 시스템이 제공해야 하는 기능을 말한다.

요구 분석 명세서

• 개발 초기에 사용자의 요구사항(비기능 요구 사항 포함)을 추출하여 정리한 문서
• 요구 분석 명세서에는 시스템의 기능이 무엇(what)인지에만 초점을 두어 정리하고 어떻게 구현할지는 기술할지는 기술하지 않는다
• 어떻게 구현 관점으로 설계에서 자세히 표현한다.

2. 요구 분석의 이해

1. 요구 분석의 정의와 목적

• 요구를 정의하는 일은 옷을 입을 때 첫 단추를 끼우는 것과 같다.
• 요구 분석을 하는 이유
  • 사용자에게 필요한 요구 사항을 추출하여 목표하는 시스템의 모델을 만들고 요구 분석 명세서를 작성하기 위해서이다.
  • 명세서에는 시스템이 만족시켜야 할 기능, 성능, 다른 시스템과의 인터페이스 등을 표현한다.

다양한 관련자들

• 발주사(고객)
• 경영자
• 발주 담당자 : 모든 절차를 준비하는 담당자(구매처)
• 사용자
• 수주사: 여러 업체들과의 경쟁에서 이겨 개발하기로 결정된 업체를 수주사라고 한다.
• 분석가: 요구 사항이 무엇이지 파악하고 추출하여 정리하는 것까지 담당한다.
• 설계자: 요구 분석 명세서를 바탕으로 코딩하기 위한 아키텍처 설계, 모듈 설계, DB설계 사용자 인터페이스 설계 등을 담당한다.
• 개발자: 좁은 의미로는 프로그래밍을 하는 프로그래머를 개발자

2. 요구 분석의 어려움

2.1 문제 영역에 대한 이해력 부족

• 문제 영역에 대해서는 전문서이 없는 경우가 많다.

2.2 의사소통의 문제

• 견본이 없는 경우가 대부분이고 요구 사항을 설명하기가 매우 어렵다.
• 사용자가 원하는 바를 어떻게 설명해야 할지 잘 모르기도 한다.
• 사용자의 의사 전달 능력(중요)에 따라 요구사항이 100%전달 되거나 안되거나

2.3 계속 변하는 요구 사항

• 처음 요구는 간단하고 단순할 수 있다.
• 새로운 요구 가 생긴다
• 이런 변경 사항을 계속 추적할 수 있도록 날짜별, 시간별로 잘 기록해놓아야 한다.
• 요구 사항 간의 충돌이나 일관성 결여 및 불일치 등이 발생할 수 있다.

2.4 애매모호한 요구 사항

• 애매하게 요구하면 분석가가 달리 해석할 수 도 있다.
• 사용자의 요구에 일관성이 없거나 서로 모순되는 경우도 발생한다 ( 서로 상충된다.)
• 분석가는 이러한 요구들을 정리하여 반영하기 위해 이해 당사자들 간의 주장을 조율할 수 있는 능력이 있어야 한다.

2.5 사용자와 개발자의 마찰

• 최적의 요구 분석 명세서를 만들어도 사용자가 그 내용을 달리 해석할 수도 있다.
• 마찰이 생길 수 도 있다.

3. 분석가에게 필요한 능력

3.1 의사소통과 협상 능력

• 우선순위를 결정
• 추상적인 사용자의 요구도 잘 파악하여 논리적 분할한다.
• 할수 있는 것 과 못하는 것 잘 구별할 줄 알아야한다?
• 다 해야되지만 우선순위가 있다.!

3.2 개발 업무 영역에 대한 지식

• 해당 영역에 대한 지식이 필요

3.3 개발 관련 기술에 대한 지식

• 사용자의 요구가 구현 가능한지 판단할 수 있어야 한다.
• 최근 기술에 대한 지식도 있어야 한다.
• 전체 기능을 세분화하고 통합된 전체 그림을 제시할 수도 있어야 한다.

3.4 이해 관계자들의 상반된 요구에 대한 중재 능력

• 경영자
  • 경영자 입장에서는 투자 대비 효과
• 고객
  • 개발 비용이 적게 들고 개발 기간을 잘 지킬 수 있는 업체에 더 많은 관심을 갈 것이다.
• 사용자
  • 자신의 업무를 효율적으로 처리할 수 있는지, 또 편리하게 해주는지 관심이 많다.

4. 요구 사항 수집 방법

4.1 자료수집

• 해당 업무에 관한 기존 자료를 수집하고 분석하는 일이다.
• 담당자들은 업무 매뉴얼 또는 업무 흐름도 등의 문서를 받아, 전반적인 업무 흐름을 파악하고 이해해야 한다.

4.2 인터뷰

• 순서가 정해져있는 것x →자료를 멎거 수집한후 이를 정리하여 분석한 결과를 바탕으로 인터뷰하는 것이 매우 효율적이다.
• 분석가가 사용자와 인터뷰
• 분석가가 경영자와 인터뷰

4.3 설문조사

 

3. 요구 분석 절차와 요구 사항 종류

01. 요구 분석 절차와 요구 사항 분류

• 요구 분석 절차

  

  자료 수집: 현행 시스템을 파악해 문제점 도출, 실무 담당자와 인터뷰, 현재 사용하는 서류 검토 등을 통해 가능한 모든 자료를 수집한다.

1. 요구 사항 도출: 수집한 자료를 정리하여 적절히 분류하고 여기서 개발에 반영할 요구 사항을 도출한다.
2. 문서화 : 도출한 요구 사항을 요구 분석 명세서로 문서화한다.
3. 검증 : 요구 분석 명세서를 검토한다. 사용자의 요구가 정확히 기록되어 서로 모순되는 사항은 없는지, 빠뜨리지 않고 전부 기록하고 있는지 등을 점검한다

• 요구 사항 분류

  

  시험에는 비기능적 요구사항 많다

• 현업에는 기능적 요구사항 많다.

02. 기능적 요구 사항과 비기능적 요구 사항

2.1 기능적 요구 사항

• 기능적 요구 사항은 단어의 뜻대로 사용자가 원하는 기능을 말함.

2.2 비기능적 요구 사항

• 수행 가능한 환경, 품질, 제약 사항이다.

제약 사항

• 개발된 소프트웨어가 수행되는 환경과 같은 조건을 말한다.
• 예
  • 자바 언어를 사용해 개발하고, CBD 개발 방법론을 적용해야 한다.
  • 레드햇 리눅스 엔터프라이즈 버전에서 실행해야 한다.
  • 웹로직 서버를 미들웨어로 사용해야 한다.
  • 윈도우즈 운영체제와 리눅스 운영체제에서 모두 실행할 수 있어야한다.

품질

사용자에 관련된 품질, 개발자에 대한 품질

• 신뢰성(reliability)
  • 소프트웨어를 믿고 사용할 수 있는 것.
  • 사용자가 주어진 시간과 주어진 환경에서 소프트웨어를 고장 없이 사용할 수 있어야 한다는 것.
  • 신뢰도란 ‘장애 없이 동작하는 시간의 비율’

    

• 성능
  • 사용자가 원하는 조건(응답 시간, 데이터 처리량 등)을 만족시키는 것이다.
  • 예) 대학 종합정보시스템은 수강 신청 시 동시 접속자 수 10000명이 가능해야 한다.
• 보안성
  • 허가받은 담당자만 해당 시스템에 접근할 수 있도록 해야한다.
• 안전성
• 사용성
  • 사용자에게 가장 민감
  • 사용할때 헷갈리지 않고 단순하고 편리하게 만들어야 한다.

3. 사용자 요구 사항과 시스템 요구 사항

• 사용자를 위한 도면
• 시공자를 위한 도면

3.1 사용자 요구 사항

• 유사한 프로젝트 경험을 가진 분석가 선정
• 표준 양식 사용
• 수집한 요구 사항에 대한 근거(출처) 마련

3.2 시스템 요구 사항

• 설계자가 설계하는 데 도움이 되도록 기술적 용어나 전문적인 표현을 써서 시스템 요구 분석 명세서로 작성
• 완전하고 일관성 있게 작성되어야 한다.
• 구조적 방법론의 구조적 언어나 객체지향 방법론의 유스케이스 다이어그램, 검증에 강한 Z명세와 같은 정형화된 수학적 명세 언어 사용 표현

4. 요구 사항의 표현

• 소프트웨어 개발에서 사용하는 모델의 개념을 이해해보고 모델링 방법과 모델링 언어의 종류에 대해 살펴 본다.

1. 표현과 모델의 이해

• 잘 표현해야 소통이 쉽고 서로 이해하는 데 큰 도움이 된다.

2. 모델의 정의와 필요성

• 모델은 ‘어떤 복잡한 대상의 핵심 특징만 선별하여 일정한 관점으로 단순화 시켜 기호나 그림 등을 사용해 체계적으로 표현한 것’
• 모델이 필요한 가장 큰 이유는 모델을 통해 실제 모습을 생각하고 확인해 볼 수 있기 때문이다.

2.1 소프트웨어 개발에서의 모델

통합 모델링 언어(UML, 영어: Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어이다.[1] 이 표준은 UML을 고안한 객체 관리 그룹에서 관리 하고 있다. UML은 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다.

• 개발될 소프트웨어에 대한 이해도 향상, 이해 당사자 간의 의사소통 향상
• 유지 보수 용이
• 과도한 문서 작업으로 인한 일정 지연 가능성
• 형식적인 산출물로 전략할 가능성

3. 모델링

• 현실 세계를 단순화하여 표현하는 기법이라 할 수 있다.

4. 모델링 언어

4.1 DFD(Data Flow Diagram)

• 사용자 요구 사항을 구적 방법론

  

4.2 E-R 다이어그램(ERD: Entity-Relationship Diagram)

• DB설계는 E-R 다이어 그램
• 정보공학 방법론의 핵심
• 데이터베이스에 저장할 데이터를 개체(entity)와 관계를 중심으로 작성한다.

4.3 유스케이스 다이어그램

• 객체지향 방법론에서 UML의 유스케이스 다이어그램으로 표현한다.

• 유스케이스 (usecase)
  • 사용자의 요구를 나타내는 기능으로, 실제로 코딩할 수 있을 만큼의 가장 작은 단위의 기능이다.
  • 예

    

• 액터(actor)
  • 액터는 개발하려는 시스템의 기능을 사용하는 사람 또는 해당 시스템과 연동되는 다른 시스템을 말한다.
    • 사용자 액터
      • 사용자 액터는 시스템을 사용하는 사람이라고 했지만 정확히 말하면 사람이 아닌 그 역할 이다.
    • 시스템 액터
      • 본 시스템과는 데이터를 주고받는 등 서로 연동되는 또 다른 시스템을 말함
      • 연동이라는 개념은 일방적으로 데이터를 파일이나 정해진 형식으로 만들어 넘겨주는 것을 연동이라 하지 않음. 개발될 시스템이 그 시스템(은행, 교육부시스템)에 접근할 수 있을 때 연동이라는 개념을 쓴다.

        

객체 지향 프로그래밍(영어: Object-Oriented Programming, OOP)은 컴퓨터 프로그래밍의 패러다임 중 하나이다. 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.

객체 지향 프로그래밍은 프로그램을 유연하고 변경이 쉽게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 또한 프로그래밍을 더 배우기 쉽게 하고 소프트웨어 개발과 보수를 간편하게 하며, 보다 직관적인 코드 분석을 가능하게 하는 장점이 있다. 그러나 지나친 프로그램의 객체화 경향은 실제 세계의 모습을 그대로 반영하지 못한다는 비판을 받기도 한다.

• 소프트웨어 개발에서 사용하는 모델의 개념을 이해해보고 모델링 방법과 모델링 언어의 종류에 대해 살펴 본다.

5. 요구 사항의 문서화

1. 요구 분석 명세서의 이해

• 요구 사항을 문서화할 때는 완성될 소프트웨어의 기능적 요구를 정확하게 서술해야 한다. 또 구현 시의 제약 사항, 품질 등의 비기능적 요구 사항도 서술해야 한다.
• 정의
  • 요구 분석 과정의 최종 산출물로 사용자와 연결시키는 중요한 문서
  • 설계 및 구현에서 참조할 사항, 전반적으로 알아야 할 사항을 포함하는 문서
  • 사용자와 개발자 간의 계약서
• 명세서 작성은 분석가의 역할이다.

2. 요구 분석 명세서 작성 시 주의 사항

• 사용자가 읽기 쉽고 ,이해할 수 있도록 작성한다.
• 개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성한다.
• 비기능적 요구를 명확히 작성한다.
• 테스트 기준 용도로 사용할 수 있도록 정량적으로 작성한다.
• 품질에 대한 우선순위를 명시한다.

3. 잘 만든 요구 분석 명세서의 특성

• 완전성
• 명확성
• 일관성(consistency)무모순성
• 추적 가능성
  • 프로그램에 오류가 발생하면 그 부분이 설계 사양서에서 어디에 해당되는지 추적할 수 있어야 한다.
• 변경 용이성
• 검증 가능성

4. 요구 명세 기법

4.1 비정형 명세 기법

• 자연어를 기반으로 서술하는 방법이다.
• 작업 흐름도와 같은 다이어그램을 사용해 작성한다.

4.2 정형 명세 기법

• 수학적 원리와 표기법 을 이용
• Z 정형 명세 언어
• 정확하고 간결하게 표현할 수 있으며, 일관성이 있는지 , 완전한지 등을 검증

5. 요구 사항 검증

6. 요구 분석 명세서의 기본 항목