4장. 요구공학
요구 사항 (Requirement)
요구 사항 (Requirements)
시스템이 제공해야 하는 서비스(Services)와 (서비스, 개발, 운영 등)에 대한 제약조건(Constraints)
요구 사항 유형
1. 사용자 요구사항
•
시스템이 사용자에게 제공해야 할 서비스와 동작하면서 준수해야 할 제약사항들에 대해 자연어와 다이어그램으로 기록한 문장
•
대상: 고객 관리자, 시스템 최종 사용자, 고객 엔지니어, 계약 관리자, 시스템 아키텍트
2. 시스템 요구사항
•
소프트웨어 시스템의 기능, 서비스와 동작 중 제약사항에 대한 보다 상세한 설명
•
무엇을 구현해야 할지에 대해 정확하게 정의
•
구현해야 할 시스템의 서비스와 기능에 대해 보다 구체적인 정보 제공
•
대상: 시스템 최종 사용자, 고객 엔지니어, 시스템 아키텍트, 소프트웨어 개발자
시스템 이해당사자
•
어떠한 방식으로든 시스템의 영향을 받는 사람에 해당
•
시스템에 어느정도의 관심을 가지고 있는 누구라도 시스템 이해당사자에 해당
요구 공학 (Requirements Engineering)
요구사항을 찾고, 분석하고, 문서화하고, 점검하는 프로세스
타당성 조사 (Feasibility Studies)
요구 공학 프로세스 초기에 이루어져야 하는 짧은 기간의 집중적 조사
1.
시스템이 조직의 전체 목적에 기여하는가?
2.
시스템이 현재의 기술을 이용해 일정과 예산 내로 구현이 가능한가?
3.
시스템을 사용하는 다른 시스템과 통합 가능한가?
3가지를 모두 충족해야 한다.
기능적 / 비기능적 요구사항
요구 사항 분류
1. 기능적 요구사항 → Service
시스템이 제공해야 하는 서비스와 특정 입력에 대해 시스템이 반응하는 방식, 특정 상황에 시스템이 동작해야 하는 방식을 기술한 것이다.
2. 비기능적 요구사항 → Constraints
•
시스템이 제공하는 서비스나 기능에 대한 제약사항
•
개별적인 시스템 특징이나 서비스보다는 전체 시스템에 적용되는 경우가 많다.
3. 도메인 요구사항
•
시스템 사용자의 특정 요구사항이 아닌 시스템의 응용 도메인에서 얻는다.
•
소프트웨어 엔지니어가 시스템이 동작하는 도메인의 특성을 이해하지 못한다는 단점이 존재한다.
기능적 요구사항
기능적 요구사항 (Functional Requirements)
•
시스템에 대한 기능적 요구사항은 시스템이 무엇을 해야 하는지를 설명
•
시스템이 무엇을 해야 하는지에 초점
•
시스템의 기능이나 서비스를 기술한다.
기능적 요구사항의 종류
1. 기능적 사용자 요구사항
시스템이 무엇을 해야 하는지 고수준으로 기술
2. 기능적 시스템 요구사항
시스템의 서비스를 자세하게 기술
요구사항 명세의 부정확성 (Requirements Imprecision)
모호한 요구사항은 사용자와 개발자가 서로 다르게 해석할 수 있어 분쟁을 일으킬 수 있다.
이상적인 기능적 요구사항 명세
1. 요구사항의 완전성
필요로 하는 모든 서비스와 정보가 정의되어야 한다.
2. 요구사항의 일관성
충돌하거나 모순되는 요구사항이 없어야 한다.
실수 혹은 누락, 이해당사자간 충돌로 인해 완전하고 일관적인 현실에서 요구사항을 작성하는 것은 어렵다
비기능적 요구사항
비기능적 요구사항 (Non-Functional Requirements)
•
시스템이 사용자에게 제공하는 특정 서비스와 직접적으로 관련되지 않은 요구사항
•
전체 시스템에 대한 명세나 제약조건
•
신뢰성, 응답시간, 메모리 사용량 등 창발적(Emergent) 시스템 속성과 관련된 제약
•
입출력 장치 성능, 다른 시스템과 인터페이스에 사용되는 데이터 표현등 시스템 구현과 관련된 제약
비기능적 요구사항 특징
•
비기능적 요구사항이 만족되지 않을 경우 기능적 요구사항의 경우보다 심각해질 수 있다.
•
비기능적 요구사항은 특정 컴포넌트보다 시스템의 전체 아키텍처에 영향을 받는다.
비기능적 요구사항 분류
1. 제품 요구사항 (Product Requirements)
•
소프트웨어의 실행시간 동작에 대한 제약조건
•
성능, 신뢰성, 보안, 사용성 등
2. 조직 요구사항 (Organizational Requirements)
•
고객과 개발자 조직의 정책이나 절차로부터 오는 요구사항
•
운영 프로세스, 개발 프로세스, 개발환경, 프로세스 표준, 운영환경 등
3. 외부 요구사항 (External Requirements)
•
시스템과 개발 프로세스 외부로부터 오는 광범위한 요구사항
•
규제 법률 윤리 등
비기능적 요구사항을 명세하기 위한 척도
속성 | 척도 |
속도 Speed | 초당 처리 트랜잭션 수 / 사용자, 사건 응답시간 / 스크린 리프레시 시간 |
크기 Size | 메가바이트 / ROM 칩 개수 |
사용 편리성 Ease of use | 교육 시간 / 도움말 프레임 수 |
신뢰성 Reliability | 평균 고장 시간 / 고장 발생 비율 / 가용성 |
견고성 Robustness | 고장 후 재가동 시간 / 고장을 원인 사건의 백분율 / 고장에 의한 데이터 손실 확률 |
이식성 Portability | 타겟 시스템에 종속된 코드 비율 / 타겟 시스템의 수 |
요구 공학 프로세스
요구공학 프로세스 활동
1. 요구사항 도출 (Elicitation)
2. 요구사항 분석 (Analysis)
3. 요구사항 명세화 (Specification)
4. 요구사항 검증 (Validation)
실무에서는 요구공학 활동들이 중첩되어 진행된다.
요구사항 도출
요구사항 도출 프로세스
•
이해당사자들의 업무를 이해하고 시스템을 업무에 활용하는 방식을 알아낸다.
•
이해당사자들로부터 응용 도메인, 시스템이 제공해야 하는 서비스, 요구되는 시스템 성능, 하드웨어 제약 등을 알아내야 한다.
요구사항 도출 프로세스 활동
1. 요구사항 발견 및 이해 (Discovery and Understanding)
2. 요구사항 분류 및 구성 (Classification and Organization)
3. 요구사항 우선순위 지정 및 협상 (Prioritization and Negotiation)
4. 요구사항 문서화 (Documentation)
관점 (Viewpoints)
•
공통점을 가진 이해당사자들로부터 요구사항을 모으고 구성하는 방식이다.
•
요구사항 분석을 위해 이해당사자 정보를 조직화
•
이해당사자 그룹이 하나의 관점을 가졌다고 간주하고 해당 그룹의 관점으로부터 요구사항 수집
•
도메인 요구사항이나 타 시스템 관련 제약조건을 나타내는 관점을 포함시킬 수 있다.
•
상이한 이해당사자들은 요구사항의 중요도와 우선순위가 다르므로 정기적인 미팅이 중요하다.
요구사항 도출을 위한 주요 기법
1. 인터뷰 (Interview)
사람들이 무엇을 하는지에 대해 이야기를 나눈다.
2. 관찰 또는 문화기술적 연구 (Observation or Ethnography)
일을 하는 사람들의 모습을 지켜보고 사람들이 무엇을 사용하는지, 어떻게 사용하는지 등을 살핀다.
인터뷰 유형
1.
미리 정의된 질문 목록이 있는 폐쇄적 인터뷰 (Closed)
2.
개방적 인터뷰 (Open)
인터뷰의 문제점
1.
도메인 전문 용어는 비전문가가 이해하기 어렵다.
2.
전문가는 자신의 지식이 상식이라 간주하여 어떤 도메인 지식을 언급하지 않는 경우도 존재한다.
문화 기술적 연구
운영 프로세스를 이해하고 이와 같은 프로세스를 지원하는 소프트웨어의 요구사항을 얻기 위해 사용하는 관찰기법
문화기술적 연구가 효과적인 경우
•
실제 일하는 방식으로부터 얻을 수 있는 요구사항
•
협력과 다른 사람의 활동을 인식하는 것으로부터 얻을 수 있는 요구사항
문화기술적 연구의 특징과 예시
문화 기술적 연구는 프로토타입 개발과 결합 가능하다
1.
Nokia → 문화 기술적 연구를 통해 새 제품의 요구사항 도출
2.
Apple → 기존 사용법을 무시
Tip)
•
ISP (Information Strategy Planning): 조직의 경영계획과 목표를 지원하기 위한 정보 시스템의 비전을 수립하는 정보전략 계획
•
BPR (Business Process Reengineering): 조직의 작업을 개선하고 자원을 효율적으로 활용하기 위해 처음부터의 근본적인 변화를 도출하는 컨설팅 프로젝트
스토리와 시나리오
스토리와 시나리오
•
특정 작업을 위해 어떻게 시스템을 사용하는지 기술
•
작업 시나리오를 거치면서 무엇을 하는지, 사용하는 정보는 무엇인지, 어떤 시스템을 이용하는지에 대한 설명을 만든다.
시나리오
사용자 상호작용이 이루어지는 일정 구간에 대한 사례를 구조적으로 설명한다.
스토리와 시나리오는 본질적으로 같은 것으로, 특정 작업을 위해 어떻게 시스템을 사용하는가에 대한 설명에 해당한다.
시나리오의 구성
1.
시나리오가 시작할 때 시스템과 사용자가 기대하는 것에 대한 설명
2.
시나리오 상의 사건들의 정상적인 흐름에 대한 설명
3.
잘못될 경우와 그에 대한 대처 방안에 대한 정보
4.
동시에 진행할 수 있는 다른 활동에 대한 정보
5.
시나리오가 종료했을 때 시스템 상태에 대한 설명
요구사항 명세
요구사항 명세란?
사용자 요구사항 및 시스템 요구사항을 요구사항 문서로 작성하는 과정
이상적인 요구사항 명세
1.
시스템의 외부행동과 운영상의 제약조건을 기술해야 한다.
2.
시스템 설계와 구현에 대한 사항을 다루지 않아야 한다.
현실적인 요구사항 명세
•
요구사항에서 설계정보를 완전히 제외하는 것은 불가능하다.
•
초기 아키텍처 설계가 요구사항을 구성하는데 도움이 된다.
•
대부분의 경우 시스템은 기존 시스템과 상호작용이 필요하다.
•
비기능적 요구사항을 만족시키기 위해 특정 아키텍처를 사용해야 하는 경우도 존재한다.
자연어 명세 (Natural Language Specification)
•
시스템 소프트웨어 요구사항을 명세하기 위해 가장 많이 사용되는 수단
•
표현력이 풍부하고 직관적이며 보편적이라는 장점과 애매모호하다는 단점이 존재한다.
자연어 명세 작성 지침
1.
표준 형식을 만들어 사용
2.
필수적인 사항과 바람직한 사항을 구분하기 위해 일관성 있는 표현을 사용
3.
중요 부분의 글자를 강조
4.
요구사항의 독자가 기술적이고 소프트웨어 공학 용어를 이해한다고 생각하지 말 것
5.
가능하다면 사용자 요구사항에 대한 이유를 기록하여 변경 시 활용한다.
•
왜 포함됐는가 / 누가 제안했는가 등
구조적 명세 (Structured Specifications)
•
구조적 자연어는 요구사항을 자유롭게 작성하지 않고 표준화된 방식으로 작성하는 시스템 요구사항의 한 방법이다.
•
자연어의 대부분의 장점을 살리면서도 어느정도의 통일성을 부여할 수 있다.
•
변동성을 줄이고, 요구사항을 더 효과적으로 구성 가능
유스케이스 모델
그래픽 모델과 구조적인 글을 이용하여 사용자와 시스템 사이의 상호작용을 설명하기 위한 방법
•
시스템의 행동을 모델링
유스케이스 구성 요소
1.
유스케이스: 시스템이 수행하는 기능
2.
액터: 시스템과 직접 상호작용 하는 모든 것
3.
연관: 유스케이스와 액터 간의 관계
유스케이스 간의 관계
1.
일반화 (Generalization)
2.
포함, 확장 (Include, Extend)
소프트웨어 요구사항 문서
•
시스템 개발자가 구현해야 하는 것에 대한 공식적인 용도
•
시스템에 대한 사용자 요구사항과 시스템 요구사항에 대한 상세 명세를 포함할 수 있다.
•
애자일 기법에선 공식 문서를 사용하지 않고 사용자 요구사항을 점진적으로 수집해서 카드에 작성 + 짧은 사용자 스토리로 칠판에 기록하는 방식을 이용한다.
요구사항 검증
요구사항 검증 (Requirements Validation)
•
요구사항이 고객이 정말 원하는 시스템을 제대로 정의하고 있는지를 점검하는 과정이다.
•
요구사항 문제를 수정하는 비용은 설계나 구현 오류를 수정하는 경우에 비해 매우 크다.
요구사항 점검 방식
1. 유효성 점검
사용자의 실제 요구를 반영하는지 점검
2. 일관성 점검
문서 상의 요구사항은 서로 상충되지 않아야 한다.
3. 완전성 점검
시스템 사용자가 의도한 모든 기능과 제약을 정의하는 요구사항을 포함해야 한다.
4. 실현성 점검
기존 지식과 기술을 사용하여 주어진 예산으로 구현이 가능한지 점검
5. 검증 가능성
시스템이 각 요구사항을 만족시키는지 보여주는 테스트를 작성 가능한지 점검
요구사항 검증 기법
1.
요구사항 검토 (Review)
2.
프로토타이핑 (Prototyping)
3.
테스트 케이스 생성 (Test case)
요구사항 변경
요구사항이 변하는 주요 원인
•
시스템의 비즈니스와 기술적 환경은 계속 변화한다.
•
개발 비용을 지불하는 사람이 시스템의 사용자가 아니다.
•
대규모 시스템은 서로 다른 요구사항과 우선순위를 가진 다양한 집단이 관여하기 때문이다.
공식적인 요구사항 관리 프로세스가 필요하다.
•
요구사항 변경으로 인한 영향을 평가
•
개별 요구사항을 추적하고 연관된 요구사항들 간 관계를 정리
•
애자일 프로세스에서는 개발 과정에서 변경되는 요구사항을 처리하므로 공식적인 변경 프로세스가 없다.
요구사항 관리 계획
어떻게 개선되어가는 요구사항을 관리할 것인지에 관한 것
요구사항 변경 관리
1.
문제 분석 및 변경 명세
2.
변경 분석 및 비용 산출
3.
변경 구현
추적 가능성 (Traceability)
•
요구사항 출처, 요구사항, 시스템 설계 간의 관계를 추적할 수 있어야 한다.
•
변경의 이유와 출처를 관리한다.
•
제안된 변경이 시스템의 어떤 부분에 영향을 주는지 분석한다.
