Computer Science/Software Engineering

[CS][소프트웨어공학] SW 요구사항, SW 개발 방법론, DFD, 자료사전

y-seo 2023. 10. 16. 14:55
 
 

[1] 요구사항의 정의

  • 요구사항 (requirements)
    • 시스템이 제공해야 할 역량 (capability)
    • 외형적으로 나타내는 기능이나 성능
    • SW 시스템이 수행해야 할 것과 SW 시스템에 있어야 할 특성을 명시적으로 기술한 문장
  • SW 개발 기준
    • 여러 이해 당사자 (stakeholder)의 이해 관계와 관련되어 있다.
    • SW가 무엇을 해야 하는가를 표현해야 한다.
    • 프로젝트 실패의 가장 중요한 이유는 명확하지 못한 요구사항 정의이다. 요구 사항은 각각의 position에서 해석해도 문제가 없게끔 정의해야 한다.

 

 
 

[2] 요구사항의 분류

  • 기능 요구
    • 고객이 요구하는 시스템이 처리할 기능
    • 업무 절차나 기계 동작을 실현한 것
    • 동사로 표현된다.
    • 쉽게 파악된다.
    • 제품 기능을 의미한다.
    • 사용 사례로 정리할 수 있다.
    • UML : 객체 지향 방법론이 제공하는 양식
    • UseCase : 기능 설명 시 사용
  • 기능적 요구 (functional requirements)
    • 시스템이 외형적으로 나타내는 기능과 동작
    • 시스템과 외부 요소들 간의 interaction (어떤 상태일 때 외부의 데이터나 명령을 받아들여 어떤 반응을 하는지 기술하는 것이다.)
    • 구현 기술과는 독립적이어야 한다.
    • Ex. 도서관 정보 시스템
      • 사용자가 전체 도서 데이터베이스 또는 선택한 일부 데이터베이스에서 검색이 가능해야 한다.
      • 모든 도서 대출은 고유번호가 주어지고, 사용자 정보에 저장되어야 한다.
  • 비기능 요구
    • 요청된 기능 이외에 시스템이 갖추어야 할 조건, 특징
    • 응답 속도, 고장에서 회복되는 기간, 보안 등
    • 기능보다 더 중요한 사안이 될 수 있다.
    • 형용사로 표현된다.
    • 파악하기 어렵다
    • 주로 제품 속성을 이야기 한다.
  • 비기능적 요구 (non-functional requirements)
    • 성능, 사용용이성, 보안 등 기능 이외의 사항
    • 시스템 구축이나 동작에 대한 제한 사항들
    • 요구분석 이후 설계 단계에서 결정해야 언어, 플랫폼, 구현의 선택을 까다롭게 할 수 있다.
    • 기능적 요구사항보다 더 중요할 수 있다.

 

 
 

[3] 요구사항 정의 품질

  • 요구사항 정의 시 나타나는 치명적 과실
    • 노이즈 발생 : 관련 없는 정보 포함, 모호한 표현
    • 침묵 발생 : 언급되어야 할 사항의 누락
    • 과도한 스펙 명세 : 결정되지 않은 구현 관련 사항 포함
    • 모순 발생 : 전후 내용에 일관성이 없는 것
    • 모호성 : 하나의 표현이 여러가지 의미로 해석
    • 전방 참조 : 아직 정의하지 않은 사항을 참조
    • 사실이 아닌 기대 사항 : 막연한 추측과 기대에 근거
  • 요구사항 품질
    • 원자적 (atomic) : 단일 목표를 가진 기능으로 표현, 간단한 문장으로 기술되어야 한다.
    • 완전성 (complete) : 필요한 정보가 다 기술되어야 한다.
    • 비모호성 (unambiguous) & 일관성 (consistent) : 앞뒤말이 다르지 않아야 한다.
    • 추적성 (traceable) : 생성하는 모든 항목에 대해 번호를 부여하여 나중에 거슬려 올라갈 수 있게끔 해야 한다.
    • 우선순위화 (prioritize) : 일정 관리에도 사용한다.
    • 테스트 가능성 (testable) : 검증 가능한 요구사항이어야 한다.

 

 
 

[4] 요구사항 수집 기법

  • 시스템이 수행하여야 할 것들에 대한 정보를 많은 정보원(information source)를 통해 수집
    • 개인과의 인터뷰
    • 작업자 관찰
    • 업무 문서/양식 조사
    • JAD (Joint Application Design)
    • 프로토타이핑

 

 
 

[4.1] 인터뷰

  • 인터뷰 및 탐문
    • 운영과 현 시스템의 이슈, 앞으로의 조직 활동에 따른 시스템에 대한 요구사항 등에 관해서 인터뷰 수행
    • 진술, 의견, 견해 등을 수집
    • 몸짓과 감정을 관찰 (이것이 직접 만나는 이유이다.)
  • 인터뷰 질문
    • 개방형 질문 (Open-Ended) : 사전에 정의된 답변이 아닌, 예기치 못한 답변을 이끌어 내는 데에 사용한다.
    • 폐쇄형 질문 (Close-Ended) : 응답자는 사전에 정의된 응답 중에서 답을 선택하도록 요청 받는다. 질문에 대한 흔한 답변이 알려져 있을 때 매우 유용하다. 많은 시간이 필요하지 않기 때문에 많은 수의 토픽들을 다룰 수 있다.
  • 효과적인 인터뷰를 위한 지침
    • 인터뷰 일정의 수립 : 대상자들에게 인터뷰 목적을 설명하고 일정을 약속, 인터뷰를 위한 체크리스트, 의사일정, 질문 등을 준비
    • 중립적인 인터뷰 : 유도심문을 피해야 한다.
    • 인터뷰 내용의 기록과 검토 : 인터뷰 수행 후 48시간 이내에 인터뷰 일지를 검토해야 한다.
    • 다양한 관점을 유지 : 잠재적 사용자와 관리자 등 넓은 폭의 사용자들을 대상으로 인터뷰를 수행해야 한다.

 

 
 

[4.2] 작업자 관찰

  • 사용자 직접 관찰하기
    • 정해진 시간에 작업자를 관찰하여 데이터가 어떻게 다루어 지고, 업무를 위해 필요로 하는 정보가 무엇인지를 파악
    • 인터뷰를 보완하는 좋은 방법
    • 대부분 편견이 없는 데이터를 얻기가 어렵다. 사람들은 관찰을 당하고 있으면 대부분 본심과 다르게 행동하기 때문이다.

 

 
 

[4.3] 업무 문서의 분석

  • 조직에서 사용하는 데이터와 정보에 대한 구체적인 사례, 보고된 이슈, 정책, 규칙 등을 발견하기 위함이다.
  • 문서를 통해 찾을 수 있는 정보의 유형
    • 기존 시스템의 문제 (결여된 정보, 중복된 절차 등)
    • 조직이 추구하는 방향 (Ex. 고객 및 공급자와의 긴밀한 관계)
    • 주요 사용자들의 직위와 이름 (Ex. 고객 행위 분석을 담당하는 영업 관리자)
    • 조직의 가치 판단 기준 (Ex. 수익보다는 시장 점유율)
    • 데이터, 데이터 처리 규칙, 조직의 운영 원리

 

 
 

[4.4] JAD

  • 합동응용시스템설계 (Joint Application Design)
    • 회의 유형
    • 최종 사용자와 정보시스템 전문가가 한자리에 모인 대화의 자리에서 시스템 설계를 논의 (조율, 일주일 정도 내내)
    • 주 사용자, 관리자, 시스템 분석가를 모이게 한다.
    • 목적 : 주요 사람들로부터 시스템 요구사항을 동시에 수집하기 위함이다.
    • 사용자 참여를 유도하여 시스템 설계를 가속화 환다.
  • 최종 결과 형태
    • 기존 시스템에 대한 자세한 문서
    • 제안된 시스템의 특성에 대한 자세한 문서
  • JAD 회의를 위한 일반적인 회의실 상태은 토론 형식이다.
    • 문제점 : 비용, 시간, 편향
    • 최근에는 e-JAD로 그룹웨어를 이용한 JAD를 실현

 

 
 

[4.5] 프로토타이핑 (Prototyping)

  • 시스템 초기 버전이 빠르게 구축될 수 있다.
  • 요구사항 조사 프로세스를 강화시킬 수 있다.
  • 요구사항을 구체화 할 수 있다.
  • 목적 : 최종 시스템을 개발하는 데에 있는 것이 아니고 최종 시스템의 구체적인 세부 내역을 개발하는 것에 있다.
  • 가장 유용한 상황
    • 사용자의 요구사항이 명확하지 않은 경우
    • 적은 수의 사용자들이 관련되어 있는 경우
    • 설계가 복잡해서 평가를 하기 위해서는 구체적으로 볼 수 있는 형태가 요구되는 경우
    • 분석가와 사용자 간의 의사소통 문제가 발생했던 경험이 있는 경우
    • 프로토타입을 만들 수 있는 도구들이 구비되어 있는 경우
    • 사용자의 적극성에 따라 양상이 다를 수도 있다. 따라서 사용자의 참여가 중요하다.

 

 
 

[5] 요구사항 정의서

  • SRS (SW requirement Specification)
  • 사용자의 요구사항과 개발 관련 요구사항을 정의한 문서
  • IEEE803 요구명세 표준을 따른다.
  • 준수해야 할 사항
    • 모든 요구사항에 유일한 식별자를 부여해야 한다.
    • 각 요구사항은 문장의 5형식에 따라 그 의미를 정확히 표현해야 한다.
    • 각 요구사항을 정의하는 문장은 복문이 아닌 단문으로 작성해야 한다.
    • 요구사항에 대해 우선순위를 부여해야 한다.
    • 요구사항을 그룹핑하여 체계화 해야 한다.

요구사항 정의서 예시 양식

 

 
 

[6] SW 개발 방법론

  • SW 개발에 관한 계획, 분석, 설계 및 구축에 관련된 방법과 절차, 도구 등 공학적인 기법으로 체계적으로 정리하여 표준화한 이론
  • 필요성
    • 작업의 표준화와 모듈화
    • 효과적인 프로젝트 관리
    • 표준화가 되면 관리하기 용이
    • 정형화된(작게 분리된) 절차와 표준용어의 제공으로 의사소통 수단 제공
  • 발전

  • 주요 방법론
    • 구조적(Structured) 방법론
      • 프로세스 중심 (Process-oriented)
      • 논리적 모델과 물리적 모델에서 분할하여 기능적 분해를 먼저 한 후 모듈로 구조화
    • 정보공학 방법론
      • 데이터 중심 (Data-oriented) 개발
      • ER 모델링 (Entity-Relationship Modeling)
    • 객체지향 (Object-oriented) 방법론
      • SW를 데이터와 로직이 통합된 객체로 보고, 객체들의 정적 관계와 동적인 상호 작용을 모델링하는 방법
      • 객체를 시스템 구성의 단위로 본다.
분석 방법 프로그램 관점 분석 시 강조점
구조적 방법론 자료 + 함수 자료보다는 함수에 중점
프로세스를 먼저 정하고 프로세스에 대한 입출력을 나중에 정함
객체지향 방법론 객체 + 객체 객체와 객체 간의 관계 파악이 중요
객체가 가지는 자료와 연산
정보공학 방법론 자료 자료 및 자료들 간의 관계를 먼저 파악
자료에 대한 연산 패턴으로 프로세스를 그룹화

 

 
 

[6.1] 구조적 방법론

  • Structured Development Mehodology
  • 프로세스 중심 모델링
    • 절차지향 언어들이 있었다.
    • 전통적인 데이터 처리 시스템 개발에 적절한 기법
    • 사용자의 요구분석 사항을 파악하기 위하여 자료의 흐름과 가공절차(프로세스)를 표현한다.
    • 구조적 분석 : 실세계의 문제를 처리 관점으로 모델링 → DFD (data flow diagram) 을 사용한다.
    • 구조적 설계 : DFD를 모듈 사이의 관계를 나타내는 구조도 (Structure chart) 로 변경하는 과정
  • 구조적 방법론의 특징
    • 그림 중심
    • 모듈의 분할과 정복에 의한 하향식 설계 방식으로 기능이 시스템 분석, 설계, 구현의 근간
    • 사용자의 업무 요구사항을 쉽게 문서화할 수 있고 사용자 개발자 간의 의사소통이 용이
    • 철저한 모듈화로 추상화와 정보 은닉을 이루어 프로그램의 구조를 읽기 쉽게 단순화
  • 구조적 방법론의 원칙
    • 추상화(Abstraction)의 원리
    • 형식화(Formality)의 원리 : 간소화
    • 분할정복의 개념 : 작게 나누어 해결
    • 계층화 원칙 : 모듈화 원칙, 작게 나누어 그룹화하고 계층 구조로 표현한다, 하위 계층일수록 상세화이고 상위 계층일수록 개략적이다.
  • 구조적 분석 방법의 3가지 모형화 도구
    • 자료흐름도(DFD) : 기능적 측면에서 프로세스 단위로 분할하고 프로세스 사이의 자료 흐름을 표시
    • 자료 사전(DD) : DFD에 나타난 자료의 내용과 속성을 정의
    • 소단위 명세서(Mini-spec) : 더이상 분할 할 수 없는 최하위 레벨의 프로세스에 대한 상세한 처리과정을 기술
  • 구조적 분석에 가장 중요한 모형화 도구
    • 시스템의 기능을 자료로 변환하는 처리와 처리를 자료의 흐름으로 연결한 네트워크형 구조로 모델링
    • 비즈니스 프로세스를 하위 프로세스로 쉽게 분해할 수 있어 매우 유용 = 하향식 분할
    • 작성 산출물
      • 배경도 (context diagram)
      • 여러 단계 분할된 DFD
      • 데이터 사전
  • DFD 구성요소

 

 
 

[6.1.1] DFD - 프로세스

  • 데이터가 변형/저장/분배 되기 위해 데이터에 수행되는 작업 또는 행위
    • 프로세스는 입력 데이터를 출력 데이터로 변환
    • 프로세스가 수작업이든 컴퓨터에 의해 수행되든 문제가 되지 않는다.
    • 프로세스의 이름과 함께 고유번호를 표현한다. (단계와 출처를 알 수 있다.)

 

 
 

[6.1.2] DFD - 자료흐름

  • 자료흐름은 변형되어 이동중인 자료군을 표현한다.
    • 시스템 내에서 한곳에서 다른 곳으로 이동하고 움직이는 데이터를 기술한다.
    • 이동방향을 화살표로 나타내고 그 위에 이름을 붙인다.
    • 자료의 내용과 형식 등은 자료사전에 명시한다. (DFD에는 표기하지 않는다.)

 
 

[6.1.3] DFD - 자료저장소

  • 머물고 있는 데이터를 표현한다.
    • 파일 폴더, 컴퓨터 기반 파일, 노트북과 같은 상이한 물리적 장소를 의미한다.
    • 데이터의 조작을 위한 물리적 구성은 중요하지 않다.

 

 
 

[6.1.4] DFD - 단말

  • 시스템 밖에서 의사 전달하는 사람, 부서 또는 다른 시스템
    • 데이터의 기원과 목적지를 기술하므로 source 또는 sink라고도 한다.
    • 단말들 사이에 자료흐름이 나타나면 안된다.

 

 
 

[7] DFD 작성 절차

  1. 배경도 작성
    • 개발하려는 시스템과 외부세계와의 인터페이스를 식별
    • 시스템 분석의 범위를 설정 (주고 받을 데이터 단말 지정)
  2. 단계적 분할
    • 중간 단계의 DFD : DFD 내의 하나 이상의 프로세스가 하위 DFD로 분할한다.
    • 최하위 단계의 DFD : DFD 내의 모든 프로세스가 더이상 분할되지 않는다.

 

 
 

[7.1] 배경도

  • 배경도(최상위 DFD) 작성
    • 시스템 경계의 입출력 식별
    • 시스템 분석의 범위를 결정
    • 시스템 전체를 나타내는 하나의 프로세스(우리의 개발 목표인 SW)와 관련된 단말들 표시

 

 
 

[7.2] DFD 분해

  • 배경도의 프로세스를 여러 하위 프로세스들로 구체화
  • 자료원과 도착지를 나타낼 필요는 없다. (옵션)

  • 최하위 DFD : 상위레벨 DFD의 프로세스 구체화
  • A를 분할하게 되면 B와 C도 분할이 될텐데 A, B, C를 다 연결하여 그려주면 level 2가 된다.

 

 
 

[7.3] DFD 작성지침

  • 모든 DFD에 적용되는 기본 규칙
    • 프로세스로 들어가는 입력은 그 프로세스로부터 나오는 출력과는 다르다.
    • 자료흐름은 프로세스를 거쳐 변환될 때마다 새로운 이름을 부여
    • DFD 상의 객체는 유일한 명칭을 가진다 (프로세스, 데이터 모두)

  • 프로세스
    • 출력만 있는 프로세스와 입력만 있는 프로세스는 작성하지 않는다.
    • 프로세스는 동사구를 사용해 명명한다.
    • 두 개의 동사가 필요하다면 처리를 분할해야 한다. 최하위 프로세스는 1가지 일만 한다.
    • 어떤 경우에도 적용되는 포괄적인 명칭은 피해야 한다.
  • 자료저장소 : 관련 데이터를 모아두는 곳
    1. 데이터는 한 자료 저장소에서 다른 자료 저장소로 직접 이동할 수 없음, 반드시 프로세스를 거쳐야 한다.
    2. 데이터는 외부 소스에서 자료저장소로 또는 자로저장소에서 외부 싱크로 직접 이동할 수 없다.
    3. 입력만 되는 자료저장소 (black hole)와 출력만 되는 자료저장소 (white hole)은 없어야 한다.

  • 자료흐름
    • 기호 사이에 오직 한 방향의 흐름만 가진다.
    • 데이터흐름은 한 번 지나간 동일한 프로세스로 직접적인 역행이 불가능
    • 자료저장소로 향하는 자료흐름은 쓰기를 의미, 자료저장소에서 나오는 자료흐름은 읽기를 의미
    • 데이터흐름의 분기와 결합 
      • 동일한 위치에서 정확히 같은 데이터가 둘 이상의 다른 프로세스, 데이터저장소, 또는 소스/싱크로 이동으로 분기

 

 
 

[7.4] DFD 분할 규칙

  • 기능적 분해 (functional decomposition)
    • 기능 중심
    • 하나의 시스템으로부터 많은 구성 프로세스들로 분리하는 행동
    • 반복적인 절차
  • 레벨 n 다이어그램
    • 배경도에서 n번의 연속된 하부 프로세스 분할 결과 생성된 DFD
    • level n DFD라고 불린다.
  • 자료흐름의 균형
    • DFD를 분해할 때 하위 레벨에서 프로세스로의 입력과 출력은 보존되어야 한다는 법칙
    • terminal과 자료는 그대로여야 한다.
    • 프로세스만 작게 분할되어 나타나야 한다.

 

 
 

[8] 논리 모델링

  • DFD는 자료의 흐름을 나타냄, 프로세스 내부의 논리를 보여주지 않는다.
    • 중간은 상관없지만, 마지막에는 어떤 처리를 통해 결과가 나오는지 알아야 한다.
  • 논리 모델링은 내부 구조 표현과 DFD에 표현된 프로세스의 기능을 포함한다.
  • 논리 모델링
    • 소단위 명세서를 작성하는 방법
    • 구조적 언어, 의사 결정 테이블, 선행/선후 조건 표시
  • 구조적 언어 : 알고리즘처럼 if/then을 사용해 표현한다, 주로 사용한다.
  • 선행/선후 조건 표시 : 프로세스 시작 전/처리 후에 필요한 조건을 표현, 프로세스가 단순할 때 사용한다.
  • 의사결정 테이블
    • 분석 단계에서 많이 사용하는 것
    • 주로 사용
    • 의사결정하는 경우의 수가 많을 때 사용
    • 의사결정 논리를 행렬과 같은 테이블로 표현
    • 가능한 조건들과 결과적인 행위들 규정
    • 복잡한 의사결정 논리에 적합
    • 테스트 케이스 작성에도 사용
    • 간단하지만 표현력이 좋음
  • 3 부분으로 구성
    • 조건부(condition stubs) : 의사결정에 유의한 조건들을 나열
    • 행동부 (action stubs) : 주어진 조건들의 집합에 대한 결과적인 행동
    • 규칙 (rules) : 주어진 조건들의 집합에 대해 어떠한 행동들이 수반되어야 하는지 규정, 조건에 따라 행동을 어떻게 해야 하는지 표현하는 것
    • 조건에 따른 행동을 규칙에 따라 표현한 테이블
  • 의사결정 테이블을 구성하는 표준 절차
    • 각각의 조건이 가정할 수 있는 조건과 값의 이름 붙이기
    • 발생 가능한 모든 행동에 이름 붙이기
    • 모든 가능한 규칙을 나열
    • 각각의 규칙을 위한 행동을 정의
    • 의사결정 테이블을 간단하게 하기 (마지막 단계)

 

 
 

[9] 자료사전

  • Data Dictionary = DD
  • 시스템 분석의 중요한 요소
  • 사용자가 이해하지 못하는 어휘들을 찾아 볼 수 있는 사전과 같은 기능
  • DFD에 기술된 모든 자료에 대해 다음 사항들을 정의
    • 자료흐름을 구성하는 자료항목 정의 → 데이터를 구성하는 항목
    • 자료에 대한 의미 정의 → 데이터가 의미하는 것 (Ex.학번의 규칙)
    • 자료저장소를 구성하는 자료항목 정의  → 자료들이 모여 있는 규칙(연관성)
    • 자료원소의 단위 및 값 정의 → (Ex. 몇 자리, 소수 점 아래, 몸무게 단위, 값의 범위 등)
  • 자료의 하향식 분할
    • 어떤 항목에 대한 정의는 구성요소들의 결합형태로 표시
    • 구성요소가 더 이상 세분화되지 않을 때까지 하향식 분할
    • 계단식
  • 자료흐름의 표현
    • 단순할 때 : "A = A11 + A12 + A21 + A22 + A31 + A32" 처럼 나열
    • 복잡할 때 계단식/하향식으로 표현

 

 

 
 

[9.1] 자료사전 표기법

  • 자료사전에 사용되는 기호
기호 (Symbol) 의미 (Meaning)
= 정의 (is composed of)
+ 구성 (and, along with)
{ } 반복 (iteration of)
[ ]  택일 (choose only one of)
( ) 생략가능 (optional)
* * 주석(comment) (의미 설명 시)
  • '정의' 작성법
    • 주석(* *)을 사용해 의미 기술
    • 자료흐름과 자료저장소에 대한 구성내역 설명
    • 자료원소에 대해 값이나 단위를 나타낸다.

  • '반복 작성법'
    • 여러 번 반복되는 자료항목은 { } 안에 기술
    • { }의 좌측에는 최소 반복횟수를 기록하고, 우측에는 최대 반복횟수를 기록
    • 반복횟수를 기록하지 않을 때는 디폴트로 최소는 0, 최대는 무한대를 나타냄 (생략 가능)

  • '선택'과 '생략가능' 작성법
    • 선택기호 [ | ] : | 로 분리된 항목들 중 하나가 선택되었다는 것을 표시
    • 생략 가능 기호( ) : 괄호 안의 자료항목이 기술될 수도, 생략될 수도 있음을 표시

  • '자료원소' 작성법
    • 자료원소는 더 이상 분할되지 않는 자료항목으로 특정한 값이나 값의 범위를 취함

 

 
 

[9.2] 자료사전 작성원칙

  • 자료의 의미 기술
    • 자료의 의미는 주석을 통해서 기술
    • 중복이 없어야 간결하고 이해하기 쉬운 자료사전
    • 중복 기술 회피 방법
      • 자료의 구성 내역을 설명하지 않는다.
      • 구성항목의 의미나 자료의 이름을 반복 설명하지 않는다.

  • 자료 구성항목의 기술
    • 구성항목을 그룹으로 묶음 
    • 각 그룹에 대해 의미 있는 이름을 부여
    • 이름이 붙여진 각 그룹을 다시 정의
    • 보기에 깔끔

  • 동의어(Alias)
    • 자료사전에 이미 정의된 자료항목에 대한 또 다른 이름
    • 동의어가 많아지면 자료의 명칭에 혼동이 생길 우려가 있음
    • 흔히 쓰는 단어 때문에 발생 가능
    • 동의어 확인이 중요

저작자표시 (새창열림)