요구분석 - 요구사항의 표현

iskull-dev.tistory.com/123

요구분석

모델: 어떤 복잡한 대상의 핵심 특징만 선별해 일정한 관점으로 단순화 시켜 기호나 그림 등을 사용해 체계적으로 표현하는 것

모델의 필요성: 직관성

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

  -여러 설계 도면을 보고 선물을 시공하듯이 SW개발 시에도 여러 관점의 모델 사용

  -UML의 다양한 다이어그램을 통해 소프트웨어의 범위나 개략적인 구조와 기능을 이해

  -장점: 개발될 소프트웨어에 대한 이해도 향상, 이해 당사자 간의 의사소통 향상, 유지보수 용이

  -단점: 과도한 문서 작업으로 인한 일정 지연 가능성, 형식적인 산출물로 전락할 가능성

모델링

  -모델을 제작하는 과정 또는 작업

  -현실 세계를 단순화하여 표현하는 기법

  -모델링 언어: 애매한 표현 등의 문제점 해결을 위해 모델링을 할때 사용하는 기호, 표기법, 도구

  -개발 방법론에 따른 모델링

    -구조적 방법론:

         DFD(Date Flow Diagram)

         DD(Date Dictionary), 프로세스 명세

    -정보공학 방법론:

        ERD(Entity-Relationship Diagram): DB에 저장할 데이터를 개체와 관계를 중심으로 작성

    -객체지향 방법론: UML표기법

 

Usecase:

. -목적 달성을 위해 엑터가 시스템을 사용하는 텍스트 형식의 스토리

  -유스케이스 다이어그램에서의 표현: 원

  -액터:

     -시스템을 사용하는 사람이나 시스템

    -시스템 엑터

          -본 시스템과 데이터를 주고 받는 등 서로 연동되는 또 다른 시스템

          -해당 프로젝트의 개발 범위에 속하지 않고 이미 다른 프로젝트에서 개발된 시스템

          -통상적으로 시스템 경계를 두고 시스템 경계 안에는 시스템이, 밖에는 엑터가 존재한다.

요구 분석 명에의 정의

  -요구 분석 돠정의 최종 산출물로 사용자와 개발자를 연결시키는 중요한 문서

  -설계 및 구현에서 참조할사항, 전반적으로 알아야 할 사항을 포함하는 문서

  -사용자와 개발자 간의 계약서

이해 당사자 관점의 요구 분석 명세서

  -사용자 입장

    -사용자와 의사 소통하는 도구로 사용되면서 동시에 계약서로도 사용

    -개발이 완료시 판단 기준으로 사용

    -개발된 SW수용 여부 결정에 사용

  -개발자 입장

    -요구 분석 명세서를 읽고 어떤 시스템이 개발될 것인지 이해하는데 사용

    -요구 분석 명세서에 기술된 기능적/비기능적 요구 사항을 기반으로 분석, 설계, 코딩

    -개발이 완료 후 요구 분석 명세서 대로 구현되었는지 점검 항목으로 사용

    -사용자 지침서 지침시 초안 작성용으로 사용

  -테스터 입장

    -테스트 케이스 생성 및 오류에 대한 판단과 동작에 대한 기준으로 사용

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

  -사용자가 읽기 쉽고, 이해할 수 있도록 작성

  -개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성

  -비기능적 요구를 명혹히 작성

  -테스트 기준 용도로 사용할 수 있도록 원하는 기능과 품질을 가능하면 정량적으로 작성

  -품질에 대한 우선순위를 명시: 상충 관계(trade-off)시 품질 우선 순위를 정할 것

잘 만든 요구 분석 명에서의 특성

  -완전성:

    기능적 요구사항 뿐만 아니라 성능, 제약 사항 등 누락되지 않고 모두 서술되야 한다.

    일반적이고 정상적인 요구 사항이 아닌 예외처리 처럼 아주 드물게 발생하는 요구 사항도 존재. 주의 필요

  -명확성

    요구 분석 명세서: 계약서와 같은 효력 발생: 문제 발생 시 근거 자료로 활용

    애매하지 않은 명확한 표현으로 작성: 관점에 따라 다른 해석 불가하도록 작성

  -일관성

     서로 상반된 요구, 불일치한 요구, 중복된 요구가 존재

  -변경 용이성

     변경하기 쉽게 요구 분석 명세서를 작성하는 것

     방법: 요구 사항이 서로 의존적이지 않고 독립적으로 서술되야 한다.

  -검증 가능성

     방법: 시스템 요수 사항을 만족하는지에 대해 체계적으로 검사할 수 있게 작성

  -추적 가능성

    추적이 가능하도록 요구 분석 명에서를 작성하는 것

요구 명세 기법

  -비정형 명세 기법

     -자연어, 다이어그램 사용

     - 특별하 기술이 필요 없어 작성하기 쉽다.

     - 쉬운 이해 -> 용이한 의사 전달 ->사용자의 적극적 참여 유도

     - 자연어 사용 -> 애매한 표현 -> 다른 해석 가능 -> 일관성 떨어짐

 

 -정형 명세 기법

  -z정형 명세 언어

  - 정확하고 간결한 표현 -> 증명 기술을 이용한 일관성/완전성 검증

  -정형화된 형태의 명세 -> 테케 생성 용이

  - 수학적 표기법 공부 -> 표기법을 이용한 정확한 표현

요구사항 검증: 위의 잘 만들어진 요구분석 명세서의 특징이 포함되어있는지 검증