소프트웨어 공학 (6) Requirement Engineering

Requirement Engineering

---

Planned based approach 중심으로 설명

0. Requirements engineering란?

(1) 고객이 원하는 사항을 듣고 소프트웨어에 대해 기대하는 바와 제한사항을 확인함

(2) 구현해야할 소프트웨어의 기능을 기술해야함

 

1) Requirements

- 소프트웨어가 없는 경우에는 다소 추상적일 수는 있지만 기존에 시스템을 개선하거나 구체적인 숫자를 뽑아낸다면 디테일한 부분으로 다양한 범위를 가진다.

- 특히 planned based에서는 Requirements를 가지고 계약을 진행하기에 Requirements은 매우 중요한 단계다.

- 계약을 맺고 진행하는 부분이기에 변화가 바뀌면 이에 대해 추가적으로 들어가는 사항과 진행 일정 등의 부담을 누가 가질 것인가에 대한 것들도 명시되어있어야한다.

- 사용자가 요구하는 것을 빠짐없이 도출하고 이를 반영해 Requirements를 정의해야한다.

- 기타 후속작업의 기초단계이자 계약서의 기반이 되기에 이를 견고하게 정의하는 것이 중요하다.

- 고객이 소프트웨어에 대한 기대치이기도 하고, 검증해야할 기술적 배경이 되기도 하고, 실제로 구현해야하는 대상이 되기도 한다.

 

 

2) Type of requirements

(1) User requirements

- 유저가 필요한 기능에 대해 자연어로 요구하는 것으로 자연어로 얘기하기 때문에 그림을 그리는 것이 좋다.

 

(2) System requirements

- User requirements을 받아서 어떤 기능을 구현해야하는지 등에 대해 구체화/구조화되어있는 형태로 써야한다.

- 추상적인 유저의 요구를 디테일하게 작성해 개발할 수 있도록 도와야한다.

 

User requirements와 system requirements의 예시

1~3: Function

4~5: Requirements

 

3) 요구사항과 관련된 이해관계자

우리가 만드는 소프트웨어가 고객, 개발자, 시스템 매니저, 시스템 오너, 외부 이해 당사자 등 많은 사람의 요구사항을 반영해야하기에 어렵다.

각 요구사항을 읽는 사람

User requirements는 사용자와 전체적인 이해관계자가 모두 읽음

 

 

 

ex) mental care system에서의 이해관계자

 

Patients, doctors, nurses, medical receptionists는 end-user에 해당한다.

 

 

Agile에서는 문서를 크게 중요하게 생각하지 않고 incremental을 중요시 생각하기에 비교적 plan based approach에서 requirements를 더 많이 중요하게 생각한다.

---

 

 

1. Functional and non-functional requirements

1) Functional ​requirements

(1) 개념

- 기능적이나 서비스에 대한 요구사항으로 하지 말아야할 것들에 대해 명시를 해놓기도 한다.

- 클래스, 메소드 등

- 분쟁 시 계약서가 될 수 있기에 공학적으로 명쾌할 수 있고, 구체적으로 이를 작성해야한다.

 

예시

점점 디테일하게 작성하는데 search를 어떻게 해석하느냐가 중요하다. 따라서 아래의 문제가 발생할 수 있다.

 

- search에 대한 고객과 개발자의 정의가 다르기 때문에 구현하는 기능의 차이가 발생할 수 있다. 따라서 디테일하게 기능에 대해 작성하는 것이 중요하다. 

 

(2) 요구사항 작성 시 주의사항

요구 사항을 작성할 때는 다음과 같은 원칙을 지키는 것이 중요하다.

i) Complete

- 아주 디테일하고 명확하게 작성해야한다.

 

ii) Consistent: 

- 각각의 요구사항간에 충돌이나 모순이 발생하지 않도록 작성해야한다.

 

하지만 위의 사항을 만족시키기는 어렵기때문에 사람 간의 대화, 숨은 의미를 찾는 등 면밀하게 볼 필요가 있다.

 

 

 

2) Non-Functional ​requirements

- 조금 더 상위레벨에서의 요구사항으로서 표준, 개발 프로세스 등에 대해 요구사항으로 적어놓기도 한다.

- 정성, 정량적인 만족 수치 등을 정할 수 있기에 추상적인 내용만 얘기하는 것은 아니다.

- 시스템의 개별 기능보단 법규, 제한조건, 보안, 신뢰성, 반응 시간, 용량, 개발 도구, 개발 프로세스, 개발 언어, 개발 방법론 등 포괄적인 내용을 담고 있다. 

 

Non-Functional ​requirements 예시

 

 

- 단일 세부 기능에 초점을 맞추지는 않지만 지켜야하는 무언가를 명시했기에 새롭게 기능을 구현해야할수도 있고, 인증을 받거나 법규 등을 준수해야할 수 있다.

 

(1) Product requirements

- 실행시간, 신뢰성(정해진 시간 안에 오류가 있으면 안된다.) 등에 대해 product에 대한 요구사항

 

(2) Organisational requirements

- 회사가 준수하는 소프트웨어 개발 프로세스 표준이나 도구 등의 요구사항

 

(3) External requirements

- 법규, 단체 인증 등과 같은 외부적으로 준수해야하는 요구사항

 

 

예시)

downtime: 멈추거나 오동작하는 시간

 

3) Domain requirements

- 언급은 안되지만 일반적으로 해당 분야에서는 반드시 해야하는 것들에 대한 내용이다.

 

4) 요구사항의 목표

- non-functional 경우 구체적으로 작성하는 것이 어렵지만 목표(원하는 것)를 확실하게 정하고 이를 검증가능하게 바꿔서 도출하는 것이 도움된다.

 

예시)

- 고객의 요구사항을 조금 디테일한 목표로 바꾸고 이를 검증가능한 non-functional requirements로 바꿔 구체적으로 작성한다.

- 공학은 정량적으로 수치화하여 체크하는 것이 좋기에 다음과 같은 정량적인 목표를 뽑을 수 있다.

 

목표에 대해 정량적으로 측정할 수 있는 지표

 

 

 

2. Requirements engineering processes

 

---

3. Requirements elicitation

1) Requirements elicitation

- 요구사항을 도출하고 많은 이해관계자를 확인하고 이를 분류하여 군을 만드는 작업을 한다.

- 이후 요구사항 간에 충돌이 발생할 때나 일정 상에서 우선순위를 따지고 협상을 진행한다.

- 그리고 요구사항을 명세화한다.

- 문서를 만들어가며 spiral 형태로 반복적으로 requirement를 도출한다.

 

2) 요구사항을 이끌어내는 데의 문제점

- 수많은 이해관계자가 무얼 만들어야할지 모르는 경우가 많기에 이를 명세화하는 게 어렵다.

- 이해관계자의 단어로 얘기하기에 이를 온전히 이해하지 못하면 올바른 기능을 만들지 못할 수 있다.

- 서로 다른 이해관계자의 충돌이 발생한 경우가 있을 수 있다.

- 조직적인 이유롸 정치적인 이유로 요구사항에 나쁜 영향을 미칠 수 있다.

- 이해관계자가 요구사항에 대해 잘 알지 못하는 경우도 존재해 요구사항에 대한 domain에 대해 공부해야한다.

 

3) Requirement discovery

- 요구사항 엔지니어링은 문제를 어떻게하면 효율적으로 문제는 줄이고, 요구사항을 명확하게 도출할 수 있는지 방법론을 제시한다.

 

(1) Interviewing

- 고객을 만나서 어떤걸 원하는지 대화를 나눔

- 인터뷰를 잘하기 위해서는 잘 듣고자하는 의지가 있어야한다.

- 대화가 진척되면 springborard나 제안, 프로토타입을 보면서 얘기를 나눌 수 있다.

- close와 open이 섞이는 경우가 많고, 이해관계자가 어떻게 이해하는지 상호작용하는지가 중요하고 의지가 중요하며 질문리스트나 인터뷰 내용을 기반으로 제안하는 것이 중요하다.

- 이해관계자가 전문성이 있기 때문에 그 정보에 대한 도메인 널리지를 공부하고 가는 것이 중요하다. 또한 본인이 이해했는지도 물어보고 그 분야의 상식적인 내용은 얘기안할수도 있으니까 이를 공부하는 것이 중요하다.

 

[인터뷰의 유형]

i) 오픈 인터뷰

- 미리 정해둔 것이 없이 다양한 것을 편안하게 얘기함

- 아무것도 없을 떄 큰 틀을 얘기하고 싶다면 이를 사용한다.

 

ii) 클로즈 인터뷰

- 미리 정해둔 질문을 인터뷰하는 것

- 기능이나 핵심 원리를 추출할 때는 이를 권장한다.

 

 

 

 

(2) Ethnography

- 고객들이 어떻게 하는지 관찰하는 것

- 사람들이 일하는 것으로부터 요구사항을 끄집어내고, 이해관계자들 간의 협력관계도 이해할 수 있다.

- 현재있는 시스템과 유저의 상호관계는 이해하기 쉽지만 개선점, 이후 개발하는 내용의 상호작용 등을 알기는 어렵다.

- 프로토타입을 사용하는 것이 효과적이다.

- 관찰 및 이해하는 것이 중요하다.

 

 

 

(3) Stories and Scenarios

- 사용자가 이를 사용하는 구체적인 사례 및 활용 예에 집중해 얘기할 수 있는 것을 끄집어낸다.

- 시나리오는 다음과 같은 내용이 추가되어야한다.

 

ex) iLearn 교육시스템에서의 Photo sharing 기능 추가

숙제를 받아서 신문을 읽고, 사진도 찍고, 찾은 정보를 아카이빙해서 공유하고자함 -> iLearn을 활용해 KidsTakePics라는 사이트에 아카이빙하고자 하려고 한다. 이때 초기 가정 / 시스템이 끝난 상황 / 일반적으로 사진을 업로드하기 위한 상황 / 주의사항 / 기타 사항 등에 대한 시나리오를 정해야한다.

 

 

4) Requirements specification

- 문서가 나오는 단계로서 요구사항을 명세한다.

- 유저 요구사항은 이해관계자들가 이해해야하기에 기술적인 정보가 없어야한다.

- 시스템 요구사항은 기술적인 정보가 들어가야한다.

- 계약서에 영향을 미치기에 중요하다.

 

(1) 시스템 요구사항을 잘 쓰기위한 5가지 방법

- 문장에 번호를 달아서 자연어로 사용한다.

- 구조화된 자연어를 사용한다.

- 프로그래밍 언어와 비슷한 슈도코드와 같이 문장으로 위에서 아래로 작성한다.

- 그림으로 그리고 설명을 적는다.(UML, sequence diagram)

- 수학적인 명세를 통해 사용한다.

 

(2) 디자인

- 디자인은 개발을 염두에 두기에 디자인에 대한 것이 시스템 요구사항에 들어가있는 경우가 많다.

- non-functional 요구사항이 명시되어있는 경우에는 디자인에 대한 것이 들어갈 수 밖에 없다.

- 구현에 대한 내용이 언급될수도 있다.

-> 요구사항 정의 단계에서도 디자인 범위를 침범할 수 있다.

 

(3) 요구사항 작성을 위한 가이드라인

- 어떤 기준이되는 format을 정해 이에 맞춰 작성해야한다.

- 다음과 같은 사항들이 있다.

- 필요하다면 요구사항에 대해 추가설명을 작성해야한다.

 

 

(4) 자연어 사용의 문제

- 정확도는 떨어진다.

- 헷갈릴 수 있다.

- 잘 구분이 안되고 서로에 대한 이해도가 떨어진다.

 

 

 

(5) Structured specifications

- 구조화된 자연어를 위주로 작성해야한다.

- 임베디드 컨트롤 시스템에서는 맞지만 agile과는 잘 맞지 않을 수 있다. agile에서는 다른 유연한 방법을 사용하기도 한다.

- 구조화한다는 것은 다음과 같은 것들을 수반해야한다.

 

예시) 3.2에 대한 내용이 문서로 작성됨

대문자로 적혀있는 것은 무조건 작성해야하고 점점 구체화되는 것을 확인할 수 있다.

 

 

 

(6) Tabular specification

- Action부분에 대한 내용을 표로 만들어서 도식화한다.

 

(7) Use cases

- 그림을 그리면서 설명한다.

- UML(unified modeling language): actor가 존재해 시스템과 actor의 관계, actor와 actor와의 관계를 그림으로 푸는 것이 중요하다.

- 이해관계자 중 주요 인물이 등장하고 시스템에 대한 시나리오가 적혀있다.

- user requirements와 system requirements가 별개의 문서로 만들어질수도 있고, 하나의 문서로 만들어질수도 있다. 하나의 문서로 나온 경우에는 software requirements document라고 말한다.

- 무엇을 해야하는지에 집중하고, 구현에 대한 부분은 자제하는 게 좋다.

 

requirements에 대한 규격이 존재하는데 IEEE에 requirements에 대한 기준이 존재하기도 한다.

[IEEE requirements 표준에 대한 내용]

 

5) Requirements validation

- V & V

- agile은 유연하게 움직일 수 있지만 plan based의 경우에는 waterfall 방식이기에 문제가 발생할 수 있다.

- 고객이 원하는 것을 반영해야하는데, 제대로 썼는지 확인하는 과정이 필요하다.

 

(1) 요구사항 검증을 위한 5가지 과정

validity: 고객이 원한 소프트웨어가 맞는 지 확인

consistency: 요구사항이 충돌하지 않는지 확인

completeness: 불충분하진 않은지 확인

Realism: 진짜 가능한지, 비용이 감당 가능한지 확인

Verifiability: 실제로 구현이 됐다 안됐다고 검증할 수 있는지 확인

 

 

(2) 검증에 대한 기술

i) requirements reviews

- 다같이 요구사항을 리뷰하는 과정이 필요하다. 이는 기본적으로 방법론과 관계없이 진행한다.

- 클라이언트와 디자이너, 관련된 사람들이 모두 리뷰를 진행하고 formal, informal 둘 다 가능하다.

 

[리뷰 단계에서 체크해야할 것]

Verifiability: 검증가능한지 확인해야함

Comprehensibility: 누가봐도 이해가능해야함

Traceability: 관련항목 삭제 등의 작업을 위해 번호를 달아서 추적가능해야함

Adaptability: 변화를 받아들이는 것이 가능한지 확인해야함

 

ii) prototyping: 빠르게 요구사항을 만들어봄

iii) test-case generation: 머릿속으로 가상으로 돌려봄

 

 

 

6) Requirements change

- 비즈니스와 기술적인 측면에서의 변화 혹은 법규의 변화는 요구사항의 변화를 이끌수밖에 없다.

- 개발단계에서 변화가 존재하더라도 코드만 바꾸는 것이 아닌 요구사항을 재정의해야할 필요가 있다.

 

(1) 요구사항 관리

- 각각의 요구사항을 관리하고, 요구사항 간의 관계도 관리해야한다.

- 새로운 변화에 따라 요구사항과 요구사항간의 관계도 변하는 사항에 대해 잘 파악해야한다.

 

(2) 요구사항 관리 시 결정해야하는 내용

- Requirements identification: 각각의 요구사항을 분류해야한다.

- A change management process: 변화에 대한 것을 관리하는 프로세스가 있어야한다.

- Traceability policies: 각각의 번호를 정해야한다.

- tool support: 이를 도와주는 도구가 존재한다.

 

다음 사항에서는 요구사항이 변경되어야할 수 있다.

 

(3) 요구사항에 대한 변화를 받아들이기 위한 의사결정 방법

- Problem analysis and change specification: 변화에 대한 명세화

- Change analysis and costing: 변화를 분석하고 비용적인 부분 확인

- Chnage implementation: 구현

 

 

핵심 내용

- 요구사항을 작성하는 것이 요지

- 요구사항 엔지니어링은 중요하다

- 계약서에 해당하는 주요 내용이다.

- 모호성을 떨쳐내야하는데 functional, non-functional 요구사항 또한 존재한다.

- 요구사항 엔지니어링 프로세스를 반복한다.

- 조직적, 정치적으로 다른 얘기를 할 수 있는데 이를 조율하는 것이 중요하다.

- 고객이 요구사항을 제대로 얘기하지 못하는 경우가 있어서 이를 끄집어 내기 위한 여러 방법이 있다.

- 인터뷰, ethnography(관찰) 등의 방법을 통해서 고객에 대한 이해도를 높일 수 있다.

- requirements validation이 매우 중요하다. 이 단계에서는 validity, consistency, completeness, realism, verifiability 등을 확인한다.

- 회사에서는 조직적인 차원에서 요구사항 관리를 한다.