요구분석
SW개발의 목적 -개발된 SW의 고객 만족 -고객 만족을 위한 특성 -적시성: 빠른 출시를 통한 시장의 점유 -유연성: 다양한 환경에서의 적응성 -통합: 기존 시스템과의 쉬운 통합 -고객만족의
iskull-dev.tistory.com
모델: 어떤 복잡한 대상의 핵심 특징만 선별해 일정한 관점으로 단순화 시켜 기호나 그림 등을 사용해 체계적으로 표현하는 것
모델의 필요성: 직관성
소프트웨어 개발에서의 모델:
-여러 설계 도면을 보고 선물을 시공하듯이 SW개발 시에도 여러 관점의 모델 사용
-UML의 다양한 다이어그램을 통해 소프트웨어의 범위나 개략적인 구조와 기능을 이해
-장점: 개발될 소프트웨어에 대한 이해도 향상, 이해 당사자 간의 의사소통 향상, 유지보수 용이
-단점: 과도한 문서 작업으로 인한 일정 지연 가능성, 형식적인 산출물로 전락할 가능성
모델링
-모델을 제작하는 과정 또는 작업
-현실 세계를 단순화하여 표현하는 기법
-모델링 언어: 애매한 표현 등의 문제점 해결을 위해 모델링을 할때 사용하는 기호, 표기법, 도구
-개발 방법론에 따른 모델링
-구조적 방법론:
DFD(Date Flow Diagram)
DD(Date Dictionary), 프로세스 명세
-정보공학 방법론:
ERD(Entity-Relationship Diagram): DB에 저장할 데이터를 개체와 관계를 중심으로 작성
-객체지향 방법론: UML표기법
Usecase:
. -목적 달성을 위해 엑터가 시스템을 사용하는 텍스트 형식의 스토리
-유스케이스 다이어그램에서의 표현: 원
-액터:
-시스템을 사용하는 사람이나 시스템
-시스템 엑터
-본 시스템과 데이터를 주고 받는 등 서로 연동되는 또 다른 시스템
-해당 프로젝트의 개발 범위에 속하지 않고 이미 다른 프로젝트에서 개발된 시스템
-통상적으로 시스템 경계를 두고 시스템 경계 안에는 시스템이, 밖에는 엑터가 존재한다.
요구 분석 명에의 정의
-요구 분석 돠정의 최종 산출물로 사용자와 개발자를 연결시키는 중요한 문서
-설계 및 구현에서 참조할사항, 전반적으로 알아야 할 사항을 포함하는 문서
-사용자와 개발자 간의 계약서
이해 당사자 관점의 요구 분석 명세서
-사용자 입장
-사용자와 의사 소통하는 도구로 사용되면서 동시에 계약서로도 사용
-개발이 완료시 판단 기준으로 사용
-개발된 SW수용 여부 결정에 사용
-개발자 입장
-요구 분석 명세서를 읽고 어떤 시스템이 개발될 것인지 이해하는데 사용
-요구 분석 명세서에 기술된 기능적/비기능적 요구 사항을 기반으로 분석, 설계, 코딩
-개발이 완료 후 요구 분석 명세서 대로 구현되었는지 점검 항목으로 사용
-사용자 지침서 지침시 초안 작성용으로 사용
-테스터 입장
-테스트 케이스 생성 및 오류에 대한 판단과 동작에 대한 기준으로 사용
요구분석 명세서 작성 시 주의 사항
-사용자가 읽기 쉽고, 이해할 수 있도록 작성
-개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성
-비기능적 요구를 명혹히 작성
-테스트 기준 용도로 사용할 수 있도록 원하는 기능과 품질을 가능하면 정량적으로 작성
-품질에 대한 우선순위를 명시: 상충 관계(trade-off)시 품질 우선 순위를 정할 것
잘 만든 요구 분석 명에서의 특성
-완전성:
기능적 요구사항 뿐만 아니라 성능, 제약 사항 등 누락되지 않고 모두 서술되야 한다.
일반적이고 정상적인 요구 사항이 아닌 예외처리 처럼 아주 드물게 발생하는 요구 사항도 존재. 주의 필요
-명확성
요구 분석 명세서: 계약서와 같은 효력 발생: 문제 발생 시 근거 자료로 활용
애매하지 않은 명확한 표현으로 작성: 관점에 따라 다른 해석 불가하도록 작성
-일관성
서로 상반된 요구, 불일치한 요구, 중복된 요구가 존재
-변경 용이성
변경하기 쉽게 요구 분석 명세서를 작성하는 것
방법: 요구 사항이 서로 의존적이지 않고 독립적으로 서술되야 한다.
-검증 가능성
방법: 시스템 요수 사항을 만족하는지에 대해 체계적으로 검사할 수 있게 작성
-추적 가능성
추적이 가능하도록 요구 분석 명에서를 작성하는 것
요구 명세 기법
-비정형 명세 기법
-자연어, 다이어그램 사용
- 특별하 기술이 필요 없어 작성하기 쉽다.
- 쉬운 이해 -> 용이한 의사 전달 ->사용자의 적극적 참여 유도
- 자연어 사용 -> 애매한 표현 -> 다른 해석 가능 -> 일관성 떨어짐
-정형 명세 기법
-z정형 명세 언어
- 정확하고 간결한 표현 -> 증명 기술을 이용한 일관성/완전성 검증
-정형화된 형태의 명세 -> 테케 생성 용이
- 수학적 표기법 공부 -> 표기법을 이용한 정확한 표현
요구사항 검증: 위의 잘 만들어진 요구분석 명세서의 특징이 포함되어있는지 검증