Requirements 란?

1. 들어가면서

 

여러분 이 그림이 의미하는 바가 무엇인지 살펴보세요. 이 그림은 요구사항을 파악하여 최종 고객이 원하는 것을 만든다는 것이 매우 어렵다는 것을 설명하는 그림입니다.

 

요구사항 분석의 중요성 및 어려움

밑에 가장 오른쪽에 있는 그림이 정말 사용자가 원했던 것인데, 위의 가장 왼쪽 그림을 보면 사용자 마저도 본인이 원하는 것을 잘 설명 못할 수 있다는 것을 의미하기도 합니다.

또한 요구사항이 잘못 분석이 되거나 요구사항이 잘못 표현되어 있으면 이를 고친다는 것은 엄청 많은 노력이 요구된다는 것을 반증하기도 합니다.

 

이에 대한 사실은 많은 통계 데이터을 통해서도 알 수 있습니다. 개발에 있어서 요구분석이 40%정도를 차지한다거나, 요구사항으로 인한 에러로 수정을 하는 비용이 단순 코드의 에러으로 수정하는 것보다 엄청난 대가를 지불해야 한다는 것을 말입니다.

 

그만큼 개발에 있어서 요구사항의 중요함을 몇 번 강조해도 부족함이 없다고 생각합니다. 사실 저희의 문화에서는 지표를 기반으로 계량적으로 관리를 하는 문화가 아닌, 즉 데이터를 기반으로 분석을 하지 않고 감, 좋은 말로는 insight만을 가지고 일을 하므로 외국의 통계나 자료에 의지하여 요구사항의 중요성을 호소할 수 밖에 없습니다.

 

2. Functional vs. Non-functional Requirements

 

요구사항의 이해를 위해서 가장 중요한 것이 functional requirements와 non-functional requirement로 구분하는 것입니다. 보시는 표는 이 두가지 요구사항 종류에 대한 특징을 나타내고 있습니다.

 

Functional requirements와 Non-functional Requiremens의 비교

Functional requirements는 말 그대로 시스템이 처리해야할 기능에 대한 요구사항으로서 가장 기본적고 필수적인 요구사항입니다. 시스템의 use-case라는 것으로 이해될 수 있으며 what이라는 관점으로 이해될 수 있습니다.

 

Non-functional requirement는 what이 아니라 how라는 관점에서 이해될 수 있으며 시스템의 품질특성과 관련되는 요구사항입니다. 따라서 반드시 정의될 필요는 없으나 시스템의 품질을 좌우하는 요구사항입니다. 다시말해 non-functional requirement는 설계를 위해 고려해야할 요구사항이라고 할 수 있습니다. 그러나 불행히도 Non-functional requirement는 정의하기가 매우 어렵습니다. 그래서 개발 후에 고객과의 분쟁이  가장 많이 발생합니다.특히 non-functional requirements는 정의되지 않아도 당연히 만족해야 할 요구사항이 많아서 코에 걸면 코걸이 귀에 걸면 귀걸이가 될 가능성이 높은 요구사항입니다. 

 

예를 들어, 월실적보고서를 생성이라는 기능적 요구사항이 있다고 할 때, 보고서의 어떤 내용이 들어가야 하는지는 functional requirements에 포함된다고 할 수 있습니다. 그러나 보고서 몇 초 내에 생성해야 하는지, 포멧은 어떻게 이쁘게 만들 것인가와 같은 요구사항은 non-functional requirement에 해당한다고 할 수 있습니다.

 

3. Process vs. Data Requirements

 

요구사항의 이해를 위해서 중요한 또 한가지는 process와 data 요구사항을 구분하는 것입니다. 소프트웨어 시스템은 일을 처리하는 프로세스와 이 프로세스의 대상이 되는 데이터로 크게 구분된다고 할 수 있습니다.

마찬가지로 요구사항도 프로세스와 관련된 요구사항과 데이터와 관련된 요구사항으로 구분될 수 있습니다. 특히 데이터의 요구사항 분석이 잘 이루지는 시스템이 더 안정적이라고 하는 통계가 있을 정로도 데이터는 프로세스보다 중요합니다. 시스템의 데이터모델을 잘 정의하면 시스템이 50% 이상의 요구사항을 파악할 수 있고 시스템을 더 안정적으로 개발할 수 있습니다.

 

그러나 현실에서는 많은 개발자들이 데이터보다는 프로세스를 중심으로 시스템을 분석합니다. 심지어 데이터 분석은 아예 관심을 가지지 않고 프로세스의 추상적 정의만 하고 시스템 분석이 완료된 것으로 오해하고 있는 것이 대부분입니다.

 

Information Engineering에서 기술한 Information system의 2가지 측면

 

4. Hige-level vs. Low-level Requirements

 

요구사항을 이해하기 위해 중요한 또 하나의 개념이 요구사항은 high-level 요구사항과 low-level 요구사항이 있다는 것입니다. 사실 시스템의 개발은 요구사항을 관리하는 행위라고 볼 수 있으며, high-level 요구사항을 low-level의 요구사항으로 구체화하는 것이라고 할 수 있습니다.

 

Requirements Hierarchy

Business requirement는 최상위 요구사항이라고 할 수 있습니다. 왜 이 시스템을 개발하게 되었는가 하는 근본적인 이유를 제시하는 것입니다. 따라서 보통 problem statement에 정의되거나 project vision과 같은 문서에 정의됩니다. 무기체계 관점에서는 ROC(Requiremets of Capability)와 비견 할 수 있을 것입니다.

 

User requirements는 말 그래도 개발자가 아닌 사용자 요구사항으로 business requirements를 달성하기 위해 시스템의 최종 사용자가 원하는 요구사항입니다. 사용자 요구사항은 system requirements를 생성하기 위한 입력의 역할을 담당합니다. 특히 사용자 요구사항은 완전하지 않고, 부정확하며 상호 일치하지 않는다는 특성이 있습니다. 따라서 system requirements가 필요한 이유입니다. System requirements는 사용자 원하는 요구사항을 개발자 관점에서 정의한 요구사항으로 사용자 요구사항에 내재된 오류를 제거하여 정제된 형태로 완전성, 일관성, 정확성 등을 만족하도록 작성되어야 합니다.

 

5. Abstract vs. Detailed Requirements

 

High-level requirements와 low-level requirements와 유사하기는 하지만 조금 다른 관점에서 이해해야 할 구분이 abstract한 요구사항과 detail한 요구사항입니다.

 

컴퓨터과학에서 문제를 해결하는 중요한 원리들이 있는데 그 중에 하나가 abstraction, 즉 추상화입니다.  추상화는 상세한 사항을 숨기고 필요한 사항만 표현하는 방법입니다. 요구사항을 분석하거나 표현할 때, 요구사항을 쉽게 이해하도록 요구사항을 추상화 레벨에 따라 이해하거나 기술하는 것이 필요합니다.

 

Strcuctured Analysis에서의 Requirement Modeling 방법

그림에서 가장 위해 존재하는 원은 대상이 되는 시스템 전체를 의미합니다.. 그리고 주변의 사각형은 시스템과 상호작용하는 외부체계를 의미합니다. 이를 context model이라고 하는데, 이 context model은 시스템의 전체를 표현하기는 하지만 상세한 사항은 표현하지 않고 이 시스템의 외부환경과의 관계를 표현하여 시스템의 범위를 이해하도록 표현합니다.

 

또한 외부환경과의 인터페이스가 무엇인가를 화살표로 표현하고 있으나 상세한 인터페이스는 표현하지 않고 있습니다.

그 아래 그림은 시스템이 크게 3개의 주요 프로세스를 구성되어 있다는 것을 의미하며 이들 간의 데이터의 흐름을 표현하여 위의 context model보다 상세화된 프로세스를 표현하고 있습니다.

 

결국 요구사항은 가장 최하위 수준에서 더 이상 쪼갤 수 없을 정도의 상세화된 요구사항이 분석되고 정리되어야 합니다. 그러나 요구사항을 정확히 모르거나 이를 알고 있다 하더라도 이렇게 추상화레벨에 따라 추상화 요구사항과 상세 요구사항을 구분하여 기술하는 것이 필요합니다.

 

6. Requirements Specification

 

저희가 목표로 하는 것은 software system requirements를 분석하여 최종 요구사항명세서를 작성하는 것입니다.

이때 명세서가 갖추어야할 속성 중에 4가지를 살펴보고자 합니다.

 

첫째는 completeness인 완전성입니다. 요구사항이 누락이 되었다는 것은 그 만큼 치명적인 오류이므로 완전성은 명세서가 갖추어야 할 매우 중요한 특성이라고 할 수 있습니다.

 

둘째  Consistency, 즉 일관성은 요구사항이 상호 불일치 정도를 의미합니다. 요구사항이 불일치 한다는 것 자체가 오류를 포함하고 있다고 할 수 있습니다.

 

셋째 Accuracy, 정확도는 요구사항을 정확하게 표현하고 있는 정도를 의미합니다. 사실 사용자 원하는 요구사항이 정확한 가를 측정하는 것은 쉬운 문제는 아닙니다. Accuracy의 반대 개념을 ambiguity, 즉 모호성이라고 이해할 수도 있습니다. 따라서 요구사항의 기술은 정해진 규칙을 기준으로 모호하지 않도록 정의하는 것이 중요합니다.

 

마지막 Testability인 테스트가능성 또는 용이성은 요구사항은 테스트를 통해 확인할 수 있는 정도를 의미합니다. 최종 요구사항은 반드시 만족하는지를 확인해야 하는데 만족하는가를 테스트하기 어렵다면 요구사항의 존재 여부도 의미가 없다고 판단할 수 있습니다. 특히 non-functional requirement은 많은 부분이 정의하기도 어렵고 테스트하기도 어려운 요구사항들이 많아 매우 주의를 요하는 요구사항입니다.