[2021년 정보시스템감리사][소프트웨어공학] 37번

37. 다음에서 설명하는 요구사항 도출 기법으로 가장 적절한 것은?

사용자들의 동작 프로세스를 이해하고 이를 지원하는 소프트웨어의 요구사항을 얻기 위해 사용하는 관찰 기법이다. 분석가는 사용자의 일상 업무를 관찰하고 사용자들의 실제 작업을 기록한다. 사람들이 실제 일하는 방식을 반영하는 기법으로 잘 드러나지 않는 요구사항을 발견하는데 도움을 준다.

① 인터뷰(interview)

② 사용자 스토리(user story)

③ 문화기술적 연구(ethnography)

④ 스프린트 백로그(sprint backlog)

[해설]

▣ 요구공학 프로세스

 - 요구사항 도출 ⇨ 요구사항 명세 ⇨ 요구사항 검증 3단계 프로세스로 구성

 

▣ 요구사항 도출(Requirements Elicitation)

구분	설명
인터뷰	l 사람들이 무엇을 하는지에 대해 이야기를 나눈다.
관찰 또는 문화기술적 연구(ethnography)	l 일을 하는 사람들의 모습을 지켜보고 사람들이 무엇을 사용하는지, 어떻게 사용하는지 등을 살핀다. l 동작 프로세스를 이해하고, 이 프로세스를 지원하는 소프트웨어에 대한 요구사항을 얻기 위해 사용하는 관찰 기법 l 다른 요구사항 도출 기법으로는 놓치기 쉬운 중요한 프로세스의 상세한 내용을 찾을 수 있음 l 하지만, 최종 사용자에 집중하기 때문에 광범위한 조직이나 도메인 요구사항 또는 혁신을 위한 제안들을 발견하기에는 효과적이지 않음
사용자 스토리(Stories)	l 애자일 기법에서 사용하는 사용자 스토리는 실제로는 요구사항을 도출하는 데 도움을 주는 일반적 스토리보다는 대화식 시나리오에 가깝다.
시나리오(Scenarios)	l 시나리오 도출 과정 동안 상세한 내용들을 추가함으로써 보다 완전한 형태의 상호작용을 작성한다

 

▣ 요구사항 명세화(Requirements Specification)

-      시스템 요구사항을 작성하기 위한 표기법(Notation)

구분	설명
자연어 문장	l 요구사항을 작성할 때 번호를 붙인 자연어 문장으로 작성한다. l 각 문장은 하나의 요구사항을 나타내야 한다.
구조적 자연어	l 표준 양식이나 템플릿에 따라 자연어로 요구사항을 작성한다. l 각각의 필드는 요구사항의 한 양상에 대한 정보를 제공한다.
그래픽 표현	l 문자 표기법으로 보충한 그래픽 모델로 시스템의 기능적 요구사항을 정의한다. l UML(Unified Modeling Language) 유스케이스 다이어그램과 시퀀스 다이어그램을 사용한다.
수학적 명세	l 이 표기법은 유한-상태 머신이나 집합 같은 수학적 개념에 기반하고 있다. l 이러한 분명한 명세는 요구사항 문서의 모호성을 줄여줄 수 있지만, 고객들은 대부분 정형적 명세를 이해하지 못한다. l 고객들은 그 정형적 명세가 원하는 바를 표현하고 있는지 확인하지 못하기 때문에 그 내용을 시스템 계약으로 채택하는 데 주저하게 된다.

 

▣ 요구사항 검증(Requirements Validation)

-      요구사항이 고객이 원하는 시스템을 제대로 정의하고 있는지를 점검하는 과정

-      요구사항 점검(checking)

구분	설명
유효성 점검	l 요구사항이 시스템 사용자의 실제 요구를 반영하는지를 점검
일관성 점검	l 명세서상의 요구사항은 서로 상충되지 않아야 함
완전성 점검	l 요구사항명세서는 시스템 사용자가 의도한 모든 기능과 제약을 정의하는 요구사항을 포함해야 함
실현성 점검	l 기존 기술의 지식을 사용해서 시스템에 대한 주어진 예산으로 실제로 구현이 가능한지를 점검
검증가능성	l 고객과 계약자 사이의 분쟁 가능성을 줄이기 위해, 시스템 요구사항은 문서로 작성해서 검증 가능해야 함

 

▣ 요구사항 변경(Requirements Change)

-      대규모 소프트웨어 시스템에 대한 요구사항은 항상 바뀜

-      시스템을 설치하고 주기적으로 사용하기 시작하면, 새로운 요구사항이 나타날 수 밖에 없음

-      시스템 요구사항에 대한 대부분의 변경은 시스템에 대한 비즈니스 환경 변화 때문에 발생