요구공학의 이해

회사 내에서 해준 세미나 자료입니다. 발표자료는 아무래도 공유할 수 없을 것 같아서, 제가 정리한 자료만 올려 놓습니다. 이래도 되려나?

요구사항 개요

-       성공적인 SW 개발이란

n  정해진 시간과 비용 내에서 고객의 실제 요구사항을 만족시키는 품질의 제품을 제공하는 것

n  위의 정의는 우리에게 불행

1.      시간이라는 부분이 타이트 해진다.

2.      고객이 요구하는 비용이 낮아진다. à 과다경쟁으로 인해 비용을 절감(이 말은 인권비를 줄인다.)

3.      그러나 품질에 대한 요구사항은 더 복잡해진다. 결국 이러한 문제점들은 시간이 흘러 사업을 하면 할수록 손해를 보는 상황이 만들어질 수도 있게 된다.

n  그래서 나온 것이 재사용을 높이고, 재작업을 줄이는 CBD라는 개발 방법론이 나오게 되었다.

n  요구사항이란

1.      우선 소프트웨어란 사람이 하던 것을 컴퓨터가 대신하게 함

2.      과거에는 그 일을 하는 사람에게 물어보면 되었다. 그러나 지금은 그렇지 않다.

3.      그러하기에 “과연 고객은 목적을 제대로 아는가? (고객은 모른다.)” 라는 관점에서 시작해야 한다.

n  고객이 “실제” 요구사항 à 고객은 모르는 상태에서 의사결정권자 또한 아니다.

n  내가 어떻게 생각하느냐에 따라, 내 행동도 그렇게 나온다.

사람마다 다른 생각, 행동은 사람마다 다른 결과가 나온다.

n  품질 à 고객이 만족하는 것. 그러나 고객이 만족하는 포인트가 다를 수 있다.

1.      (문서를 작성할 때) 우리가 쓰는 “목적”이라는 단어의 의미는?
à 단순히 단어의 조합인지, 실제 고객을 만족시키기 위한 목적인지를 확립해야 한다. 그래서 명확한 목적이 필요하다.

2.      여기서 잠깐, 개발자의 성향은 잘하고 싶은 욕구가 있다. 그런데 과연 이것이 도움이 될 것인가? 화가 될 것인가?

l  프로젝트에 도움이 되기 위한 전제조건: 팀워크가 좋다면

l  그것이 아니라면 화가 된다.

l  프로젝트는 개인이 잘한다고 되지 않는다. 팀워크가 좋아야 한다.

n  현재 개발프로세스의 관심 흐름은
(과거) 요구사항 à UML à TEST à 요구사항 (현재)
다시 회귀하고 있다.

n  S/W개발의 실패 요소로 인해서 요구공학이 나옴

 

-       S/W 개발 시 발생되는 현상들

n  계획: 일정과 인력이 정해지면 이를 효율적으로 관리하기 위해 필요한 것

1.      현실에서 계획이라는 단어는 부정적으로 받아들여진다.

2.      그러나 필요하다.

n  전 세계적으로 가장 많이 사용하는 개발 프로세스는 Code & Fix. 우리는 Copy & Paste

n  컴퓨터에게 장애란? 뭘 써야 할지 모를 때. 그러기 때문에 컴퓨터에게 코드 한 줄, 한 줄 모두 중요하다.

n  요구사항의 부족한 이해

1.      개발자는 변경(고객의 마음)에 민감하다.

l  변경은 곧, 재작업이다.

l  만드는 건 오히려 오류가 적다. 고치는 건 오류 발생 확률이 높아짐

n  실제 장애가 발생하면 편법으로 고친다. à 잠재적 오류를 만들게 된다.

n  그리고 실제 변경을 기반으로 한 작업이 많다. 이 말은 곧, 제한적 요소가 많다.

 

-       요구사항이란 무엇인가

n  실제 요구사항을 끌어내는데 가장 중요한 것은 communication!
à 말(대화)가 중요하고, 그 다음은 심리.

n  명확하지 않은, 제대로 되지 않은 고객의 요구사항과 생각들
à 그래서 우리는 알아서 개발하게 된다.

 

-       요구사항의 정의

n  요구사항: 내(개발자)가 만들어야 하는 것

n  내가 가진 생각은 보편적이라고 생각한다. 그래서 상대방도 당연히 알고 있을 것이라 여긴다.

n  최근에 요구사항의 정의는 고객이 무엇이 필요한지를 알아가게 하는 과정이라 정의한다.

n  우리나라 고객의 요구사항에 대한 특이점

1.      우리나라 사람은 두리뭉실 말함(문화적 특징).

2.      (무엇을 해야 하는지 정확히 알지 못하기 때문에)시간이 흘러 생각이 구체화 되었을 때 말한다. à 후 폭풍을 일으킨다.

3.      그래서 변경이 생긴다. 결국 시간이 부족해진다.

 

-       요구사항의 진화과정

n  모든 것은 Problem으로부터 시작한다.

n  만들어질 것의 배경을 이해해야 한다. 배경에 대해 모르면 변경에 대한 범위가 넓어진다.

n  ‘왜 저게 만들어지는가?’라는 의심부터 해야 한다.

n  Problem à Needs à Features(기능)

1.      Feature vs. Function

l  로그인은 Function일까? Feature일까?
à Function이다. 로그인은 무엇인가에 가치를 주지 않는다.

l  Feature은 하나만 존재해도 그것만으로 가치가 있다(대상이 의미가 있다.).

n  개발할 때의 시발점은 Features를 정의하는 것부터 시작한다. à 내가 만들 것의 전체를 정의하는 것.

n  소프트웨어란 내가 만드는 것이 무엇인지를 정의하는 것부터 시작한다.

 

-       요구사항의 중요성

n  요구사항은 일에 대한 양을 결정한다. 이 양은 프로젝트를 계획하는데 기반이 된다.

n  요구사항의 변경은 시간이 흐를수록 비용이 늘어난다. à 시간이 더 필요해짐

1.      외국의 경우, 코드 수정. 앞 단계의 요구사항 문서 변경 등의 비용이 든다.

2.      그러나 우리나라는 코드만 수정한다. 문서 수정은 안 한다. 결국 더욱 큰 문제가 발생하고, 비용이 더 든다.

n  개발이란 내가 결정한 의사를 구체화하는 과정

n  우리에게 설계문서란

1.      과연 내가 만든 설계를 다른 사람이 보고 “똑같이” 만들 수 있나?

2.      내가 만든 문서는 내가 기억하지 못하기 때문에 나중에 참조하기 위해 만드는 것이다.

n  코드: 컴퓨터를 위한 것. 사람이 보기 위한 것이 아니다.
내가 단 주석은 주석을 달았을 때의 시점과 나중에 볼 때의 시점이 달라진다.

 

-       요구사항의 속성

n  사람이기 때문에 변경이 생긴다.

n  출발은 모호한 곳에서 시작해서 구치화하는 것

 

-       요구사항의 진화와 변경

n  우리나라는 분석, 설계, 구현을 같이 하기 때문에 문제가 된다. 그러하기 때문에 분석, 설계를 하기 위한 시점을 정해야 한다.

n  고객 지식과 정보의 진화

1.      왜 고객의 변경사항은 진행 후반에 나오는가?
à 분석 단계에서 고객의 요구사항(≒변경사항)을 끌어내야 하는데 그러지 못했기 때문이다. 결론은 정보의 전달이 중요하다.

n  고객은 “모른다.”라는 전제하에 시작해야 한다. 그래서 고객을 Leading하게 하는 것이 중요하다.

n  기술뿐만 아니라 비즈니스적으로 아는 사람이 되어야 한다. à 고객의 요구사항 뿐만 아니라 내 경험, 경향 등도 중요하기 때문이다.

n  사람이 진행하는 업무는 딱딱 나눌 수 없다. à 연결이 된다.
그래서 대화(Communication)가 중요하다.

n  재작업 à 시간이 촉박해진다. à 오류를 발생 à 오류 수정(재작업)

 

-       요구사항 vs. 기대사항

n  Gap이라는 문제

1.      오래 버틴다(연관겅) à 만족을 주어야 한다.

2.      만족을 주기 위해서는 [요구사항 + α]가 필요하다. 여기서 α는 일이 늘어남을 의미한다.

3.      실무자가 제일 싫어하는 관리자는 무조건 Yes라 말하는 Yes Man

4.      결론은 무조건 좋은 것이 좋은 건 아니다. 적절한 시간, 계획이 되어 만드는 것이 중요하다.

l  여기서 계획은 내가 일할 수 있는 buffer를 말한다.

l  이러한 buffer는 과거의 정보(시간, 경험)를 통해서 계획할 수 있다.

 

-       명시적 요구사항 vs. 묵시적 요구사항

n  문제가 되는 건 본인 위주의 개발(내가 아는 범위 내에서)에서 생긴다.

n  고민을 먼저 하는 습관이 중요하다.

n  명시적: 고객의 요구사항 / 묵시적: 실제 만들어야 하는 것

 

-       요구사항 도출 과정

n  개발 관점에서는 제품 요구사항의 정의가 더 중요하다. à 실제 만들어야 하는 때문에

n  분석, 설계: 내가 해야 될 것들을 체계적으로 정리(정의)하는 것

n 

1.      Interface

l  최근에는 연결점이 필요해져 Interface도 필요해짐

l  신호/정보가 왔다 갔다 하는 것

l  ex) 함수를 호출한다. à 내부적으로 interface 작업

 

-       요구사항 구분

n  기술적 요구사항

1.      Functional

2.      Non-Functional

l  우리가 만든 S/W가 제대로 동작하기 위한 조건

l  굉장히 기술적인 이야기 à 제시를 해주어야 한다(빠져나갈 수 있는 구멍을 만들 수 있다(좋은 뜻인가?).

3.      상황에 따라 Functional이 중요할 수도, Non-Functional이 중요할 수도 있다. à 누가 먼저 정보를 선점하는가가 중요하다.

 

-       Non-Functional 요구사항

n  Maintainability: 유지보수성을 높게 고려한다.

1.      모듈화 시킨다. à 변경이 생길 경우, 변경을 용이하게 한다.

2.      모듈화: 변경되지 않고, 재사용이 가능해야 한다.

 

-       요구공학

n  요구공학 도출 – 과거에는 도출(능동적)이 아니라 수집(수동적)이었다.

n  요구사항 관리에는 변경, 추적 관리도 포함되어야 한다.

n  요구사항 개발이 제대로 되야 요구사항 관리에 의미가 있다. à 그래서 요구사항 개발과 요구사항 관리 둘 다 중요하다.

 

-       요구공학의 목적과 목표

n  실패할 확률을 줄여준다. 하지만 성공과는 관련이 없다.

n  QA(Quality Assurance)

1.      Test, 형상관리 – 부가적인 작업이나 없어서는 안 되는 것

 

-       요구공학 측면에서의 개발 프로세스

n  명세: 문서를 쓴다(활자. 인류가 발전하는 근간이 된다.).

n  문서는 내가 짠 코드의 정리가 아닌 누군가에게 내 정보를 전달하기 위함이다.

 

-       요구사항 품질과 시스템의 품질과의 관계

n  개발 프로세스: 일하는 방식

n  요구사항 품질: Correct, Unambiguous, Complete, Consistent, Ranked for importance and stability, Verifiable, Modifiable, Traceable, Understandable

 

-       요구사항이 높은 품질을 갖기 위한 조건

n  Correct(명확하다.)

1.      두 사람에게 정보를 전달했을 때, 똑 같은 의미로 받아들이면 됨

2.      명확하지 않으면, 그 아래 조건들을 만족할 수 없다.

n  Consistent

1.      쫑나면 안 된다.

2.      혼자서는 되는데 합치면 안 된다. à 의사소통이 이루어지지 않아서 그런 거다.

n  이걸 왜 적었나 모르겠지만, 기능성이 높으면, 쓰기 어렵다.

n  Ranked for importance and stability(개발적 관점)

1.      우선 순위를 정한다.

l  어려운 것부터 해야 시간 관리가 쉽다.

l  어렵다는 것은 예측이 안 된다. 또한 협상의 여지가 안 생긴다.

n  Understandable(이해 가능하다.)

1.      표준, 양식이 필요하다. 필요한 부분을 찾기 쉬어진다.

 

-       슬라이드와 상관없이 강의한 내용임돠

n  분석이란

1.      내가 만들어야 할 것을 찾는 것.

2.      동작하는 것을 찾는 것

3.      What에 대한 관점

n  설계란

1.      How(What의 묶음이 How가 된다.)

2.      어떻게 나누어서 만들 것인가.
나누다 à 아키텍처 à Framework

n  그런데, 사람이 하는 일을 정확히 나눌 수 없다. 그래서 Modeling이 나옴

 

-       요구사항 분석 단계

n  고객이 필요한 것을 알려주는 과정

 

-       요구사항 분석 단계에서 이루어지는 활동

n  얘를 왜 만들어야 하는지? 어떻게 만들지 생각해야 한다.

n  실질적 Process

1.      고객의 요구사항 수립

2.      고객 요구사항 정리

3.      제품 요구사항 도출(기능정의, 묵시적 요구사항 정의, 인터페이스 정의, 제약사항 정의)

4.      분석

 

-       요구사항 도출 기술

n  인터뷰

1.      의사소통이 중요하다.

2.      S/W 개발의 시점은 대화에서 시작한다.

3.      그러나 개발자는 보통 방어적이 된다. à 본인은 모른다. 주변 사람은 다 안다.

n  설문

1.      결정하기 어려운 경우를 고객에게 떠넘김

2.      결과적으로 숫자로 나오는데, 사람은 숫자에 대한 믿음을 가지게 된다. 그래서 위험하다.

3.      그러나 설문의 장점은 조작이 가능하다.

n  브레인 스토밍

1.      아이디어를 모아서 분류한다. 그리고 다시 분류하는데 생각을 집중하게 만드는 장점이 있다.

n  스토리보드 & Prototyping

1.      보여줌으로써 기능을 명확하게 상상할 수 있게 해준다.

2.      Prototyping

l  상호작용적 스토리보드

l  하지만 시간이 없다.

l  그래서 기존에 보여줄 수 있는 예제가 있을 때 그것을 이용한다.

3.      컨셉을 어떻게 정하는지에 따라 선택한다.

l  수평적: 전체적 흐름을 보여줄 때. 처음 시작할 때 사용한다.

l  수직적: 하나의 특정적 부분을 집중해서 보여줄 때. 개발자 고객 모두 기본적인 지식이 있을 때

n  결과적으로 방향성(우리가 원하는 방향으로)을 어떻게 잡느냐가 중요하다. à 비교대상을 만들어서 같이 보여준다.

 

-       약간의 잡답

n  모든 문제는 내가 생각지 못했던 곳에서 문제가 생긴다. 그래서 팀워크가 필요하다.

n  분석

1.      What if를 얼마나 많이 생각하는지가 중요

2.      정답은 없지만 찾아보는 것이 중요

 

-       요구사항 정리과정

n  장애 정보를 모아서 수집하는 기능 à 정보를 쌓으면 활용해야 한다.

 

-       제품(S/W) 요구사항

n  어떻게 동작(기능. Features)하는지 정의하는 것이 중요하다.

1.      내가 만드는 것의 input / output이 무엇인지를 정의하는 것부터 시작한다.

2.      Features에 대한 차이는 없으나, Function에 대한 차이는 생김

l  각각 하나의 기능에 대해 정의를 내린다. (시나리오 기반)

è  기본 흐름 정의: 반드시 들어가야 하는 기능

è  선택적 흐름 정의: 최근에 이것을 어떻게 끌어내는지가 중요.

l  사람, 환경에 대해 고려해야 함.

l  Exception을 처리 해주어야 함.

3.      Function으로 나눌 것에 대해 고려한다.

n  위와 같은 순서로 분석을 하면, 코딩뿐만 아니라 Test 하기도 수월해진다. (Test Case가 즉흥적으로 만들어지는 것을 막을 수 있다.)

 

-       요구사항 정리 과정

n  인터페이스 정의

1.      정보가 왔다 갔다 함.

2.      기능에 의해서 구현되나, 기능과 분리해서 생각한다.

l  이유:

è  생각하는 관점이 다르기 때문에

è  왔다 갔다 하는 정보가 “무엇”이냐라는 점

3.      고려사항

l  주고 받는 정보의 대상이 무엇인지

l  주고 받는 주기가 어떻게 되는지

l  주는 정보는 무엇인지, 받는 정보는 어떻게 받는지

l  ex) Software <- Interface -> Hardware

4.      인터페이스는 기능에 의해서 정의되다.

l  여기서 기능이란, 인터페이스가 어떤 기능에 의해 작동하는지에 대한 것을 의미한다.

l  Mapping 표를 만든다.

 

-       제약사항

n  개발이란 과정은 선택이다. 그런데 제약사항은 필수이다.

n  선택할 수 없다.

n  미리 결정된 것. 설계 시 반영된다.

n  Mapping 표 만들기

1.     

2.     

n  분석 & 설계

1.      분석이 제대로 되면 모든 기능 리스트가 나온다.

2.      설계가 제대로 되면 모든 소스 코드 리스트가 나온다.

l  어디에서 이 기능을 동작하게 할 것인가를 고려하는 것에서 시작한다. 아래와 같이 Sequence Diagram을 통해 확인할 수 있다.

l  설계에 들어가면 조금 더 구체화 된다.

-       요구사항 분석 단계 활동(1/4)

n  현재 우리의 문제점

1.      코드가 돌아가는 건 분석, 설계를 하고 있다는 것이다. 그러나 그것들을 하는 시점이 문제이다.

2.      일시적인 편안함 때문에, 우리는 비용과 시간이 많이 들게 작업한다.

3.      실제로 우리가 무엇을 하는지 모른다.

n  분석, 설계는 사람의 생각을 체계적으로 정리하기 위한 단계이다. 분석과 설계를 하는 이유는 아래와 같다.

1.      보면서 생각할 수 있는 시간을 가질 수 있다.

2.      고민을 하기 위한 시간을 벌 수 있다. (개발 단계에서 고민하면 시간이 촉박해진다.)

l  고민: 과연 지금 고민하고 있는 것이 지금 시점에 하는 것이 맞는지 생각해봐야 한다.

3.      개발자가 일할 시간을 분산 시킬 수 있다.

n  Agile

1.      개발자를 위한 프로세스가 아니다.

2.      단지 밤새는 것을 줄일 수 있을 뿐이다.

n  분석, 설계는 당연한 것이다. 습관이다.

n  분석, 설계를 잘하면 내가 무엇을 할지 명확해진다.

n  분석 단계

1.      선택 흐름(무슨 일이 생길지 모르는 것들), Exception Handling 정의가 중요하다.

2.      이론상의 실제 분석 단계

l  고객 요구사항을 기반으로

l  우리가 만들어야 하는 기능을 정의

l  기본, 선택, Exception Handling을 정의

l  우리가 구현해야 할 기능들을 정의

n  분석과 설계의 목적은

1.      분석: 어떻게(How)를 만들 것이냐

2.      설계: 무엇(What)을 만들 것이냐

n  무(無) à 유(有) / 기존 시스템 Upgrade

1.      무(無)에서 유(有)를 만들 때는 무엇을 만들지를 고민 à 내가 알고 있는 정보를 기반으로

2.      기존 시스템에서 Upgrade는 어떻게 바꿀지를 고민

l  기존에 있던 문제와 시장에 대한 Trend 를 기반으로 시작,

l  그래서 최근 기업은 기존 상품의 문제를 DB화한다.

 

-       요구사항 분석 단계 활동(2/4)

n  모델링

1.      대규모의 인원이 대규모 프로젝트를 진행함에 있어서 서로 간의 원활한 의사소통을 위한 것

2.      잘 정리하는 것이 중요

3.      회사 내, 팀 내에서 서로 대화만 가능하면 된다. 꼭 표준을 따를 필요는 없다.

 

-       확인(Validation)과 검증(Verification)

n  Validation: 기본적으로 Test 라고 알면 된다.

n  결과론적인 품질(Validation)이 중요하지만, 과정적인 품질(Verification) 또한 중요하다.

n  Test 의 시기에 무엇을 하기는 너무 늦다. 또한 Test 의 시기에 발견된 문제점을 Test 후에 수정하기에는 더욱 너무 늦다. à 그래서 나온 것이 Verification 이다.

 

-       테스트의 구분

n  정적 테스트: 요구사항과 가장 관련이 깊다.

1.      회의, 코드 분석 도구로 확인해 본다.

l  코드 분석 도구를 통한 확인 방법: 알고리즘을 확인할 수 없으나, 개발자의 실수를 확인하는데 도움이 된다. 오픈소스로 있다고 함.

n  동적 테스트

1.      우리가 기본적으로 알고 있는 Test

2.      우리에게 필요한 Test 는 회기 Test à 변경에 대한 Test 를 위해서 필요하다.

n  분석이 제대로 된 전재 하에 Test 가 진행된다.

1.      분석: 팀워크가 중요하다. à 일이 나눠지면, 각각의 작업을 구분하는 것이 아니라 팀원 간에 다같이 고민해야 한다.

n  Test의 의 품질을 나누는 기준

1.      제품에 대한 나의 믿음

2.      Test Case 가 잘 만들어 졌는가 à 분석에 대한 결과물이 제대로 나와야 한다.

n  Test를 체계화 한다. à 일관된 Test 가 있다.

n  Test 는 제품을 잘 알고 있는 사람(개발자)가 해야 한다.

 

-       Inspection 이란

n  회의 의 비효율적인 요소를 줄이기 위해서 만든 것

n  검토의 목적

1.      여기서 검토란, 잘못된 것을 찾아가는 과정이다. 그러나 우리는 해결책까지 찾으려 한다. 이는 시간 낭비이다.

n  잘못된 것만을 찾는 과정이다.

n  동료(Peered) 검토

1.      동료들 각각 찾은 잘못된 것을 통합한다.

n  기록을 철저하게 한다. (회의록을 남긴다.)

n  사전에 검토한다. à Test 하기 전에 해야 한다는 것을 의미한다.

n  여기서 중요한 점

1.      기법이 중요한 것이 아니다. 동료 간의 의사소통이 중요하다.

2.      체계화하여 정리한다.

 

-       Defect 발생 원인

n  Defect 발생 원인

1.      대부분의 개발자는 기억에 의존

2.      내가 한 잘못을 내가 보지 못한다. à 사고가 편향됐기 때문이다.

n  위의 이유로 Defect가 발생한다. 그렇기 때문에 동료 검토가 필요하다.

 

-       역할과 책임

n  Inspection 이라는 기법에서는 만든 사람은 아무것도 하지 않는다. à 사고가 편향될 수 있기 때문이다. 그래서 발표를 주관하는 Reader가 따로 있다.

 

-       Inspection Process

n  Preparation 단계가 중요하다. 이 말의 의미는 미리 검토해 오는 것이 중요하다.

n  이러한 좋은 기법이 우리나라에 보급되지 않은 건, 검토할 만한 이유가 없었기 때문이다.

n  검토할 만한 이유들

1.      코드를 눈으로 보는 것도 의미가 있다. à 원인을 찾을 수 있다.

2.      Test 라는 것은 형상만 볼 수 있다.

3.      Test 가 찾지 못하는 것을 코드를 통해 볼 수 있다.

4.      Cross Training 할 수 있는 기회가 된다. 또한 다른 사람이 무엇을 하는지 알 수 있다.

n  회의는 비싼 작업이다. 어떻게 하면 효율적으로 할 수 있는지 “계속” 고민해야 한다.

n  실제로 검토의 양은

1.      오류가 나왔던 부분

2.      고객의 요구사항 부분

3.      만들기 어려운 부분

4.      신입사원이 만든 부분

 

-       Defect 구분

n  유형을 구분하면 결함을 예방하는데 쓸 수 있다. à 교육을 통해 오류를 해결할 수 있다.

 

-       Inspection 대상 선정 시 고려사항

n  모든 것에는 선택과 집중이 필요하다.

n  너무 일반적인 건 하지 않는다.

 

-       테스트 시나리오 도출

n  선택흐름은 테스트 시나리오가 된다.

n  실제 문제가 생기는 건, 정상적이지 않은 상황이 발생했을 때이다.

n  Test

1.      내가 생각하는 방식에 따라 결과가 180도 달라진다.

2.      잘 돌아가는지 확인하는 과정이 아니다. 결함을 찾는 과정이다.

3.      Test 시간을 줄이기 위해, Test 설계 기법이 나온 것이다.