<4> Requirements Engineering

이 글은 시험이 약 4시간 남은 학부생이 중간고사 암기를 위해 적은 글입니다...........내용은 지현박 교수님의 강의자료를 참고하였음을 밝힙니다.

 

 

✔️Requirements engineering이란?

: 고객이 시스템에서 요구하는 서비스와 시스템의 운영과 개발에 대한 제약사항을 설정하는 과정

 

✔️requirement :시스템이 수행해야 하는 작업 (WHAT)

 

1) 사용자 요구사항 : 시스템이 사용자에게 제공해야 할 서비스와 동작상의 제약사항에 대해 자연어와 다이어그램으로 기록한 문장 [고객을 위한 작성]

 Readers: 고객관리자, 시스템 최종 사용자, 고객 엔지니어, 계약 관리자, 시스템 아키텍트

 

2) 시스템 요구사항 : 시스템의 기능, 서비스및 운영 제약에 대해 보다 상세하게 설명한 구조화된 문서 [계약의 일부]

 Readers: 시스템 최종 사용자, 고객 엔지니어,  시스템 아키텍트, 소프트웨어 개발자

 

---

✔️ SW Quality 특성

: 기능 적합성, 성능 효율성, 호환성, 보안성, 사용성, 신뢰성, 유지보수성, 이식성 등

 

---

✔️  기능/ 비기능 요구사항

 

-기능 요구사항 : 시스템이 재공해야 하는 서비스와 특정 입력(특정 상황)에 대해 시스템이 반응하는 방식 + 해서는 안 되는 일 명시 가능 (*정확하게 명시되지 않으면 개발자와 사용자가 다르게 해석할 수 있음)

• 기능 혹은 시스템 서비스를 설명
• 사용자 기능 요구사항 : 시스템이 수행해야 하는 작업에 대한 상위 수준의 설명
• 시스템 기능 요구사항 : 시스템 서비스를 자세히 설명

ex) 시스템을 사용하는 각 직원은 8자리 숫자의 번호로 고유하게 식별된다

 

 

-비기능 요구사항: 시스템이 제공하는 서비스/기능에 대한 제약사항(시간적 제약, 개발 프로세스에대한 제약, 표준 등)

• 시스템의 속성과 제약 조건을 정의 (안정성, 응답 시간 등)
•  프로그래밍 언어 또는 개발 방법 지정
• 정확하게 기술하기 어려울 수 있고, 검증하기 어려울 수 있음

=> 검증 가능한 비기능 요구사항 : 객관적으로 테스트가 가능한 몇 가지 척도 사용(속도, 크기, 신뢰성, 견고성 ,, 등)

 

ex) 고장시간은 어떠한 날이든 5초를 넘어서는 안 된다, 수강신청이 시작되면 동시에 5천 명의 상요자가 접속할 수 있어야 한다.

 

 

-도메인 요구사항: 운영 영역에서 시스템에 대한 제약사항

• 도메인 요구사항이 충족되지 않으면 시스템이 작동하지 않을 수 있음.

*문제점

- 요구사항이 어플리케이션 도메인의 언어로 표현 -> 소프트웨어 개발자가 이해하기 어려움

- 도메인 전문가는 해당 영역에 대한 이해도가 높아 요구사항을 명시적으로 만들 생각을 하지 않음

 

---

 

✔️ 요구사항의 Users

시스템 고객 : 요구사항 명세, 요구사항이 자신들의 요구를 만족하는지 확인 + 변경 요구

관리자 : 시스템 입찰 계획, 개발 프로세스 계획 수립

시스템 엔지니어 : 어떠한 시스템을 개발해야 하는지 이해

시스템 테스트 엔지니어 : 검증 테스트 개발

시스템 유지보수 엔지니어 : 시스템 및 부분과의 관계 이해

 

 

✔️ 요구사항 문서의 구조

_사용자 요구사항 정의 : 사용자에게 제공할 서비스 기술

_시스템 아키텍처 : 예상 시스템 아키텍처에 대한 고수준의 개요를 제공

_시스템 요구사항 명세 : 기능 비기능 요구사항 기술 

_시스템 모델 : 그래픽 시스템 모델 포함

_시스템 진화 : 예상되는 변경 사항 기술, 변경을 제약하는 설계 결정을 피하도록 함.

 

 

✔️요구사항 문서를 작성하는 법 

*자연어의 문제점 : 명확성 부족, 요구사항 혼동 및 통합의 가능성

=> 구조적 자연어 (보완) : 표준 양식이나 템플릿에 따라 작성 [입력과 출력에 대한 설명, 사전 조건과 사후 조건 등]

 

*Tabular specification(자연어 보완하는데 사용) : 표를 이용; 여러 가능한 대체 조치 정의에 유용

 

 

---

 

✔️요구공학의 프로세스 

 

✔️ 이해관계자(Stackholders)

: 최종 사용자, 관리자, 유지 보수와 관련된 엔지니어, 도메인 전문가, 노동자 조합 등

 

-- 요구사항 분석의 문제점들

• 이해관계자들은 자신이 진정으로 원하는 것이 무엇인지 모름
• 이해관계자는 요.사를 자신의 용어로 표현
• 이해관계자마다 요.사 상충 가능
• 조직적 및 정치적 요인이 영향을 미침
• 도중에 변경됨 -> 새로운 이해관계자 등장가능

 

 

✔️⭐요구사항 도출 및 분석 단계

: 요구사항 발견 -> 분류 및 구성 -> 우선순위 정하기 및 협상 -> 문서화

 

 

✔️ 요구사항 도출 방법 

 

1) 인터뷰 

- 폐쇄적 인터뷰와 개방적 인터뷰를 혼합하여 사용

(폐쇄 : 미리 정의된 질문에 대한 응답 / 개방 : 다양한 이슈를 함께 탐색) 

 

*효과적인 인터뷰 : 열린 마음을 가지고 선입견을 피하고 이해관계자들의 말 경청  + 토론 진행

 

2) 시나리오

:  시적 상황 , 잘못된 경우, 동시에 진행할 수 있는 다른 활동에 대한 정보, 시나리오 종료시 시스템 상태에 대한 설명을 포함

 

 

3) Use case 

: 상호작용에서 행위자를 식별하고 상호작용 자체를 설명하는 UML 의 시나리오 기반 기술 / 모든 상호작용을 설명하는 고수준의 그래픽 모델

 

 

✔️요구사항 검증(Validation)

: 요구사항이 고객이 진정으로 원한느 시스템을 정의하고 있는지를 점검하는 과정 --> 수정 비용이 많이 들기 때문에 중요

 

 

✔️Checking

• 유효성 : 고객의 요구를 잘 반영하는가?
• 일관성 : 요구사항 충돌?
• 완전성 : 모든 기능의 포함?
• 실현성 : 주어진 예산과 기술로 구현?
• 검증가능성: 요구사항 확인 가능?

 

✔️Validation technique

1) 리뷰: 고객과 계약 직원의 공식/비공식 리뷰. (정기적으로 이루어져야 함) -> 초기 단계에서 문제 해결 가능

 

2) 프로토타이핑 : 실행 가능한 모델을 사용하여 요구사항 확인

 

 

✔️요구사항 관리 : 시스템 개발 중에 변화하는 요구사항을 관리하는 프로세스 

- 개별 요구사항을 추적하고 종속된 요구사항 간의 링크를 유지해야 함.