소프트웨어 공학 - [제6강] 사용자 요구 분석

소프트웨어 공학 - [제6강] 사용자 요구 분석

주요용어

• FURPS+: HP에서 정의한 요구사항 분류 모델로 F는 기능적 요구사항을 의미하며 나머지는 비기능적 요구사항인 사용성, 신뢰성, 성능, 지원성을 의미한다. +는 제약조건이다.
• 요구 공학: 시스템의 목표와 기능 및 제약 사항을 결정하는 과정으로 시스템 요구사항을 만들고 유지하기 위한 반복적 프로세스를 말한다.
• JAD: 애플리케이션 설계와 개발 과정에 고객과 사용자를 참여시키는 방법론이다. 고객과 개발자 간의 협력과 합의를 위해 워크숍을 진행한다.
• 객체지향 분석: 객체와 객체 간의 관계를 바탕으로 요구 사항을 분석하는 방법이다. 클래스 다이어그램으로 표현되는 분석 객체 모델과 상태 다이어그램이나 시퀀스 다이어그램으로 표현되는 동적 모델로 분석 과정의 결과물을 표현한다.
• 구조적 분석: 시스템의 기능을 중심으로 요구사항을 파악하는 방법으로 분할 정복과 하향식 기능 분해 방법을 이용한다.
• 시스템 모델: 시스템 명세를 문서화할 때 다양한 관점에서 시스템의 모습을 표현하기 위해 사용되는 모델을 통칭한다.
• 데이터 흐름도: 기능 관점에서 입력 데이터에 대하여 어떤 계산을 통해 결과가 나오는지 보여주기 위한 것으로 구조적 분석 방법에서 사용되는 모델이다.

요구사항

요구사항

문제 해결이나 목적 달성을 위해 사용자가 필요로 하는 조건이나 능력 또는 시스템이 갖추고 있고 지켜야 하는 조건이나 능력

‘what’에 관한 기술이며 ‘how’에 관한 기술이 아님

요구사항 분석은 요구사항을 정하고 검토하는 과정

요구사항의 문서화

요구사항 명세서는 시스템이 제공해야 하는 서비스나 제약 조건에 관해 기술한 문서로 개발과 유지보수 작업의 기초가 되는 문서

요구사항의 종류

기능적 요구사항은 기능적 결정 요인을 정의한 요구사항

기능적 요구사항의 예는 “사용자가 티켓을 구입할 수 있어야 한다.”, “사용자가 지방세 정보를 볼 수 있어야 한다.”, “제품이 판매된 후 데이터베이스가 수정되어야 한다.”

비기능적 요구사항은 제품의 품질, 서비스나 기능상의 제약, 법률이나 표준의 준수에 관한 내용을 기술한 것으로 사용성, 효율성, 성능, 저장소 용량, 입출력 장치의 성능, 보안, 신뢰도, 이식성 관련 요구사항 등과 프로세스 관련 요구사항 및 하드웨어 사용에 관한 것 등

비기능적 요구사항의 예는 “사용자에게 1초 내로 피드백이 주어져야 한다.”, “ 인터페이스 색상이 회사의 공식 색상과 일관성이 있어야 한다.”

FURPS+

HP에서 개발한 요구사항 분류 모델로, FURPS는 Functionality, Usability, Reliability,

Performance, and Supportability의 약자

F는 기능적 요구사항, URPS는 비기능적 요구사항 중 품질 요구사항이라 하며, +는 비기능적 요구사항 중 제약 사항에 관한 것

일반적으로 비기능적 요구사항이 기능적 요구사항보다 중요함

비기능적 요구사항이 만족되지 않으면 시스템을 사용하지 않을 수 있음

요구 공학 프로세스

요구 공학

• 시스템 요구사항 문서를 만들고 유지하기 위한 반복적 프로세스로 시스템의 목표와 기능 및 제약 사항을 결정
• ‘요구 분석’에 비해 반복적이고 협력적인 프로세스를 강조하고 결과의 문서화와 변화하는 요구 사항에 대한 이해를 강조한 용어
• 입력은 고객이 준비한 문제 기술서이며, 출력은 요구사항 명세서(SRS)

타당성 조사

시스템이 기관의 목적에 부합하는지, 현재의 기술과 비용으로 일정에 맞춰 개발될 수 있는지, 다른 시스템과 통합될 수 있는지 판단

요구사항 수집과 분석

• 요구사항 수집을 요구사항 추출이라고도 함
• 요구사항 수집은 시스템 분석가가 고객이나 사용자와 의사소통하여 시스템이 제공해야 하는 서비스, 요구되는 시스템의 성능 및 제약 사항 등을 찾아내는 것
• 분석가는 도메인에 관한 지식을 가지고 있어야 함
• 다양한 사람이 관련되어 있음. 시스템에 관심을 가지고 있으며 시스템에 직간접적으로 영향을 받는 사람을 관련자(stakeholder)라 함
• 요구사항 수집 → 요구사항의 분류 → 요구사항들 간의 충돌 해결 → 우선 순위 매기기

요구사항 추출과 분석의 어려운 점

• 정확히 표현하지 못하거나 비현실적인 요구를 함
• 각자의 환경에 익숙한 표현을 사용함
• 다양한 관점에서 서로 다른 요구사항을 하기도 함
• 주변 상황이 바뀌면 요구사항 분석 중에 요구사항이 바뀔 수 있음

JAD(Joint Application Design)

애플리케이션의 설계와 개발 과정에 고객과 사용자를 참여시키는 방법

모든 관련자들이 참여하는 JAD 세션(워크숍)에서 요구사항을 추출함

3~5일 정도의 회의를 진행함

최종 JAD 문서는 합의된 요구사항 명세서임

절차

1. 조사 단계: JAD 진행자가 인터뷰를 통해 프로젝트의 목적과 범위를 정함
2. 준비 단계: 고객, 관리자, 시스템 분석가, 응용 분야 전문가 등으로 구성되는 JAD 팀을 정함
3. 회의: 회의를 통해 시나리오, 유스케이스, 사용자 인터페이스 모델을 정의
4. 최종 문서 작업: 회의 중에 합의된 내용을 명세화하여 최종 문서를 만들고, 배포하여 검토함

고려 사항

협력 작업을 통해 참석자들 간의 의사소통을 증진시키고 빠른 합의를 이끄는 방법. 개발자는 사용자를, 사용자는 개발 작업의 문제를 이해하게 됨

JAD 진행자의 역량이 중요

요구사항 문서화

사용자 요구사항

시스템의 고객이나 사용자를 위해 작성됨

자연어, 간단한 테이블이나 다이어그램을 사용

고수준의 추상적 요구사항으로 기술적 전문 용어의 사용을 피할 것

제안 요청서(RFP)의 형태가 이러함

시스템 요구사항 문서

개발자를 대상으로 작성되는 것

서비스와 제약조건을 상세히 기술한 것

설계와 개발 작업의 기초가 되며 계약서의 역할

시스템 모델을 사용하여 표현함

요구사항 검토

개발 팀이 요구사항의 의미를 설명하고 고객, 계약자, 사용자 등이 오류가 있는지 시스템 요구사항을 검토하는 것

요구사항 명세서는 계약서로의 기능을 하므로 고객과 개발자는 모두 상세히 검토해야 함

좋은 요구사항이 갖추어야 할 특성

• 완전성: 모든 가능한 시나리오를 기술
• 일관성: 요구사항들 간에 모순이 없어야 함
• 명확성: 모호한 부분이 없어야 함
• 정확성: 고객이 필요로 하고 개발자가 만들어야 하는 것을 표현해야 함
• 실현성: 제약 조건을 만족하면서 시스템을 구현할 수 있어야 함
• 검증 가능성: 언급된 요구사항이 만족되는지 시스템을 테스트할 수 있어야 함
• 이해성: 시스템의 구입자나 최종 사용자가 이해할 수 있어야 함
• 추적성: 요구사항의 제안자, 요구사항, 설계 문서 및 코드 사이의 관계를 추적할 수 있어야 함
• 적응성: 다른 요구사항을 대규모로 수정하지 않고 변경될 수 있어야 함

요구사항 관리

• 요구사항의 변화를 이해하고 통제하는 프로세스
• 초기 요구사항은 불완전하고 불일치가 존재하므로 요구사항은 변경되거나 진화함
• 환경이 변화하거나 시스템에 대한 이해도가 높아짐에 따라 새로운 요구사항이 생기거나 요구사항이 변경됨
• 지속적 요구사항은 시스템 도메인과 직접적 관련이 있는 요구사항으로 안정적임
• 변하기 쉬운 요구사항은 정책이나 제도의 변화, 관련된 시스템이나 비즈니스 프로세스의 변경으로 바뀔 가능성이 있는 경우

추적 가능성 정보

요구사항의 변경을 관리하기 위한 정보

요구사항들 간에, 그리고 요구사항, 시스템 설계, 코드 사이에는 다양한 관계가 존재함

요구사항이 변경될 경우, 그에 따른 영향을 받는 관련 요구사항(또는 설계 요소)을 파악할수 있어야 함

추적성 정보의 활용

개발자는 모든 요구사항을 개발했는지 확인할 수 있음

테스터는 시스템이 요구사항과 일치하는지 알 수 있음

설계자는 시스템의 존재 이유를 알 수 있음

유지보수자는 변경의 파급 효과를 평가할 수 있음

추적성 정보의 유형

소스 추적성: 요구사항들을 그것의 제안자 및 제안 이유와 연결하는 것

요구사항 추적성: 특정 요구사항과 관련 있는 다른 요구사항들에 관한 정보를 유지하는 것

설계 추적성: 요구사항과 관련된 설계 문서를 파악하고 유지하는 것

요구사항 모델링

요구사항 모델링

• 시스템을 명확히 이해하거나 명세화하기 위해 모델을 사용함
• 자연언어를 이용한 명세의 문제점은 모호성, 요구사항의 혼합, 과도한 유연성, 모듈화의 어려움 등
• 상세한 명세화 작업을 위해서 수학적 명세, 다이어그램이나 테이블, 구조화된 언어, 설계 기술 언어를 사용함
• 가장 널리 사용되는 방법은 시스템 모델을 이용하여 표현하는 것
• 업무 프로세스, 해결할 문제, 시스템 자체를 그래픽을 사용해 표현
• 다양한 관점에서 시스템의 모습을 표현
• 정확한 기술 방법으로 표현하므로 검증 가능함
• 그림은 자연언어보다 이해하기 쉬움
• 분석과 설계 과정의 다리 역할을 함

객체지향 분석

객체를 찾고 객체 간의 관계를 바탕으로 요구사항을 구조화하고 정형화하여 시스템의 모델을 만드는 일

요구사항 명세서를 정형적 모델로 만드는 일은 개발 초기에 어려운 문제를 찾고 해결할 것을 요구하게 되나 도메인 지식과 기술적 지식의 부족 및 의견 불일치로 인해 미뤄지는 경향이 있음

분석 모델은 분석 과정의 결과물로 시스템을 사용자 관점에서 표현한 것으로 분석 객체 모델(클래스 다이어그램)과 동적 모델(상태 다이어그램, 시퀀스 다이어그램)로 구성됨

기능 모델(유스케이스 또는 시나리오)은 객체지향 분석의 입력이며 분석 과정에서 수정될수 있음

외부에서 접근할 수 있는 기능을 유스케이스로 표현하는 방법과 사용자 스토리를 사용하여

요구사항을 모델링 하는 방법이 있음

유스케이스 다이어그램

소프트웨어 시스템과 외부 환경과의 상호 작용을 표현함

막대 인간은 시스템과 상호 작용하는 외부 개체(사람이나 외부 시스템)

타원은 유스케이스로 액터가 이용하는 기능

직선은 액터와 유스케이스를 시작시키거나 결과를 받는 것을 표현

유스케이스

사전 조건, 사후 조건 및 예외 사항을 포함하여 시스템의 동작에 관한 시나리오를 기술한 문서

반복적 개발 프로세스에서 유스케이스는 점차적으로 구체화됨

하나의 유스케이스에서 정의된 행위를 기술하기 위해 시퀀스 다이어그램을 작성하게 됨

사용자 스토리

초기 요구사항 발견과 프로젝트 계획에 사용되는 짧은 대화형의 텍스트

애자일 방법에서 널리 사용됨

2~4 문장 정도로 시스템이 해야 하는 일을 3×5 인치 카드에 작성

하나의 시스템 점증에 대해 80개 카드의 적당함

분석 객체 모델과 동적 모델

요구사항 추출 과정에서 만들어진 유스케이스들과 시나리오들을 분석 모델로 변환하여 클래스 다이어그램, 시퀀스 다이어그램 등을 작성함

분석 객체 모델

시스템이 처리해야 하는 객체나 개념, 그것들의 성질 및 관계를 다루는 모델로 객체는 속성(애트리뷰트)와 오퍼레이션(메소드)을 가짐

UML 클래스 다이어그램으로 표현되며 주요 개념들을 사용자에게 시각적으로 보여줌

동적 모델

상태 다이어그램이나 시퀀스 다이어그램으로 표현됨

시퀀스 다이어그램은 하나의 유스케이스를 실현하기 위한 여러 객체들의 상호작용을 표현

상태 다이어그램은 한 객체의 상태 변화를 표현

분석 객체 모델과 동적 모델을 작성할 때의 고려 사항

사용자 관점의 개념을 표현한 것으로 소프트웨어 클래스나 컴포넌트를 표현하는 것이 아님

분석 객체 모델에 나오는 클래스는 매우 추상화된 형태임

구조적 분석(SA)

시스템 요구사항을 정의하기 위해 분할 정복과 하향식 기능 분해 방법을 사용한 요구사항

분석 방법

결과를 그래픽 표현에 기초한 시스템 모델로 표현

시스템 모델을 사용하여 분석가와 사용자가 의사소통함

기능적 분해에 의해 시스템을 다루기 쉬운 조각들로 나눔

구조적 분석에 사용된 소프트웨어공학 원리

추상화의 원리: 복잡한 사물로부터 핵심적인 부분만을 간추려 내는 것

형식화의 원리: 엄격한 접근방법을 사용하고 단계별로 결과물을 문서화하는 것

분할과 정복: 큰 문제를 작고 독립적인 문제들로 나누어 푸는 것

계층화: 분할된 모듈을 트리 구조로 구성하는 것

구조적 분석과 설계에 사용되는 모델들

소프트웨어 시스템을 보는 세 가지 관점

정보 관점: 사용되는 데이터와 데이터 간의 관계를 규명(개체 관계도)

기능 관점: 어떤 기능을 수행하며, 어떻게 상호 작용하고 입력이 어디서 나와서 어떻게 변환되어 어디로 나가는가(데이터 흐름도)

동적 관점: 실시간 시스템에서 외부 자극(이벤트)에 어떻게 반응하는지에 관한 시스템의 상태 변화를 표현(상태 전이도)

데이터 흐름도(DFD)

구조적 분석에서 사용되는 기능 관점의 시스템 모델

시스템에서 데이터 흐름과 변환을 보여주는 네트워크 형태의 다이어그램

입력 데이터에 대하여 어떤 계산을 통해서 결과가 나오는지에 관한 단계적 처리를 보여줌

정보 처리 시스템의 기능을 명세할 때 널리 사용됨

데이터 저장소에 저장되거나 프로세스 사이에서 전달되는 데이터는 데이터 사전에 정의됨

표기법

프로세스

데이터 흐름

데이터 저장소

외부 개체

최상위 수준의 데이터 흐름도(배경도 또는 0-수준 DFD)에서 시작하여 확장됨

최하위 수준의 데이터 흐름도에 존재하는 프로세스를 기능 단위라 하며, 최하위 프로세스에

대해 프로세스 명세서를 작성함

프로세스 명세서는 의사 코드 등을 사용하여 프로그램의 논리를 보여줌

구조적 분석과 객체지향 분석의 비교

구조적 분석은 기능 관점에서 시스템을 표현함

객체지향 분석은 기능과 데이터를 함께 캡슐화한 객체를 가지고 시스템을 표현함

구조적 분석은 기능 분해 또는 합성에 의한 표현 방법을 사용하며, 객체지향 분석은 상속개념도 사용할 수 있음

01
요구사항 추출과 분석 작업이 어려운 이유를 나열한 것이다. 적당하지 않은 것은?
1 사용자가 원하는 것을 정확히 표현하지 못한다.
2 작업 중에도 요구사항이 바뀌거나 추가된다.
3 작업을 하면서 분석가가의 응용 분야에 대한 이해도가 증가한다.
4 모순되는 요구사항이 나오거나 동일한 내용이 다르게 표현된다.
정답 | 3
해설 | 일반적으로 고객은 자신의 업무에 대해 정통하나 기술적 지식이 부족하고 분석가는
그 반대이다. 분석가가 응용 분야에 대해 잘 알고 있다면 고객과의 의사소통이 나아질 것이
다.
02
요구사항 명세를 문서화할 때 자연 언어로 작성하지 않고 시스템 모델을 사용하면
여러 장점이 있다. 이것에 관한 설명으로 잘못된 것은?
1 그림을 사용하므로 이해하기 쉽다.
2 다양한 관점에서 시스템의 모습을 표현할 수 있다.
3 하나의 표현을 여러 가지 뜻으로 해석할 수 있다.
4 정확한 기술 방법으로 표현하므로 검증이 가능하다.
정답 | 3
해설 | 정확한 기술 방법으로 표현되는 시스템 모델에서 하나의 표현은 하나의 의미로 해석되어 의미의 모호함이 없어진다.
03
사용자 요구사항과 시스템 요구사항을 구분하여 설명할 때, 다음 중 시스템 요구사
항에 해당하는 것은?
1 제안 요청서와 같은 형태
2 고수준의 추상적 요구사항
3 자연언어나 간단한 다이어그램을 사용함
4 설계 작업을 위해 상세히 기술함
정답 | 4
해설 | 시스템 요구사항은 사용자 요구사항을 보다 상세하게 기술한 것으로 설계와 개발
작업의 기초가 되며 계약서로 활용될 수 있다.
04
요구사항 문서가 가져야 하는 좋은 특성 중에 “요구사항을 제안한 사람, 요구사항,
설계 문서 및 코드 사이의 의존성을 파악할 수 있다”와 관계 있는 것은?
1 이해성
2 추적성
3 실현성
4 검증 가능성
정답 | 2
해설 | 요구사항이 주어질 때 그것의 제안자를 연결한 것을 소스 추적성, 관계있는 다른 요
구사항을 연결한 것을 요구사항 추적성, 관련된 설계 문서를 연결한 것을 설계 추적성이라
한다.
05
요구사항 문서가 가져야 하는 좋은 특성 중에 “시스템을 통해 일어날 수 있는 모든
가능한 시나리오가 기술되었다”를 의미하는 것은?
1 완전성
2 추적 가능성
3 실현성
4 검증 가능성
정답 | 1
해설 | 완전성이란 빠짐없이 모든 것이 기술되어 있는 것을 의미한다.
06
요구사항 추출과 객체지향 분석 과정에서 다음 중 가장 먼저 수행해야 하는 작업
은?
1 유스케이스의 작성
2 시퀀스 다이어그램의 작성
3 상태 다이어그램의 작성
4 클래스 다이어그램의 작성
정답 | 1
해설 | 유스케이스는 기능적 요구사항을 표현한 것으로 요구사항 추출 후 수행되는 분석
작업의 입력이 된다.
07
구조적 분석(SA)/구조적 설계(SD)와 관련이 없는 내용은?
1 분할 정복과 하향식 기능 분해 2 데이터 흐름도와 구조도
3 상속 개념의 적용과 유스케이스
4 기능 관점에서 시스템을 기술
정답 | 1
해설 | 상속은 객체지향 개념의 하나이며 유스케이스는 객체지향 분석 과정에서 사용된다.08
데이터 흐름도의 구성 요소가 아닌 것은?
1 데이터 흐름
2 프로세스
3 데이터 저장소
4 데이터 사전
정답 | 4
해설 | 데이터 흐름도에서 데이터 저장소에 저장된 데이터나 프로세스 사이에서 전달되는
데이터는 데이터 사전에 정의되어 있다.
정리하기
01
요구사항 분석과 요구 공학의 의미는 무엇인가?
요구사항 분석은 사용자의 요구사항을 결정하는 과정이다. 요구 공학은 요구사항 분석의 결
과를 문서화하고 변화되는 요구사항을 관리하기 위한 반복적인 프로세스이다.
02
JAD(Joint Application Design)는 무엇인가?
애플리케이션의 설계와 개발 과정에 고객과 사용자를 참여시키는 방법이다. JAD 세션으로
불리는 워크숍을 통해 개발자와 사용자는 빠른 합의와 협력을 이끌어낼 수 있다.
03
요구사항 문서 갖추어야 하는 특성인 완전성, 일관성, 명확성이란 무엇인가?
완전성은 “시스템을 통해 일어날 수 있는 모든 가능한 시나리오들이 기술되었다”이며 일관
성은 “요구사항들 간에 서로 모순되지 않는다”이며 명확성은 “ 요구사항 명세서에 모호한
부분이 없다”이다.
04
구조적 분석을 설명하라.
자료 흐름의 분석을 통해 요구사항을 정의하는 방법이다. 분할 정복과 하향식 기능 분해 방
법을 사용하며 그래픽으로 표현된 시스템 모델로 결과를 표현한다. 자료 흐름도와 자료 사
전이 대표적이다.
05
객체지향 분석 과정의 결과물은 무엇인가?
분석은 추출된 요구사항을 구조화하고 정형화 하는 일이다. 클래스와 클래스 간의 관계를
표현하는 클래스 다이어그램, 하나의 유스케이스를 실현하기 위한 객체들 간의 상호작용을
표현한 시퀀스 다이어그램, 한 객체의 상태 변화를 표현한 상태 다이어그램이 분석 과정의
결과물이다. 사용자의 요구를

요구사항 추출과 분석 작업이 어려운 이유를 나열한 것이다. 적당하지 않은 것은?

• 1 사용자가 원하는 것을 정확히 표현하지 못한다.
• 2 작업 중에도 요구사항이 바뀌거나 추가된다.
• 3 작업을 하면서 분석가의 응용 분야에 대한 이해도가 증가한다.
• 4 모순되는 요구사항이 나오거나 동일한 내용이 다르게 표현된다.

확인

정답 및 해설

정답입니다.

정답 : 3번

일반적으로 고객은 자신의 업무에 대해 정통하나 기술적 지식이 부족하고 분석가는 그 반대이다.
분석가가 응용 분야에 대해 잘 알고 있다면 고객과의 의사소통이 나아질 것이다. 

사용자 요구사항과 시스템 요구사항을 구분하여 설명할 때, 다음 중 시스템 요구사항에 해당하는 것은?

• 1 제안 요청서와 같은 형태
• 2 고수준의 추상적 요구사항
• 3 자연언어나 간단한 다이어그램을 사용함
• 4 설계 작업을 위해 상세히 기술함

확인

정답 및 해설

정답입니다.

정답 : 4번

시스템 요구사항은 사용자 요구사항을 보다 상세하게 기술한 것으로 설계와 개발 작업의 기초가 되며 계약서로 활용될 수 있다. 

요구사항 문서가 가져야 하는 좋은 특성 중에 요구사항을 제안한 사람, 요구사항, 설계 문서 및 코드 사이의 의존성을 파악할 수 있는 것과 관계있는 것은?

• 1 이해성
• 2 추적성
• 3 실현성
• 4 검증 가능성

확인

정답 및 해설

정답입니다.

정답 : 2번

요구사항이 주어질 때 그것의 제안자를 연결한 것을 소스 추적성, 관계가 있는 다른 요구사항을 연결한 것을 요구사항 추적성, 관련된 설계 문서를 연결한 것을 설계 추적성이라 한다.

요구사항 추출과 객체지향 분석 과정에서 다음 중 가장 먼저 수행되어야 하는 작업은?

• 1 유스케이스의 작성
• 2 시퀀스 다이어그램의 작성
• 3 상태 다이어그램의 작성
• 4 클래스 다이어그램의 작성

확인

정답 및 해설

정답입니다.

정답 : 1번

유스케이스는 기능적 요구사항을 표현한 것으로 요구사항 추출 후 수행되는 분석 작업의 입력이 된다. 

데이터 흐름도의 구성요소가 아닌 것은?

• 1 데이터 흐름
• 2 프로세스
• 3 데이터 저장소
• 4 데이터 사전

확인

정답 및 해설

정답입니다.

정답 : 4번

데이터 흐름도에서 데이터 저장소에 저장되는 데이터나 프로세스 사이에서 전달되는 데이터는 데이터 사전에 별도로 정의되어 있다.