[소프트웨어공학] Chapter 04. Requirements Engineering
Requirements Engineering ( 요구 공학 ) 이란
시스템이 동작하고 개발되는 제약 조건과 함께 고객이 시스템에 대해 필요로 하는 서비스(기능)를 설정하는 과정.
소프트웨어 개발 프로세스의 초기 단계 중 하나로, 소프트웨어 시스템이나 제품의 요구사항을 정의, 수집, 분석, 검증 및 관리하는 과정
요구사항(requirments)이란
요구공학 프로세스 동안 생성되는 시스템 서비스와 제약 조건에 대한 기술(descriptions)
( 고객의 요구사항을 일반적인 high-level로 설명하는 추상적인 말(ex. ~하게 돌아가는 서비스)부터 개발자가 이해할 수 있는 자세한 수학식이 적힌 명세서까지 )
요구사항이 제공하는 2가지 기능
· 계약을 매길때 가격 제시의 기반이 될 수 있다 (이해할 수 있어야한다 )
· 계약 할 때 기반이 되기도 한다 ( 자세하게 정의되어야 한다 )
요구사항의 2가지 유형( Types of requirement )
User requirements (사용자 요구사항) _ 고객을 위해 작성
- 시스템의 기능과 동작에 대한 제약사항에 대해 인간의 언어로 쓰인 글이나 시스템에서 제공하는 도표, 그림 등
User requirements 읽는 사람들 :
Client-manager, System end-users, Client engineers, Contractor managers, System architects
System requirements (시스템 요구사항)
- 시스템의 기능, 서비스, 제약사항들에 대해 상세하게 쓰이고 문서화 된 요구사항
- 무엇이 구현되어야 하는지 정의되어있다. 고객과 계약자 간의 계약서의 일부가 될 수 있음
- 소프트웨어 개발자가 사용함
System requirements 읽는 사람들 :
System end-users, Client engineers, System architects, Software developers
이해관계 당사자( System stakeholders )
시스템으로부터 어떻게든 영향을 받는 사람이나 기업 (시스템으로부터 정당한 이득을 얻는 사람, 기업)
· 최종 사용자(end-users), 시스템 관리자(system managers), 시스템 소유자(system owners), 외부 이해관계 당사자(external stakeholders) 등
Agile methods와 Requirements
· Agile 방법에서는 요구사항이 자주 바뀌기 때문에 자세한 요구사항을 만드는 것은 시간낭비라고 여긴다
· 그렇기에, agile에서 요구사항 문서화 작업은 항상 뒤떨어져있다
· Agile 방법은 주로 증분해서 요구사항을 반영하고 요구사항을 user's story라고 표현한다
· 일반 비지니스 시스템에서는 괜찮지만 중요한 시스템이나 여러 팀으로 나누어져 개발하는 곳에서는 문제가 생길 수 있다
Functional and non-functional requirements
Functional (기능적) and non-functional (비기능적) 요구사항
[ Functional requirements ]
- 시스템이 제공하는 서비스나 기능에 대한 요구사항
(입력에 대하여 어떻게 반응해야하고 특별한 상황에서는 어떻게 동작해야하는지 등)
- 소프트웨어의 종류, 예상 사용자, 시스템의 종류에 따라 다르다
ex) 병원 시스템에서 사용자는 모든 진료들의 예약 리스트를 검색할 수 있어야한다.
Functional user requirements => 시스템에 포함되어야 하는 것을 말로 표현
Functional system requirements => 시스템 서비스에 대하여 자세하게 서술해야 한다.
[ Non - functional requirements ]
- 시스템에서 서비스나, 기능에 대한 제약사항들 (시간 문제, 개발과정 등)
- 종종 특정 서비스보다는 시스템 전체에 적용됨
- 시스템의 속성(신뢰도, 반응시간, 저장용량 등)과 제약사항(입출력 기기 등)에 대한 요구사항- 특정 개발 플랫폼, 언어, 방법론 등에 관한 제약사항도 포함될 수 있다
- functional 보다 non-functional 요구사항들이 더 중요할 수도 있다 ( 충족되지 않으면 시스템이 쓸모없을 수 있음 )
비기능적 요구사항 분류
1. Product requirements
- 개발된 시스템이 특정한 방식으로 행동해야 한다는 요구사항 ex) 실행속도, 신뢰도 등
2. Organizational requirements
- 조직의 정책과 절차의 결과로 나온 요구사항 ex) 구현 요구사항, 프로세스 기준 등
3. External requirements
- 외부로부터 요구되는 요구사항들 ex) 법적인 부분
Domain requirements
- 소프트웨어나 시스템 개발에서 해당 시스템이 적용될 도메인에 대한 요구사항
즉, 시스템이 동작할 환경이나 상황에 따라 필요한 요구사항을 정의하는 것
ex. 병원 시스템에서 의료 기록을 열람할 수 있는 사람들의 범위, 환자의 개인정보 보호, 의료진 간의 의사소통, 의료기기의 안전성 등
Requirements imprecision
- 기능적 요구사항이 자세하게 설명되어있지 않으면 문제가 생긴다 (계약 문제와도 직결되기 때문)
- 애매한 요구사항은 개발자와 고객에 의해 서로 다르게 해석될 수 있다
Requirements Completeness and Consistency ( 요구사항의 완벽성과 일관성 )
- 요구사항들은 완벽하고 일관성 있어야한다.
Complete
- 필요한 모든 기능들을 파악하고 포함해야한다
Consistent
- 기술적인 충돌이나 모순이 발생해선 안된다 (하나의 제한사항에 의해 다른 요구사항이 성립되지 않는게 존재하면 안
된다)
실무에서,
시스템과 환경이 복잡하기 때문에 완전하고 일관된 요구사항을 작성하는 것은 불가능하다
Goals and requirements
- 비기능적 요구사항을 정확하게 설명하는 것은 어려울 수 있다. 부정확한 요구사항은 검증하기 어려울 수 있다.
Goal (목적) : 사용자의 일반적인 의도
( ex. 사용 편의성, 시스템은 사용하기 쉬워야하고 에러가 거의 발생하지 않아야한다, 직원이 4시간동안 훈련을 받으면 모든 기능을 쓸 수 있어야한다 (Testable non-functional requirement) )
Verifiable non-functional requirement (검증가능한 비기능적 요구사항) : 객관적으로 테스트할 수 있는 측정 기준을 사용하여 명시된 요구사항
Goal(목적)은 시스템 사용자의 의도를 전달해주므로 매우 유용함.
비기능적 요구사항을 명시하는데 사용되는 항목들
1. Speed (속도)
ex) 이벤트 반응시간, 화면 새로고침 시간, 초당 트랜잭션 등
2. Size (용량)
ex) 파일 크기, ROM 칩 수
3. Ease of use (사용하기 편리함)
ex) 트레이닝 시간
4. Reliability (신뢰도)
얼마나 오차 없이 정확하게 측정하고 있는가의 정도
ex) 장애까지의 평균 시간, 불가용성 확률, 고장 발생률, 가용성
5. Robustness (견고성)
ex) 장애 후 재시작 시간, 장애를 유발하는 이벤트 비율, 장애 시 데이터 손상 가능성
6. Portability (이식성)
ex) 특정 플랫폼이나 OS에 종속되는 코드 비율, 지원 대상 시스템의 수
Requirements engineering processes
요구공학 처리과정은 여러상황이 다 다르므로 하나로 통일하기 어렵지만 공통적인 부분이 있다
공통적인 부분
1 ) Requirements elicitation - 요구사항 도출
2 ) Requirements analysis - 요구사항 분석
3 ) Requirements validation - 요구사항 점검
4 ) Requirements management - 요구사항 관리
※ 실무에서, 요구공학은 위의 1 ~ 4과정이 계속 반복된다 ( 반복을 거치며 점점 구체화 됨 )
Requirements elicitation - ( 요구공학 처리과정 공통부분 1, 2 )
Requirements elicitation and analysis ( 요구사항 도출 및 분석 )
- 요구사항을 도출하는 방법 (기능적, 비기능적, Domain 요구사항들을 고객과 개발자가 함께 찾는다)
- 다양한 이해관계 당사자가 참여
[ 요구사항 도출/분석의 4가지 단계 ] _순환구조
1) requirements Discovery (발견)
이해관계 당사자로부터 요구사항을 얻기위해 소통 ( domain 요구사항들이 이 과정에서 발견될 수 있다 )
- 요구되는 시스템이나 현존하는 시스템에서 정보를 모으고 사용자 요구사항과 시스템 요구사항을 분리하는 것
- 이해관계 당사자와 소통
2) requirements Classification and Organization (분류 및 조직)
서로 관련된 요구사항들을 그룹짓고 덩어리로 조직화하기
3) requirements Prioritization and Negotiation (우선순위 매기기, 충돌 해결)
요구사항의 우선순위를 정하고 충돌되는 요구사항 해결
4) requirements Specification (명세화)
요구사항이 문서화되고 다음 반복되는 과정을 위해 입력해둔다
* 위 4가지 과정이 순환되는 구조로 요구사항을 추출한다.
Interviewing (stakeholders로부터 요구사항을 끌어내는 방법)
- 이해관계 당사자와 비공식/공식적인 인터뷰를 함으로써 요구사항을 얻을 수 있다
인터뷰의 종류
- close 인터뷰 : 사전에 준비된 질문을 통해 인터뷰
- open 인터뷰 : 여러 이해관계 당사자 사이에서 이슈가 나온다
인터뷰를 효과적으로 하는 법
- 오픈 마인드, 이해관계 당사자의 말을 잘듣기, 미리생각한 아이디어 피하기
실무에서의 인터뷰
- 인터뷰는 보통 closed와 open을 혼합해서 한다
=> 인터뷰를 통해 이해관계 당사자가 무엇을 원하고 시스템 사용에 대한 전반적인 이해를 얻을 수 있다
- Interviewers들은 시스템이 무엇을 해야 하는지에 대해 미리 생각해온 것 없이 열린 마음으로 대해야 한다
- 단순히 원하는 것을 묻는 것이 아니라 요구 사항을 제안함으로써 효과적으로 유도해야 한다.
인터뷰의 문제점
- 개발자가 쓰는 용어를 요구공학자가 이해하지 못할 수 있다
- Domain requirement를 얻기에는 좋지 않다 ( 특정 분야의 용어를 잘 모르기 때문, 너무 친숙해서 놓칠 수도 있음 )
Problems of requirements elicitation ( 요구사항 도출의 문제점 )
- 이해관계 당사자는 그들이 무엇을 원하는지 잘 알지 못한다
- 이해관계 당사자는 개발과 관련된 용어를 잘몰라 그들만의 말로 표현한다
- 서로 다른 이해관계 당사자 간 요구사항 충돌이 발생할 수 있다
- 기업이나 정치적 문제에 영향받을 수도 있다
- 분석단계에서 요구사항이 바뀔 수 있다. 새로운 이해관계 당사자가 생길 수도 있고 비즈니스 환경이 바뀔 수도 있음.
Stories and scenarios ( 스토리와 시나리오로 부터 요구사항 끌어내기 )
- scenarios와 user stories는 시스템이 어떻게 사용될 수 있는지의 예시를 보여준다 ( 특정 작업에서 어떻게 쓰일 것인지 )
- 실제 사용에 기반하기 때문에 이해관계 당사자는 후기를 남길 수 있다
Scenarios ( 구조화된 user stories )
- starting situation : 시작 상황에 대한 기술
- normal flow of events : 정상적인 동작에 대한 기술
- what can go wrong : 잘못될 수 있 상황에 대한 기술
- other concurrent activities : 다른 여러가지 상황에서의 동작에 대한 정보
- scenario finishes : 종료됐을 때의 상태에 대한 기술
도출/분석 과정 4. Requirements specification
사용자/시스템 요구사항을 문서화하는 과정
- User requirement는 최종 사용자, 고객이 이해할 수 있어야한다 ( 배경 지식이 없음으로 가정 )
- System requirement는 사용자 요구사항보다 더 자세하고 기술적인 정보를 포함할 수 있다 (시스템 관련 사항)
※ 요구사항이 시스템 개발을 위한 계약의 일부가 될 수 있다 (문서화가 최대한 완벽해야 하는 이유)
시스템 요구사항 작성 방법
- Natural language (자언어) : 각 요구사항은 넘버링하고, 각 넘버에는 하나의 요구사항만 작성.
- Structured Natural language : 요구사항을 표준 형식이나 템플릿에 작성. (각 부분에는 요구사항에 대한 정보 제공)
- Design description language : 프로그래밍 언어 등으로 작성. (추상적으로) =>인터페이스 설명에 용이하나 요즘 잘 안쓰임
- Graphical notations : 시각적 요소, UML use case, Sequence diagram 등 사용
- Mathematical specification : 수학적인 개념(유한상태머신, 집합)에 기반하여 서술.
Requirements and design ( 요구사항과 설계 )
- 요구사항은 시스템이 무엇을 해야할지 설명하는 것이고 설계는 그것을 어떻게 할지 서술하는 것이다
실무에서, 요구사항과 설계를 분리하기는 어렵다
- 요구사항을 구조화 하기위해 시스템 구조가 설계될 수 있음
- 다른 시스템과 상호작용하는 시스템은 설계 요구사항을 발생시킴
Natural language Specification ( 자연어 명세서 )
- 요구사항은 다이어그램이나 표와 함께 자연어로 쓰일 수 있다
- 표현적이고 직관적이고 보편적이라 사용자와 고객이 이해하기 쉬우므로 요구사항 작성에 사용된다.
Guidelines for writing requirements
- 표준 형식을 만들고 모든 요구사항에 사용해라
- 언어를 일관된 방식으로 (중요한 요구사항은 shall / desirable한 요구사항은 should로 작성)
- 요구사항 중 핵심이 되는 부분에 밑줄 치기
- 컴퓨터 특수용어 사용은 지양
- 왜 요구사항이 필요한지 설명을 작성
Problems with natural language ( 자연어의 문제점 )
- Lack of clarity (명료함 부족) : 읽기 어렵다
- Requirement confusion (혼란) : 기능적, 비기능적 요구사항이 혼합될 수 있다
- Requirement amalgamation (혼합) : 여러 서로다른 요구사항들이 같이 표현될 수 있다
Structured specification (구조화된 명세서 ) - 개발자들이 주로 사용하는 형태
- 요구사항을 자유롭게 쓰는 것을 제한하고 표준화된 형태로 작성
- 몇몇 종류의 요구사항에 적합 ex) 임베디드 컨트롤에는 적합 But. 비지니스 시스템에는 부적합
- 구조화되어있으면 자연어보다 정보를 찾기 쉬움
Form-based specification ( 형식기반 명세서 ) -> structured 명세서임.
- function or entity 에 대한 기술
- inputs/outputs and where they come from/ go to 에 대한 기술
- information needed for the compuation and other entities에 관한 정보에 대한 기술
- action to be taken에 대한 기술
- pre/post-condition
- function에 의한 side effects(있다면)
+ Domain에 관련된 내용들도 추가될 수 있다.
Tabular specification ( 표 형태의 명세서 )
- 자연어를 보완하는데 사용됨
- 가능한 action과정들이 여러개면 이들을 정의할때 유용
Use cases
- UML에 포함되는 일종의 시나리오
- 상호작용하는 행위자(actors)를 식별해주고 어떤 상호작용을 하는지 설명
- 시스템 상의 모든 가능한 상호작용을 설명해야함
- 예측하기 힘든 것을 시각적요소로 보여준다 (어떤 이벤트가 발생하는지 자세하게 설명)
=> 사용자가 어떤 작업을 하는지 파악하기 쉽게 해준다
software Requirements document (요구사항 문서)
- 시스템 개발자에 대한 공식적인 요구사항 문서 ( 개발자가 무엇을 해야하는지 적혀있는 )
- 사용자 요구사항 정의와 시스템 요구사항 명세서 모두 포함해야 함
- 설계(design) 문서가 아니다 (어떻게 동작될 것인지가 아닌 무엇을 해야할지)
=> 앞에서도 보았듯이 분리하기 어렵지만 요구사항 문서에는 what만 고려
요구사항 문서 사용자들
- System Customers : 요구사항을 충족하는지 체크하며 읽는다
- Manager : 계약을 하기 위해 요구사항으로부터 계획을 세운다
- System engineers : 시스템이 무엇을 해야하는지 확인
- System test engineers : 시스템을 검증하기 위해 요구사항 확인
- System maintenance engineers : 시스템을 이해하고 부분간의 연관성을 이해하기 위해 사용
요구사항 문서의 구조
Preface (서문)
Introduction (소개글) : 시스템의 기능이나 다른 시스템과 어떻게 연관되는지 간단하게 서술
Glossary (용어사전)
User Requirements definition (사용자 요구사항) : 사용자에게 제공하는 서비스 설명 (비기능적 부분도 포함)
System architecture (시스템 구조)
System requirements specification : 기능/비기능적 요구사항이 자세하게 서술
System models
System evolution
Appendices(부록)
Index(색인)
Requirements validation - ( 요구공학 처리과정 공통부분 3 )
Requirements validation (요구사항 점검)
- 사용자가 원하는 것이 시스템에 반영되었는지 요구사항 확인
- 배포 후 에러 처리비용은 상당히 비싸기 때문에 검증과정이 중요하다 (배포 전 에러 체크)
요구사항 체크사항
- Validity (타당성) : 사용자의 요구사항을 최상의 기능(function)으로 제공하는가?
- Consistency : 요구사항이 충돌하지는 않는가?
- Completeness : 고객이 요구하는 모든 기능(function)들이 반영되어있는가?
- Realism : 주어진 이용가능한 예산, 인적 자원으로 충분한가?
- Verifiability : 요구사항들은 검증 가능한가? / 입출력이 확실해야함
요구사항 검증 기술
- Requirements review : 매뉴얼 분석을 체계화 하기 ( 고객과 개발자가 함께 리뷰 참여하기 )
- Prototyping : 실행가능한 시스템 모델을 만든다
- Test-case : 테스트 케이스 만들어서 점검
Review check
코드 리뷰 이후에 개발자가 수정한 내용을 다시 한번 검토하는 과정
1. Verifiability : 현실적으로 테스트 가능한지 - 검증가능성
2. Comprehensibility : 이해가능한지 - 이해가능성
3. Traceability : 출처가 명확한지 (누가 요구했는지) - 추적가능성
4. Adaptability : 적응가능한지 (수정 시 다른 요구사항에 큰 영향을 주지 않고 수정될 수 있는지) - 적응성
Requirements change - ( 요구공학 처리과정 공통부분 4, Requirements management )
Changing requirements (요구사항 변화)
- 시스템은 계속 업데이트 될 수 밖에 없음 ( 시대의 흐름이 계속 변하기 때문 )
- 시스템을 위해 돈을 지불하는자와 최종 사용자는 거의 다름
- 큰 시스템은 다양한 사용자가 있어 이들의 다른 요구사항들과 우선순위들로 인해 갈등이 발생할 수 있음
요구사항 업데이트 과정
초기 문제 인식 -> 초기 요구사항들 -> 수정된 문제 인식 -> 수정된 요구사항들 ==> (반복구조)
Requirement management (관리)
- 요구공학과정이나 시스템 개발로부터 발생하는 수정되는 요구사항을 관리
=> 시스템이 업데이트 되다보면 새로운 요구사항이 발생할 수 밖에없다
요구사항 관리 기법
- Requirements identification : 각 요구사항은 유일하게 식별되어야한다 (다른 요구사항과 연관될 수 있으므로)
- Change management process : 수정 시 미치는 영향과 비용 잡는 과정
- Traceability policies : 요구사항들 간의 관계, 시스템 디자인들을 기록해두기
- Tool support : 관리 툴 이용
요구사항 변화(change)가 받아들여질지 결정하는 것들
1. Problem analysis and change specification ( 문제분석과 수정사항 사양화 : 유효한지 점검 )
2. Change analysis and costing ( 변화 분석과 가격 매기기 )
3. Change implementation ( 변화 작업 수행 )
