Ch04. 요구공학

▶4주차 필기 내용

Ch04. 요구공학

[요구사항] : requirements

-시스템이 제공하는 서비스(기능적 요구사항)와 서비스에 대한 제약조건(비기능적 요구사항)

[요구공학] : requirements engineering

요구사항 도출, 분석, 문서화, 점검 프로세스

 

[요구사항의 유형]

▶사용자 요구사항

-사용자 대상 고수준 추상적 요구사항

-자연어와 다이어그램 활용하여 사용자 위해 작성

▶시스템 요구사항

-시스템이 제공해야 할 내용을 ’상세하게‘ 기술한 요구사항

-시스템의 기능, 서비스, 제약조건을 구조화한 문서로 작성

▸시스템 이해당사자 - 시스템의 영향 받는 사람 - 사용자, 시스템관리자, 시스템 소유자, 외부 이해당사자 등

 

[타당성 조사] (***) | Feasibility studies

-요구공학 프로세스 초기의 짧은 기간 동안 진행

-타당성 조사 목적

-시스템이 조직 전체 목표에 기여?

-시스템을 기한 내에 주어진 예산으로 현재의 기술 이용해서 구현 가능?

-시스템을 사용되고 있는 다른 시스템과 통합 가능?

-시스템이 기술적/재정적으로 타당한지 평가하여 프로젝트 진행 여부 결정

---

   4.1 기능적/비기능적 요구사항

▶[기능적 요구사항]

-시스템이 제공해야 하는 ’서비스‘

-시스템이 특정 입력 상황에 어떻게 반응/행동하는지

-시스템이 무엇을 해야하고 무엇을 하지 말아야 하는지 명시적 기술

▶[비기능적 요구사항]

-시스템이 제공하는 (서비스)기능에 대한 ’제약조건‘

-개발 프로세스, 표준에 대한 제약조건

-개별 특징이나 서비스 < 시스템 전체에 적용되는 경우 多(창발성)

<도메인 요구사항> p,100 -응용 도메인에서 주어진 새로운 요구사항 or 기존 요구사항에 대한 제약조건 -소프트웨어 엔지니어는 도메인을 잘 이해 못할 가능성 O

 

[1. 기능적 요구사항]

▸시스템이 무엇을 해야 하는지 나타냄

▸시스템의 기능(functionality)나 서비스를 기술

      ▸[기능적 ’사용자‘ 요구사항]

-시스템이 무엇을 해야 하는지 고수준으로 기술

      ▸[기능적 ’시스템‘ 요구사항]

-시스템 서비스 자세하게 기술

▸EX) Mentcare 시스템의 기능적 요구사항 예시 -사용자는 예약 내역 검색 가능 -각각의 클리닉에 대해 당일 방문 환자 리스트 생성 가능 -8자리 직원 번호로 직원 구분 가능

 

▶요구사항 명세의 부정확성

: 모호한 요구사항은 사용자, 개발자가 서로 다르해석 가능해서 분쟁 가능

▶요구사항 완전성

: 필요로 하는 모든 서비스와 정보가 정의되어야 함

▶요구사항의 일관성

: 충돌, 모순되는 요구사항 없음

▶이상적 요구사항 : 완전성 + 일관성

-현실적으로 불가능

 

[2. 비기능적 요구사항]

▸시스템 제공 특정 서비스(기능)가 아닌 요구사항을 의미

-시스템에 대한 명세나 제약조건

-신뢰성, 응답시간, 메모리 사용량 등 ’창발적‘(emergent) 시스템 속성과 관련된 제약

-I/O 장치 성능, 다른 시스템과 인터페이스에 사용되는 데이터 표현 등 시스템 구현과 관련된 제약

▸비기능적 요구사항 만족되지 않는 것이 (기능적 만족X 보다) 심각할 수 O

▸비기능적 요구사항은 특정 컴포넌트 < 시스템 전체 아키텍처에 영향을 받음

 

[비기능적 요구사항 분류]

▶제품 요구사항

-소프트웨어의 실행시간 동작에 대한 제약조건

-성능(속도, 용량), 신뢰성(고장률), 보안, 사용성 등

▶조직 요구사항

-고객과 개발자 조직의 정책, 절차로부터 오는 요구사항

-운영 프로세스, 개발 프로세스, 개발환경, 프로세스 표준, 운영환경 등

▶외부 요구사항

-시스템과 개발 프로세스 외부로부터 오는 광범위한 요구사항

-규제, 법률, 윤리 등

 

[요구사항 목표]

▶비기능적 요구사항 문제는 이해 당사자들이 일반적인 목표(goal)로 요구사항 제시함

- 사용 편함, 고장 시 시스템 회복능력, 사용자 입력에 대한 빠른 반응 등

▶목표

-사용자의 일반적 의도

-개발자에게 사용자 의도 전달하는데 도움 됨

▶확인 가능한 비기능적 요구사항

-객관적으로 테스트할 수 있는 척도로 표현된 문장

-정량적인 명세로 표현

[비기능적 요구사항 명세 척도]

---

   4.2 요구공학 프로세스

[요구공학 프로세스 활동]

-실무에서는 요구공학 활동들 중첩되어 진행됨

-요구사항 도출(elicitation)

-요구사항 분석(analysis)

-요구사항 명세화(specification)

-요구사항 검증(validation)

---

   4.3 요구사항 도출

[요구사항 도출 프로세스]

-이해당사자들의 업무를 이해하고 시스템을 업무에 활용하는 방식 알아냄

-이해당사자들로부터 응용 도메인, 시스템이 제공해야 하는 서비스, 요구되는 시스템 성능, 하드웨어 제약 등을 알아냄

[요구사항 도출 프로세스 활동]

- 요구사항 발견 및 이해

- 요구사항 분류 및 구성

- 요구사항 우선순위 지정 및 협상

- 요구사항 문서화

[관점] Viewpoints -관점 : 공통점을 가진 이해당사자 그룹으로부터 요구사항을 수집하고 구성하는 방식 -요구사항 분석을 위해 이해당사자 정보를 조직화 : 이해당사자 그룹이 하나의 관점을 가졌다고 간주하고 해당 그룹이 가진 관점으로부터 요구사항을 수집 -도메인 요구사항이나 타 시스템 관련 제약조건을 나타내는 관점을 포함시킬 수 O -상이한 이해당사자들은 요구사항의 중요도와 우선순위를 다르게 생각

 

[1. 요구사항 도출 기법]

▶제안된 시스템에 대한 정보를 찾는 방법

-다양한 유형의 이해당사자, 기존 시스템에 대한 지식, 문서

▶요구사항 도출을 위한 주요 기법

    1) 인터뷰

    2) 관찰 or 문화기술적 연구

  (1) 인터뷰

▶[인터뷰 유형]

-폐쇄적 인터뷰: 미리 정의된 질문 목록 있음

-개방적 인터뷰

▶[인터뷰의 문제점]

-도메인 전문 용어는 비전문가가 이해하기 어려움

-전문가는 어떤 도메인 지식은 언급하지 않음

   (2) 문화기술적 연구

▶[문화기술적 연구]

-운영(동작) 프로세스를 이해하고, 이와 같은 프로세스를 지원하는 소프트웨어의 요구사항을 얻기 위해 사용하는 관찰 기법

▶문화기술적 연구가 효과적인 경우

-실제 일하는 방식으로부터 얻을 수 있는 요구사항

-협력과 다르사람의 활동을 인식하는 것으로부터 얻을 수 있는 요구사항

▶문화기술적 연구는 프로토타입 개발과 결합될 수 O

▶혁신과 문화기술적 연구

-Nokia는 문화기술적 연구를 통해 새 제품 요구사항을 도출

-Apple은 기존 사용법을 무시

 

[2. 스토리와 시나리오]

▶[스토리와 시나리오]

-특정 작업을 위해 어떻게 시스템을 사용하는지 기술

-무엇을 하는지, 사용하는 정보는 무엇인지, 어떤 시스템을 이용하는지

▶시나리오

-사용자 상호작용이 이루어지는 일정 구간에 대한 사례를 구조적으로 설명

▶시나리오 구성

-시나리오가 시작될 때 시스템과 사용자가 기대하는 것에 대한 설명

-정상적인 사건 흐름에 대한 설명

-비정상적인 사건 흐름에 대한 설명

-동시에 진행할 수 있는 다른 활동에 대한 정보

-시나리오가 끝날 때 시스템 상태에 대한 설명

---

4.4 요구사항 명세

[요구사항 명세]

▸‘이상적으로‘ 요구사항은 시스템의 외부 행동과 운영상의 제약조건을 기술해야 하며

                                               (시스템의 설계와 구현에 대한 사항 다루지 않아야 함)

▸‘현실적으로’ 요구사항에서 설계 정보 완전 제외하는 것은 불가능

-초기 아키텍처 설계가 요구사항 구성하는데 도움이 됨

-대부분의 경우 시스템은 기존 시스템과 상호작용 필요

-비기능적 요구사항 만족시키기 위해 특정 아키텍처 사용해야 하는 경우

 

[1. 자연어 명세]

[자연어 명세 지침]

-표준 형식 만들어 사용

-필수적인 사항과 바람직한 사항 구분하기 위해 일관성 있는 표현 사용

-중요 부분 글자 강조

-요구사항의 독자가 기술적이고 소프트웨어공학 용어를 이해한다고 생각하지 말 것

-가능하다면 사용자 요구사항에 대한 이유를 기록하여 변경 시 활용

-왜 포함되었는지

-누가 제안했는지 (요구사항 출처)

 

[2. 구조적 명세]

[구조적 명세]

-표준 서식 만들어 사용

-표에 구조화된 양식(템플릿) 맞춰서 정보 기입

 

[3. 유스케이스]

[유스케이스 모델]

-시스템 행동을 모델링

[구성요소]

-유스케이스(use case) : 시스템이 구행하는 기능 (기능적 요구사항)

-액터(actor) : 시스템과 직접 상호작용하는 모든 것 (시스템 or 사람)

<관계 표현>

유스케이스 <-> 액터 관계	연관 (association)
액터 간의 관계	일반화(generalization)
유스케이스 간의 관계	-일반화(generalization) -포함(include) -확장(extend)

[4. 소프트웨어 요구사항 문서화] //그냥 넘김

---

   4.5 요구사항 검증

[요구사항 검증]

-고객이 원하는 시스템을 제대로 정의하고 있는지 점검

-요구사항 문제 수정 비용이 >> 설계, 구현 오류 수정 비용보다 매우 크다

[요구사항 검증 기법]

-요구사항 검토(review)

-프로토타이핑(protyping)

-테스트 케이스(test case) 생성

[요구사항 점검 내용]

1) 유효성(validity) : 사용자 실제 요구 반영 여부 점검

2) 일관성(consistency) : 요구사항 상호 충돌, 모순 여부 점검

3) 완전성(completeness) : 사용자가 의도한 모든 기능, 제약조건 포함 여부 점검

4) 현실성(realism) : 기존 지식과 기술 사용하여 주어진 예산으로 구현 가능한지 점검

5) 검증가능성(verifiability)

: 시스템이 각 요구사항 만족시키는지 보여줄 테스트 작성 가능한지 점검

---

   4.6 요구사항 변경

[요구사항 변화 주요 원인]

-시스템의 비즈니스와 기술 환경 계속 변화함

-개발 비용 지불하는 사람이 시스템 사용자가 아님

-대규모 시스템은 서로 다른 요구사항, 우선순위를 가진 다양한 이해당사자 집단이 관여

[공식적 요구사항 관리 프로세스가 필요]

-요구사항 변경으로 인한 영향을 평가

-개별 요구사항 추적하고 연관된 요구사항들 간 관계를 관리

-*애자일 프로세스 : 개발 과정에서 변경되는 요구사항 처리하므로 공식적 변경 프로세스X

 

[요구사항 추적성] : 추적가능성 (Traceability)

▶추적가능성 유지해야 한다. (*******)

-요구사항 출처, 요구사항, 시스템 설계 간 관계를 추적 가능해야 함

-변경 이유와 출처 관리

-제안된 변경이 시스템의 어떤 부분에 영향 주는지 분석

-한 변경으로 인한 파장이 시스템 전체로 어떻게 퍼지는지 추적

[소프트웨어 공학]  한티 미디어 10판 교재