[소프트웨어공학] 4장 Requirements Engineering

*Plan based 기반으로 많이 설명함

 

• Functional(소프트웨어 기능 관련, 구체적) and non-functional(추상적, 개발 전반에 영향을 미치는 요소) requirements
• Requirements engineering processes
• Requirements elicitation(요구사항 추출)
• Requirements specification(요구사항 명세화)
• Requirements validation(요구사항 검증)
• Requirements change(변화에 대한 발전사항)

 

 

Requirements engineering

2가지 측면

-고객이 시스템에 대해 요구하는 것(이루어져야할 부분, 제한사항들을 파악)

-구현해야할 기능적인 측면

 

요구사항

고객이 잘 모르는 부분은 모호함이 있을 수 있음

기존의 시스템 개선, 구체적인 수치를 뽑아내는 측면에서는 굉장히 세세하게 수행해야하는 것이 필요하다.

-요구사항 자체가 계약서가 될 수 있음 세세한 정의가 필요

-해야 하는 일과 들어가선 안 될 일들을 정의한다.

-금액적인 측면에서 누가 그 것을 부담할지도 정해야한다.

>>Plan based 모델에서는 이후 문제 발생에 책임을 따질 때 필요하기 때문에 자세하게 정의할 필요가 있다.

-큰 소프트웨어 개발에서 특히 강조된다.

-사용자가 요구하는 것이 구체적이든 추상적이든 정의하는 것이 중요하다.

>>이게 이후에 계약이 될 것이고 소프트웨어에 대한 규약이 될 것임.

>>이것이 사실상 기술적 계약서가 된다.(기술적인 기반이 된다)

 

요구사항의 종류

>User requirements – 이 소프트웨어를 사용할 사람이 어떤 것들이 필요한지에 대한 요구사항(System requirements의 기반이 된다, 대부분 자연어(말)로 쓰여진다, 덧붙여 다이어그램과 같이 그림으로 표현하는 것이 도움이 될 수도 있다.)

>System requirements(이걸 가지고 구현이 됨) - User requirements를 받아서 이것을 소프트웨어로 구현할 때 어떤 것들이 필요한 것인지 어떤 규칙(제한사항)이 지켜져야 하는 것인지를 명시해놓은 요구사항, 어느 정도 구조화(구체화)되어 있다.

>>각각의 요구사항을 쓴 사람이 다르다는 가정 하에 진행하는 것이 좋다 -> 그래야 좀 더 명시적인 요구사항이 만들어진다.

 

 

사용자 요구사항과 시스템 요구사항을 어떻게 쓰는지?

예제(앞에서 제시한 멘탈 케어 시스템 예시)

1) 사용자 요구사항

한 달 동안 진료소 별로 처방한 약의 가격을 보고 받고 싶다(자연어)

시스템 요구사항(6하 원칙 형태)

1-1) 매달 마지막 일하는 날에 레포트를 만들기로 함, 처방한 진료소에 따라서 처방한약의 가격을 작성한다.

1-2) 그 달의 마지막 날 17:30에 레포트를 만든다.

1-3) 약의 이름과 처방된 약의 개수 어떤 것들을 썼는지 그런 것들을 가격을 포함한다.(좀 더 자세한 내용)

1-4) 투입양이 다른 경우에는 별도의 레포트로 작성을 한다.(ex. 10mg, 20mg, 제한사항이 됨)

1-5) 이러한 정보는 관련된 사람들만 볼 수가 있다.

>>1,2,3 이 기능에 대한 것, 4,5가 제한에 대한 것을 명시한다.

>>위와 같이 넘버링되어 파트별로 구분이 된다.

 

>>각각의 요구사항이 등장하면 각각을 필요로 하는 사람들이 모여서 각각에 대한 개발을 한다. 또한 그러한 사람들의 의견이 반영이 되어야한다.

사용자 요구사항 – 시스템과 관련된 사용자가 문서를 보게 됨.

시스템 요구사항 – 어떤 기능을 구현해야하는지와 관련된 사람들이 보게 됨.

 

요구사항 단계에서 만족시켜야 할 대상은?

>그러한 사항을 요구한 사람 또는 기관

-사용자

-시스템 관리자

-시스템 소유주

-법과 규정들

 

누구를 만족시켜야 하는가?

ex. 멘탈케어 시스템

>환자

>환자의 정보가 저장이 되고 관리가 되어야함

>환자를 보는 의사

>간호사

>환자가 전화로 문의를 했을 때 그러한 정보들을 처리할 행정분

>이러한 소프트웨어를 유지, 관리하는 기업들

>법률 규정 관련(시스템이 윤리적인 요소들을 만족하는지)

>환자에게 도움을 줄 수 있는 단체 사람들

>정보에 대한 보안을 담당하는 사람들

 

>>이러한 사항들을 만족시키지 못한다면 돈을 못 받는 등의 불이익이 돌아올 수 있다.

에이자일 보단 plan based에서 문서적인 요구사항들이 더욱 강조된다.

 

Functional(기능적) and non-functional(제약 조건, 기능 외에 법률적 등등) requirements

 

>Functional requirements(class와 method같은 것들과 연결됨) – 기능적인 측면에서 시스템적으로 하지 말아야 할 것들도 포함한다.

ex. 인공지능 -> 머신러닝, 자율주행 -> 여러 시나리오 정보 >>각각에 해당되는 정보들이 필요

공학적으로 명확하다, 구제적이어야 한다(모호한 부분이 없어야함)

ex. 멘탈케어 시스템

-모든 진료소에 대한 예약 리스트를 검색하고 싶어 함.

-시스템이 진료소 별 날짜별로 예약 리스트를 만들어 오게 만든다.

-시스템의 관리 아이디는 8비트짜리 유저번호/사업자 번호이다.

검색에 대한 인식 오류 예시

환자 : 사용자 이름을 검색하면 전체 클리닉의 리스트가 검색됨.

개발자 : 일을 줄이거나 성능을 올리는 것을 선호하기 때문에 먼저 클리닉을 선택하고 그 상황에서 환자의 이름을 검색하면 클리닉에 해당되는 리스트가 검색된다.

>>따라서 가능한 자세하게 설명되어야 한다.

 

>non-functional requirements(기능을 만드는 것에 있어 제한이 되는 것들) – 기능화된 것들보단 어떤 표준을 따라야한다면 포함되어야할 것들을 가지고 있다.

>>위에 두갠 고객님과 풀어나감

용량, 제한시간, 법률 같은 것들을 명시한다.

개발도구와 같은 것들도 명시된다.

기능이 아닌 전체적인 모습에 기반을 둔다.

ex. 조직에서는 부서, 개발팀, 법구에서는 윤리적 법 관련 그리고 기능 보안 같은 것들이 포함된다.

시스템에 전체적인 영향을 끼칠 수 있다.

Product requirement – 응답시간, 신뢰성과 같은 것

ex. 멘탈케어 시스템

월요일에서 금요일 사이에는 아침 8:30부터 17:30까지 반드시 작동이 되어야한다.

하루에 5초 이상 멈추거나 오류가 발생해서는 안 된다.

Organizational requirement – 그 회사에서 준수하는 프로세스 기준, 구현 요구사항을 만족해야 하는 것

ex. 멘탈케어 시스템

운영적인 면에서 이 멘탈케어 시스템에 접근하는 사람은 인정받은 아이디카드를 가지고 해야한다. (아이디카드가 인증되어 있는 것인지, 정상 발급된 것인지 등에 대한 판단이 이루어져야 한다.)

External requirement – 법규, 규정, 단체 인증 같은 외부적인 것

ex. 멘탈케어 시스템

환자의 개인정보 보호에 대한 규정을 지켜야한다.

>Domain requirements(개발사의 역량) – 언급은 안 되고 있지만 산업군 같은 곳에서 지켜야하는 범위

 

요구사항의 방향성

>Complete(완벽한) - 오해의 여지를 없애기 위해 가능한 자세하게 설명한다.

>Consistent(일관된) - 각 요소들이 서로 충돌되는 상황들이 만들어지면 안 된다.

 

요구사항을 얻기 위해서

-목표를 정한다.

원하시는 것이 무엇인지 -> 편하고 쉬운 시스템

-검증가능하게 바꾸기(검증가능라고 테스트가 가능하게 바꾸기)

편하고 쉬운 시스템 -> 정확히 무엇인가?

 

ex. 멘탈케어 시스템

-의료 관련 직원들이 사용할 시스템을 만들고 싶은데 편하고 쉬운 시스템을 써서 에러를 줄이는 것 (목표)

-이 시스템을 아무런 지식이 없는 사람에게 4시간 교육을 해서 사람들이 2시간동안 시스템을 사용을 해서 얼마만큼의 에러가 발생하는지에 대한 에러발생률을 측정 함.(테스트가 가능하고 비함수적인 요소들로 구성한다.)

공학은 정량적인 수치를 부여하는 것이 명확함을 가져다 준다!!

ex. 스피드 -> 초당 트랜잭션

사이즈 -> 얼마만큼의 바이트가 필요한지

사용하기 쉬움 -> 트레이닝을 얼마만큼 해야하는지

신뢰성 -> 에러가 일어나는 빈도, 에러 시간

호환성 -> 윈도우즈 운영체제의 것이 리눅스에서 적용이 되는지

 

>>요구사항은 계약서에 명시가 되어야하고 이러한 것이 명확하지 않으면 추후에 돈을 못 받는 등의 피해가 생길 수 있다.(사실상 요구사항이 계약서이다!)

 

나선형 모델

>>사용자 요구사항을 도출 -> 스펙화 -> 프로토타입 제작 -> 시스템 요구사항 도출 -> 시스템 요구사항을 규격화 -> 리뷰 -> 시스템 요구사항 문서화(문서)

 

 

 

>Requirements elicitation(요구사항 도출)

요구사항을 찾아낸다!

요구사항들을 유사한 군별로 구분한다.

요구사항의 우선순위부여 그리고 판단한다.

요구사항 명세화(문서를 만드는 것이 중요)

 

요구사항을 도출할 때의 문제들

-실제로 사용할 사람들이 개선되고 발전되어야 하는 것이 무엇인지 모르는 경우가 많다.

-서로 단어에 대한 이해가 다를 수 있음(ex. 검색)

-기능에 대한 충돌들이 발생할 수 있다.

위에 것들은 사람과 대화를 하면 해결 될 수 있음

-조직과 정치적인 이유로 요구사항을 오염시키는 것

-이해당사자(사용자)가 앞으로 변해갈 것에 대한 인식이 없을 수도 있음 -> 개발자가 사용자와의 대화를 통해서 해결해 가야함

 

요구사항을 파악하기 위한 도구들

>인터뷰

인터뷰 종류

-닫힌 인터뷰(미리 정리된 내용을 가지고 인터뷰)

-열린 인터뷰(미리 정리하지 않고 자유롭게 인터뷰하는 것)

>>잘 듣고자 하는 의지가 중요하다!!

>>요구사항을 제안해보고, 같이 프로토타입을 수행해보면서 인터뷰를 진행할 수 있다

>>통상 두 종류의 인터뷰가 섞여서 사용되는 경우가 많다

>>기본적으로 이해 당사자가 시스템과 어떻게 상호작용하는지가 중요하다.

>>설득을 하는 것이 아닌 의견을 듣기 위해 하는 것이다!

>>이전 인터뷰에서 있었던 제안들을 정리해서 설명해본다!

주의사항

>>전문가들과의 인터뷰에서는 특정 영역에서 쓰이는 언어/지식들을 이해해서 가야함

 

>민족지(관찰을 하는 것, 지켜보자, 모니터링)

-말로 물어보거나 하지 않고 그 사람들이 시스템을 어떻게 사용하는지 관찰/지켜보는 것

-이해 당사자 간의 관계를 알아보는 것도 좋다.

문제점

>>현재 상태를 이해하는 방법으로는 적절하지만 어떠한 변화가 나올지 관한 내용은 알기 어렵다.

 

민족지와 프로토타입을 같이 사용

ex. 공항에 비행물체 감시 시스템을 사용함에 있어 보통 꺼두는 경우가 많다.

시스템 자체가 너무 민감하여 오히려 방해가 될 수 있음

>>시스템을 사용함에 있어 정확한 이해가 필요하다. -> 이러한 것을 발견하고 프로토타입을 개발하여 개선점을 찾는다.

 

>스토리와 시나리오기법

-실생활에서 사용하는 구체적인 예에 집중을 함으로써 조금 더 구체적으로 이야기 할 것들을 뽑아냄

-작업에 대한 전후 상황 안에 있는 진행들을 파악해본다.

 

ex. iLearn예시

iLearn 클래스룸에 포토쉐어링 기능을 추가하는 것에 대해서 어떻게 할지를 이야기 해봄

스토리 적어보기

>학생들이에게 과제를 줌 (동내에서 물고기 산업이 어떤 식으로 이루어지는지를 알아보게 함)

-> 학생들이 과제와 관련된 자료들을 찾아봄. -> 앞에서 찾은 자료들을 정리하고 공유하고 싶음 -> 다른 사이트를 이용해 사진을 올리도록 함 -> iLearn과 앞에 나온 사진업로드 사이트가 연동될 수 있도록 setup해줌

iLearn 시스템이 구체적으로 어떤 기능을 해야 할지 시나리오화

-> 시나리오 이름 : 사진공유

-> 초기 상태에서 사용자들은 본인이 업로드할 사진을 가지고 있어야 함 -> 컴퓨터를 통해 업로드 시키니 컴퓨터에 저장되어 있어야함 -> 사진을 업로드할 다른 사이트에도 로그인이 되어있어야 함 -> 사진을 선택해서 업로드함 -> 추가적으로 태그를 붙이거나 이름을 부여함 -> (저장될 때 파일이 어떤 식으로 변환되어 저장이 되는지 개발자에게 명시) -> 사용자가 업로드를 마치면 자동적으로 승인관리자에게 승인과련 메일을 전송함 -> 승인이 되면 업로드가 된다. -> 승인이 됐음을 사용자에게 알려줌(중복을 알려줌) ->마친 상태 : 선택한 사진이 업로드가 되어야하고 승인을 대기해야 한다(승인을 하는 사람에게는 사진이 보여야함) -> 사진이 업로드되면 다른 사람들도 볼 수 있어야함

 

 

>Requirements specification(요구사항 명세화)

어떤 식으로 써야 받을 사람이 이해를 할 수 있을지를 고민

사용자 요구사항 – 고객이 반드시 이해해야 하는 부분, 가능한 기술적인 부분이 배제가 되어야 용이하다

시스템 요구사항 – 실제로 시스템을 개발하는 사람들에게 전달이 될 것이기 때문에 기능적인 부분들이 포함되어야한다.

 

시스템 요구사항의 명세화 방법(뒤로 갈수록 세세해짐)

>자연어(앞에다 넘버링을 함, 문장으로만 표현) -> 사용자 요구사항은 단 번호, 시스템 요구사항은 ‘.’을 찍고 번호가 추가됨.

-넘버링을 하고 다이어그램, 테이블을 사용

-기본 형태를 지킨다.

-너무 어려운 부분은 지양함

ex. 인슐린 펌프 예제

3.2 시스템은 인슐린 펌프를 가지고 인슐린을 투여할 수 있어야 한다. 10분마다 해야한다.(이것보다 커지면 문제가 발생할 수 있음)

문제점

-정확도가 떨어짐

-복잡해지고 구분이 어렵다.

 

 

>구조화된 자연어(구조화된 형태나 탬플릿을 가짐)

이렇게 체계화된 것은 plan based(ex. 임베디드 시스템)에는 맞지만 에이자일과 같은 것과는 맞지 않을 수 있다.

형태를 정한다는 건 -> 다양하게 고려할 것들이 많다.

특정 형태에 맞춰서 만들어야함, 정해진 형태를 꼭 지켜야한다.(예시 page59-60)

- 구조화된 자연어가 너무 글 위주라 표를 만들어서 표현함

 

>설계 묘사 언어(수도코드와 같은 것들로 프로그램 언어는 아니지만 그렇게 보이는 것들로 명세를 한다)

 

>그림(그림을 다루어 표현, 시나리오를 정의하고 그에 따라 그림을 그리는 UML(등장인물 엑터가 존재함, 시스템과의 관계를 보는 것이 중요)을 구성한다, 시퀀스 다이어그램을 통해 시나리오 별로 그림을 그림, 예시 page64)

 

>수학공식(계산이 있다면 사용이 용의, 약속된 기호를 사용해야함)

 

>>대부분 요구사항에서 설계를 언급함

-비함수적인 요구사항이 있을 때 세세한 구조를 생각하면 설계가 언급 됨

-지켜야할 외부의 인증

-다른 시스템과의 연동(이것은 구현까지 언급될 수도 있다)

 

>>결과적으로 요구사항 문서가 최종적으로 만들어 진다.

요구사항은 유저에게 이해를 구하고 허락을 받는 문서이다 -> 따라서 무엇을 하는지에 집중을 하고 구현을 위한 부분들은 자제함

 

 

>Requirements validation(요구사항 검증)

-> 여기는 폭포수 모델을 기반으로 하기 때문에 중요성이 높다

-구현과정의 문제 해결 보다 요구사항의 문제해결이 훨씬 더 많은 소요를 부른다.

 

5가지 관점에서 확인

>>Validity - 당신이 원하던 소프트웨어가 맞나요?

>>Consistency - 충돌이 발생하는 요소가 없어야 함

>>Completeness - 불충분한 부분은 명확해질 필요가 있음

>>Realism – 실제로 가능한지를 판단해야함

>>Verifiability – 우리가 만든 요구사항이 실제로 검증이 가능 한지

 

validation 방법

-읽기(이해하기)

-프로토타입을 만들어 봄

-가상으로 돌려보기(테스트케이스 별로 상황을 그려본다)

요구사항을 리뷰해야 함!

리뷰 확인

>>Verifiability - 확인 가능한지

>>Comprehensibility – 이해가 가능한지

>>Traceability – 만들어진 과정을 추적가능한지

>>Adaptability – 변화를 받아드리는 것도 가능한지

 

 

>Requirements change(변화에 대한 발전사항)

소프트웨어는 변화할 수밖에 없다

-주로 변화하는 것(비즈니스, 기술)

-법규가 바뀌어도 변화가 필요하다

 

변화를 받아드리는 절차도 정해져있다.

변화가 왔다고 해서 그것을 전적으로 수용하지 않음

 

요구사항 관리 계획 4가지

>Requirements identification – 넘버링을 통한 전후관계를 파악함, 각각이 명확하게 식별 가능함

>change management process – 변화 관리 과정이 필요

>Traceability policies – 변화된 곳에 대한 추적이 이루어져야함

>Tool support Tools – 전문 도구가 필요함

 

Problem analysis and change specification – 문제를 분석하고 변화를 구체화함(문서화)

Change analysis and costing – 변화로 인한 어떤 변화가 있을지 분석하고 비용을 산출함(받아드릴만 하다면)

Change implementation – 변화를 구현함

 

삼성SDS, LG CNS와 같은 기업이 사업을 수주할 때 사용한다!

 

4장 요약

- 소프트웨어 시스템의 요구조건은 시스템이 무엇을 해야 하는지를 정하고, 시스템의 작동과 구현에 대한 제약조건을 정의한다.

- 기능적 요구사항은 시스템이 제공해야 하는 서비스에 대한 설명 또는 일부 계산을 수행해야 하는 방법에 대한 설명입니다.

- 비기능적 요구사항은 시스템 개발 및 개발 프로세스의 제약을 받는 경우가 많다.

- 이 기능은 시스템의 새로운 특성과 관련되는 경우가 많으므로 시스템 전체에 적용됩니다.

- 요구사항 엔지니어링 프로세스는 요구사항 도출, 사양 및 검증을 포함하는 반복 프로세스입니다.

- 요구사항 도출은 요구사항 발굴, 요구사항 분류 및 조직, 요구사항 협상 및 요구사항 문서화(requirements discovery, requirements classification and organization, requirements negotiation and requirements documentation) 등 활동의 소용돌이로 표현될 수 있는 반복적 프로세스입니다.

-면접 및 민족지도(interviews and ethnography)를 포함한 다양한 요구사항 도출 기법을 사용할 수 있습니다. 토론을 용이하게 하기 위해 사용자 사례와 시나리오를 사용할 수 있다.

- 요구사항 명세서는 사용자 및 시스템 요구사항을 공식적으로 문서화하고 소프트웨어 요구사항 문서를 작성하는 프로세스입니다.

- 소프트웨어 요구 사항 문서는 시스템 요구 사항에 대한 합의된 설명입니다. 시스템 고객과 소프트웨어 개발자가 모두 사용할 수 있도록 구성되어야 합니다.

- 요구사항 검증은 유효성, 일관성, 완전성, 사실성 및 검증가능성(validity, consistency, completeness, realism and verifiability)에 대한 요구사항을 확인하는 과정이다. -> 마지막 기회

- 비즈니스, 조직 및 기술의 변화는 불가피하게 소프트웨어 시스템 요구사항의 변경으로 이어집니다. 요구사항 관리는 이러한 변경사항을 관리하고 제어하는 프로세스입니다.