요구분석

요구사항

• 소프트웨어 개발에서의 정의는 '사용자와 개발자가 합의한 범위 내에서 사용자가 필요로 하는 기능' 시스템이 제공하는 기능 요구와 품질과 같은 비기능 요구로 나뉜다.
• 요구사항이 정확히 무엇인지 파악하는 작업은 요구분석 단계에서 이루어진다.

요구분석

• 정의는 시스템이나 소프트웨어의 요구사항을 정의하기 위해 사용자 요구사항을 조사하고 확인하는 과정
• 목적은 사용자에게서 필요한 요구사항을 추출해 목표하는 시스템의 모델을 만들고 요구분석명세서를 작성하기 위함이다.
• 요구분석명세서는 요구 분석 단게에서 생성되는 최종 산출물로 시스템의 기능이 무엇인지에만 초첨을 두고 정리한다.
• 요구분석 단계 후 설계 단계에서는 설계서가 만들어지는데 이 문서는 어떻게 구현할지 기술한다.

요구분석의 어려움

• 사용자와 분석가의 의사소통 문제
• 사용자의 계속되는 요구사항 추가
• 사용자의 모호한 요구사항

요구사항 수집

• 자료 수집 : 현행 시스템에서 모든 업무의 입,출력 관련 기본 기능 분석, 현행 시스템의 문제와 개선점 추가될 요구사항을 파악
• 인터뷰 : 자료를 수집한 후 정리해 분서 결과를 바탕으로 각 부서 담당자를 인터뷰하는게 효율적이다.
• 설문 조사 : 설문 문항을 잘 만드는 것이 중요하다.

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

요구 분석 절차

1. 자료 수집 : 현행 시스템의 문제점 도출, 실무 담당자 인터뷰, 현재 사용하는 문서 컴토 등을 통해 모든 자료 수집
2. 요구사항 도출 : 수집한 자료를 정리해 적절히 분류하고 개발에 반영할 요구사항을 도출
3. 문서화 : 도출한 요구사항을 요구분석명세서로 작성
4. 검증 : 요구분석명세서에 사용자 요구가 정확히 기록되어 서로 모순되는 상황은 없는지, 빠뜨리지 않고 전부 기록했는지 등을 점검

요구 분석 분류

요구사항 분류는 아래 이미지와 같다.

요구사항 분류

기능 요구사항

• 사용자가 시스템을 통해 기능을 제공받기 바라며 시스템은 사용자가 필요한, 원하는 기능을 제공한다.
• 사용자가 원하는 기능은 요구분석명세서에 완전하고 일관성 있게 표현해야 하며 시스템에도 전부 반영한다.
• 완전성과 일관성을 파악해야 한다. 완전성은 사용자가 원하는 기능이 모두 포함되었는지, 일관성은 요구사항에 모순이 있어서는 안된다.

비기능 요구사항

• 수행 가능한 환경, 품질, 제약사항 등을 말한다.
• 비기능 요구사항이 매우 중요한 소프트웨어는 군사 무기나 의료 장비 등이 해당한다.
• 제약사항 : 개발 소프트웨어가 수행될 환경에 의한 조건
• 신뢰성 : 소프트웨어에서의 신뢰성은 신뢰도로 나타내며 장애 없이 동작하는 시간의 비율로 나타낸다.
  1000번 수행했을 때 오류없이 동작하는 횟수가 999번인 경우 : 99.9%
  신뢰도 높은 소프트웨어의 조건은 시스템에 오류가 있더라도 장애가 발생하지 않고 회피할 수 있는 능력이 있어야 한다.
  장애가 발생해도 이전 수준으로 회복이 가능하며, 장애로 영향을 받은 데이터들이 정상적으로 복귀되어야 한다.
• 가용성 : 소프트웨어가 총 운용 시간 동안 얼마나 정상적으로 고장 없이 가동되었는지를 비율로 나타낸다.
• MBTF : 평균 정상 작동 시간 또는 고장 간 평균 시간
• MTTR : 평균 수리 시간

가용성 계싼

요구사항의 표현

표현을 위해 사용하는 악보나 수학 공식은 하나의 모델이다

소프트웨어 개발 모델

• 건축에 여러 도면이 필요하듯이 소프트웨어를 개발할 때도 여러 종류의 모델이 필요하다.
• 객체지향 개발에서는 UML의 다양한 다이어그램을 통해 개발 소프트웨어의 범위나 개략적인 구조와 기능을 이해할 수 있다.
• UML의 수많은 다이어그램이 소프트웨어 개발 과정에서 하나의 모델로 사용

소프트웨어 개발 모델 사용의 장단점

• 장점
  • 이해도 향상
  • 유지보수 용이
• 단점
  • 과도한 문서 작업으로 일정 지연
  • 형식적인 산출물로 전략할 가능성이 있다.

모델링

앞서 설명한 모델을 제작하는 것이 모델링이다.

모델링에는 다양한 방법이 있다.

• 자연어를 사용한 표현
• 형식 언어를 사용한 표현 : 표기법을 별도로 공부하므로 일반 개발자가 사용하기는 어려운 편. 문법과 의미가 수학을 기초로 작성됨. 간결하고 정확하게 표현 가능. 관계형 포기법, 상태 위주 표기법 등이 있다.
• UML 다이어그램을 사용한 표현

모델링 언어

• 모호한 표현의 문제를 해결하기 위해 사용하는 기호, 표현법, 도구다.
• 악보 기호, 수학 기호 등과 UML 다이어그램과 같은 형식적 표기법 등

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

• 요구사항 정의 및 분석, 설계의 결과물을 다양한 다이어그램으로 표현하는 표기법
• 모호한 표현이 없고 일관되어 모델링을 하는 데 매우 유용하다.
• 개발자 간에 원할하게 의사소통할 수 있고 시스템을 주관적으로 해석하는 일도 줄어든다.
• 다양한 다이어그램을 사용하므로 시스템을 여러 시각으로 볼 수 있다.
• 사용자 요구사항을 검증하는 의사소통 도구로도 사용한다.

개발 방법에 따른 모델링 언어

• 구조적 방법 : 자료 흐름도(DFD), 자료 사전(DD), 소단위명세서를 사용해 요구분석 결과를 표현
• 정보공학 방법 : E - R 다이어그램을 DB 설계 표현으로 사용
• 객체지향 방법 : UML 표기법을 사용. 특히 요구사항은 유스케이스 다이어그램을 사용해 표현한다.

구조적 방법의 표현 도구 : DFD

자료 흐름도(DFD) : 들어온 자료를 처리한 후 결과를 내보내는 과정을 나타낸 것이다.

DFD 작성 단계

1. DFD를 작성할 때는 먼저 필요한 기능이 무엇인지 찾아내야 한다.
2. 입력과 출력 자료 표현
3. 자료 저장소 표현
4. 자료 출원지와 목적지 표현

아래 예시를 통해 더 확실하게 이해가 가능하다.

DFD 작성 예시

자료 사전 : DD

DFD에 존재하는 데이터에 대한 자세한 설명을 기록해 놓은 것이 DD다.

자료 사전은 몇 가지 기호를 사용해 자료를 정의한다.

자료 사전의 기호

소단위 명세서

소단위명세서는 DFD에서 원으로 표시한 프로세스인 처리는 실제 알고리즘 형태로 작성한 것이다.

소단위명세서를 작성하는 도구에는 구조적 언어, 선후 조건문, 의사 결정표 등이 있다.

소단위명세서 작성의 예

유스케이스 다이어그램 작성하기

1. 후보 유스케이스 도출
2. 후보 유스케이스 검토 / 유스케이스 특성 확인 및 통합
3. 유스케이스 정련

유스케이스 다이어그램에 대한 더 자세한 내용은 아래 링크에서 확인할 수 있다.

https://devdebin.tistory.com/136?category=1014214 

UML

유스케이스 명세서 작성하기

• 유스케이스 다이어그램을 작성하면 각각의 유스케이스에 대한 명세서를 작성해야 한다.
• 유스케이스 명세서는 7개 항목으로 구성되며 각 유스케이스의 자세한 내용을 기술하는 문서이다.

유스케이스 명세서 항목

요구사항의 문서화

소프트웨어 요구분석명세서의 정의

• 요구분석 과정의 최종 산출물로 사용자와 개발자를 연결하는 중요한 문서다.
• 설계와 구현에서 참조할 사항, 전반적으로 알아야 할 사항을 포함하는 문서다.
• 사용자와 개발자의 계약서다.

요구분석명세서 작성

• 분석가와 사용자의 배경 지식이 너무 다르기 때문에 분석가가 요구분석명세서를 작성하는 일은 어렵다.
• 완전한 요구분석명세서를 작성하려면 분석가는 형행 업무 내용을 충분히 파악한 후 사용자와 대화할 수 있도록 준비한다.
• 입출력 화면 등이 어떻게 구성되는지 사용자에게 설명하면서 사용자가 느끼는 문제점과 원하는 요구사항을 파악해야 한다.
• 분석가가 작성한 요구분석명세서는 사용자에게는 계약서, 개발자에게는 설계 및 구현을 위한 공식 문서로 사용한다.
• 소프트웨어 개발과 관련된 이해 당사자에게는 중요한 기준이 되는 문서다.

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

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

잘 만든 요구분석 명세서의 특징

• 완전성 : 기능 요구사항 뿐 아니라 성능, 제약 사항 등의 비기능 요구사항이 빠지지 않고 모두 서술되면 완전하다.
• 일관성 : 상반된 요구뿐 아니라 불일치하거나 중복된 요구가 존재하면 일관성이 없는 요구분석명세서다.
• 명확성 : 요구분석 명세서는 계약서와 같은 역할도 하므로 요구사항, 비용, 기간 등에서 문제가 발생하면 근거가 된다. 또한 잘못 해석해 의도하지 않은 결과를 초래할 수 있으므로 누구나 같은 해석을 하도록 표현을 명확히 해야 한다.
• 추적 가능성 : 추적이 가능하게 작성
• 변경 용이성 : 한 곳의 변경으로 인해 다른 곳에 미치는 영향이 작은 것을 말한다.
• 검증 가능성 : 요구분석명세서가 시스템이 요구사항을 만족하는지를 체계적으로 검사할 수 있다면 검증 가능성이 크다.

요구 명세 기법

비정형 명세 기법

• 사용자 요구를 표현할 때 자연어를 기반으로 서술하거나 작업 흐름도와 같은 다이어그램을 사용해 작성한다.
• 특별한 기술이 필요하지 않아 요구사항을 작성하기 쉽다
• 명세 내용을 이해하기 쉬워 사용자와 분석가의 의사소통이 쉽다.
• 분석하는 과정에서 사용자의 적극적인 관심과 참여를 유도할 수 있다.
• 자연어로 작성하면 표현이 모호할 수 있고, 해석을 다르게 할 수도 있다
• 일관성이 떨어질 수 있고 명세가 불충분할 수 있다.
• 작성된 내용이 사용자 요구를 충분히 반영해서 표현하고 있는지 완전성을 검증하기가 어렵다.

정형 명세 기법

• 사용자의 요구를 수학적 원리와 표기법을 이용해 표현하는 것(Z 정형 명세 언어)
• 사용자 요구를 정확하고 간결하게 표현할 수 있다
• 수학에서 사용되는 증명 기술을 이용해 작성된 사용자 요구가 일관성이 있는지, 완전한지 등을 검증할 수 있는 장점이 있다.
• 사용자 요구를 정형화된 형태로 작성함으로써 효율적으로 테스트 케이스를 생성할 수 있다.
• 이 테스트 케이스는 명세 내용과 구현의 일치 여부를 확인하는 데 사용할 수 있다.
• 수학적 원리와 표기법을 사용하려면 분석가가 관련된 수학 지식이 있어야 한다.
• 수학적 표현으로 작성된 표기법을 충분히 이해할 수 있어야 한다.
• 이 표기법을 사용해 사용자 요구를 정확히 표현할 수 있어야 한다.

요구사항 검증

• 여러 방법을 통해 추출하고 정리한 사용자의 요구분석명세서가 정확하고 안전하게 서술되었는지 검토하는 활동이다.
• 사용자 요구사항이 완전하게 서술되었는지 검증
• 요구분석명세서를 작성할 때 문서 표준을 따랐는지 확인한다.
• 설계에서 사용하기에 적합한지를 확인한다.

 

이상으로 포스팅을 4장 복습 포스팅을 마칩니다. 감사합니다.

 

참고자료

쉽게 배우는 소프트웨어 공학 2판 (4단원 요구분석)

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791156645429 

쉽게 배우는 소프트웨어 공학 - 교보문고