소프트웨어 개발자에게 어떤게 요구사항일까

소프트웨어 개발 중 만나는 여러 문제가 있다. 그 중 하나인 요구 사항을 제시하는 사람과 요구를 분석하는 사람, 두 사람도 모르는 문제. 미지의 영역에 대한 부분에 집중해본다.

개요

개발을 요청하는 사람이 정말 완벽한 체계를 설계 해온다면 개발자는 작업만 하면 된다. 하지만 대부분의 경우 요구 사항을 토대로 실제 요구를 채굴해내어야 한다. 요구 사항은 요구하는 기능 깊숙한 곳에 숨어있다.

그러면 어떡해야하죠..?

요구사항이 들어오면, 그 요구사항의 의도를 파악하고, 확장 가능한 설계로 나누고, 그 설계의 세부 동작을 설정 가능하도록 분석해내어 요구사항을 채굴해낼 수 있다.

요구사항 예시 다섯가지를 확인해보려 한다.

요구사항

1. 기능의 응답시간은 500ms 이하여야 한다.
2. 대화 상자의 배경은 회색이다.
3. 애플리케이션은 몇 개의 프론트엔드 프로세스와 하나의 백엔드 서버로 구성한다.
4. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면, 시스템은 삐 소리를 내고 입력을 받아들이지 않는다.
5. 애플리케이션 코드와 데이터의 크기는 256kb 이내로 작성한다.

첫번째 요구사항

응답시간을 500ms으로 제한하려 한다. 왜 500ms로 설정하였을까? 응답시간은 어디에서부터 어디까지인가? 최악인가 최선인가?

만약 이 값이 어떠한 이유로 변경될 수 있는지 파악한다면, 시스템의 전체적인 적용이 필요한 것인지, 하나의 기능에 필요한것인지도 알아낼 수 있다.

 

두번째 요구사항

대화 상자의 배경 색상을 정의하고 있다. 자 그런데, 회색이 무엇일까? css에서는 grey라고 명시하면 RGB 값으로 808080이 제공된다. 그런데 flutter에서는 grey 라고 하면 머테리얼 템플릿일때 9E9E9E 를 제공한다. 그러면 이제 회색이 무엇인지 물어보러 가야한다.

하지만 색상에 집중하지 않고 rgba 색상을 설정할 수 있도록 해서 결과물을 전달하면 어떨까? 요구사항에 색상을 그대로 적용하면 이 색상을 변경해달라는 요청을 끊임없이 받을 수 있다. 하지만 색상을 직접 결정할 수 있는 인터페이스를 제공한다면 요구사항도 만족하고 회색보다 도전적인 색상을 적용해보기도 좋을것이다.

 

세번째 요구사항

서버의 수량을 제한하는 요구다. 목적이 무엇일까? 정말 하나의 서버를 원하고 있을까? 여러개의 분산 시스템을 사용하지만 하나의 목적으로 동작하므로 마치 하나인것처럼 명시한게 아닐까. 정말 하나의 서버를 의도했다면 우리는 단일 장애 지점(Single Point Of Failure, SPOF) 를 극복하기 위해서는 하나처럼 동작하는 서버가 여럿 필요하다고 설득할 수 있다.

 

네번째 요구사항

'숫자 필드' 에서 소리를 내는 기능을 요청하고 있다. 이 요건을 설계 없이 코드에 구현한다면 텍스트필드는 실제로 소리를 내는 기능과 결합하게 된다. 즉, 기능의 경계가 무너지고 스파게티 코드가 될 가능성이 높아진다는 뜻이다. 그러면 소리를 내면 안될까? 그런 방법은 옳지 않다. 대신 설계 과정을 거쳐서 느슨한 결합을 만들어낼 필요가 있다.

숫자 필드에서 올바르지 않은 값을 무시할 때, 그 무시에 대한 이벤트를 발생한다. 소리를 내는 기능은 그 리스너를 통해 소리를 내도록 처리한다면 요구사항을 만족하며 결합도를 낮출 수 있다. 테스트도 간단해진다.

 

다섯번째 요구사항

애플리케이션의 코드와 데이터의 크기를 제약하는 경우는 정말 명확한 목적이 있는 경우다. 개발자가 먼저 나서서 제안할만한 내용이 요구사항으로 들어왔다면 그 의도를 꼭 찾아야 한다. 256kb는 대체 어디서 온걸까?

게임과 같이 큰 메모리를 사용하는 경우에 OS단에서 하드웨어 스펙을 제한하는 경우에도 발생한다. iBanana 라는 제품에서는 애플리케이션 크기를 256kb 미만으로 사용해야 한다 라는 매뉴얼을 보고서 요구사항이 왔다면, 그 배경에 따라 필요한 제안을 할 수 있다. 예를 들어 이 제품 대신 다른 제품을 사용했을 때의 이점이라던가, iBanana 제조사에서 제공하는 SDK를 통하면 요구를 만족하기 쉽다거나 하는 방식이다.

다시 분석한 요구사항

1. 기능의 응답시간은 최대(최악) 응답 시간을 ms 단위로 설정할 수 있다.
2. 대화 상자의 배경을 rgba 로 설정할 수 있다.
3. 애플리케이션은 프론트엔드와 백엔드 서버로 구성한다.
4. 숫자 필드에는 숫자만 입력받을 수 있고 올바르지 않은 입력은 무시하며 올바르지 않은 입력 이벤트를 발생한다.
5. 애플리케이션 코드와 데이터의 크기는 사용 제품인 iBanana(가칭)의 메모리 제약인 256kb 이내여야 한다.

결론

소프트웨어의 요구사항을 찾아내는 과정은 험난한 과정이 맞다. 이 험난한 과정임을 받아들이고, 요구사항을 채굴하고 추출하는 과정을 통해 제품을 목적에 맞추어 나가보자.