Post

[소프트웨어 공학] Requirements (요구사항)

Posted Updated
By Keem
13 min read

1. 요구 사항 (Requirements)

  • 무엇을 구현 해야하는 가 ( 고객의 니즈를 만족 시켜야함 )

  • 기능, 품질 특성 (성능, 보안성)
  • 개발 프로세스에 대한 제약 조건 ( 특정 언어로 작성)

※ stakeholder (이해 관계자) : 시스템 직간접적 영향을 주고 받는 그룹 - 이들을 통해 요구사항 도출

1. 요구사항 단계

  • Business requirements - 프로젝트 스폰서
    • why? 왜 프로젝트를 수행하는가?
  • User requirements - 사용자
    • 시스템을 통해 달성하려는 목표나 수행하는 업무
  • Solution requirements - 개발자
    • 니즈 만족을 위해 구현해야 하는 것

※위로 올라갈 수록 추상적인 의미

1.1 Business requirements

  • 시스템을 구현하는 이유 (이윤 증가, 비용 절감, 이윤 방어, 미래 소요 비용 절감)

  • 이득을 얻을 수 있도록 시스템을 통해 달성해야 하는 목표

※ 카페테리아 예시 목표 - 음식 낭비 비용 감소, 운영 비용 감소 등)

1.2 User requirements

  • 가치를 제공 받기 위해 시스템을 통해 달성하고자 하는 목표나 수행하는 태스크
  • 요구사항 달성을 위한 요구사항 도출

※ 식사 주문, 메뉴 생성, 급요 공제 등록

1.3 Solution requirements

functional requirements

  • 요구 사항을 달성할 수 있도록 개발자가 구현하는 것

※ 고객 급여 공제 등록 여부 확인, 고객이 선택한 날짜에 가능한 메뉴, 결제 금액 계산

non functional requirements

  • 사용성, 성능, 가용성, 보안, 안정성, 견고성

data requirements

  • 시스템이 조작하는 데이터 개체 및 데이터 개체 간의 관계 정의

2. 외부 인터페이스 요구 사항

  • User Interface 요구사항
  • Hardware Interface 요구사항 (센서)
  • Software Interface 요구사항
  • Communications interface 요구사항 (통신 기능, 이메일, 문자)

2.1 User Interface 요구사항

  • 웹 적합성 : 신체적, 환경적 조건에 관계 없이 사용
  • 웹 호환성 : OS, 브라우저에 상관없이 유사한 화면으로 동일한 정보 접근

2.2 Hardware Interface 요구사항

  • 외부 하드웨어 장비 (센서, 바코드 인식기 등)
  • SW <-> HW간의 상호작용

※ SRS - Software Requirements Specification

TBD - To Be Determined / N/A - Not Applicable / None

2.3 Software Interface 요구사항

  • 데이터 베이스, 외부 라이브러리, 도구, 운영체제, 외부 소프트웨어 시스템과의 통신에 관한 인터페이스 요구사항

2.4 Communications interface 요구사항 (통신 기능, 이메일, 문자)

  • 시스템에 필요한 이메일 등 통신 기능과 관련된 요구 사항 기술
  • 통신 보안, 암호화 문제, 데이터 전송 속도

3. 비즈니스 규칙과 제약

비즈니스 규칙 (Bussiness Rule)

  • 사용 운영의 특정 측면을 정의하거나 제한
  • 회사 정책, 법률, 산업표준
  • 조직은 물론 시스템도 준수해야함
  • User, Solution Requirements에 영향을 미침

※ 환불 정책 : 환불 시 영수증 제시, 30일이 지나면 마일리지로만 적립

설계 및 구현 제약 (constraints)

  • 설계나 구현 등의 행위에 가하는 제약

  • 특정 프로그램 언어 및 DB 사용

※ C++으로만 개발 or Orcale DB만 사용

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

소프트웨어 개발을 위한 요구사항 개발을 위한 활동

  • Elicitation (도출) - 요구사항 도출 (잠재적이거나 숨겨진)
  • Analysis (분석) - 요구사항 상세화, 중복 제거, 품질 평가, 우선 순위
  • 명세 - 문서화
  • 검증 - 요구사항 올바른지

1 요구사항 도출

Bussiness Analyst는 이해 관계자로부터 시스템에 바라는 요구 식별

요구사항 도출 기법

  • 인터뷰 - 직접 대화를 통해 도출
    • 친밀감, 경청 자세 중요
    • 폐쇄적 질문이 아닌 개방형 질문
    • 5 whys - 근본 원인 도출을 위함

  • 워크숍 - 이해 관계자 협업을 통해 도출

    • 다양한 요구사항 동시에 도출
    • 의견 충돌 해소 및 가능한 빨리 합의
    • 집약적인 의견 교환 가능

  • 설문 - 대규모 사용자 그룹의 요구를 위함

    • 가장 문제가 되는 영역 파악
    • 우선순위 파악 가능

  • Brainstorming - 짧은 시간에 아이디어 최대한 많이 / 집단적 창의적 발상 기법

    4S 원칙

    • 비판 금지 (Support) : 아이디어에 비판 금지
    • 자유 분방 (Silly) : 우스꽝스러운 아이디어도 환영
    • 양산 (Speed) : 아이디어가 많으면 좋음
    • 결합과 개선 (Synergy) : 여러 아이디어 결합하면 좋은 아이디어 될 수 있음

  • 관찰 - 사용자의 업무 환경 관찰하여 문제점 식별

    • 적극적 관찰 (active observation): 업무 중 질문 가능
    • 수동적 관찰 (passive observation): 업무 중 방해 금지
  • 문서 분석
    • 기술문서, 문제점 보고서 등을 분석

3. 요구사항 분석

  • 추상적인 요구사항을 분해하고 정제

  • 더 중요한 요구사항 파악
  • 요구 사항 모델링을 통해 더 구체화, 가시화 되어 시스템에 대한 이해도가 크게 향상되며 개발에 필요한 정보 제공
  • 모델링
    • 구조적 분석 (Data Flow Diagram)
    • 유스케이스 분석 모델링 (UML)
    • 사용자 스토리
    • ERD (Entity Relation Diagram)
    • State Transition Diagram
    • Dialogue Map

요구 사항 품질 테스트

  • Necessary - 필요한지?

    • Gold Plating 방지 - 개발자가 이득이 된다고 생각하여 장식적인 기능 추가

    • 신규 가입자에게 할인 혜택 제공

      • 신규 가입자에게 7% 할인 쿠폰 제공
      • 최근 구매 실적 없는 사람에게 할인 정보 제공

  • Implementation Free

    • 요구사항에 불필요한 설계 및 제약이 포함되면 안된다

  • Unambiguous

    • 요구사항은 하나 이상의 의미로 해석되면 안됨

  • Complete

    • 각 요구 사항을 이해하는데 필요한 모든 정보를 가지고 있어야 하며 발생할 수 있는 모든 조건에 대해 기술해야 한다.
    • 교수는 사용자 ID, 비번 및 관련된 정보를 이용하여 로그인이 가능하다

  • Atomic

    • 각 요구사항은 여러 요구사항으로 분리되지 않아야 함
    • 항공권, 호텔 예약 -> 항공권 예약, 호텔 예약

  • Feasible (실형 가능성)

    • 요구사항은 비용 일정 같은 제약 내에서 기술적으로 실행 가능해야함

  • Traceable (추적 가능)

    • 요구사항 소스 및 요구사항으로부터 파생된 다른 시스템 구성 요소(설계 코드) 등과 연결되어야 함
    • RTM (requirements Traceability Matrix)
      • 테스트 케이스와 함께 사용자 요구사항 매핑하고 추적하는 문서

  • Verifiable - (Atm 예시 참조)

    • 요구 사항은 검증 가능하여야함

    • 품질 속성 템플릿

      • 소스 (Source) : 자극을 생성하는 개체

      • 자극 (stinulus) : 시스템에 영향을 주는 조건

      • 대상 또는 산출물 (artifact) : 자극에 의해 영향을 받는 시스템

      • 환경 (environments) : 자극이 발생된 상황

      • 반응 (response) : 자극으로 야기되는 시스템 행위

      • 반응 척도 (mesure) : 시스템 반응을 평가하는 척도

  • Consistent

    • 다른 요구사항과 모순 X 동일한 개념 다른 용어를 사용하여 기술 X

      시스템은 Paypal결제 수단으로

      시스템은 결제 수단으로

  • NonRedundant

    • 요구사항은 중복되면 안된다

4. 요구사항 명세

  • 분석된 요구사항 명확, 완전하게 기록
  • 시스템이 수행할 모든 기능, 구현상 제약 조건, 개발자와 사용자가 합의한 성능에 대한 내용 등
  • 최종 결과물 : 요구사항 명세서 (SRS : Software Requirement Specification)

※ SRS 국제 표준 IEEE-STD-830

4.1 SRS (Software Requirement Specification)

Purpose (목적)

  • 무엇을 위해 문서를 작성한 것인지 설명 (문서의 목적 기술)

​ ※ 용도 나열 금지

Scope (범위)

  • 개발할 소프트웨어에 대한 설명

Product Perspective (제품 조망)

  • 제품을 외부에서 바라본 모습
  • 기존 제품 대체인지 차기 버전인지
  • 시스템의 일부라면 큰 시스템과의 인터페이스 기술
  • 다이어그램으로 제품과 외부와의 관계를 보여줄 수 있음

User Characteristice

  • 이 제품을 사용할 것으로 예상되는 사용자 식별 및 그들의 특징 기술

Constraints (제약 사항)

  • 반드시 사용하거나 피해야하는 기술
  • 사용자 웹 브라우저 유형이나 버전

Assumption and Dependencies (가정 및 의존성)

  • 프로젝트를 위해 필요하거나 결정되어야 할 전제 조건 또는 선행되어야 할 사항
  • 가정이나 의존성 문제 발생 시 프로젝트가 위험
소프트웨어 공학, 정리
software engineering
This post is licensed under CC BY 4.0 by the author.