다음 문장들이 진정한 요구 사항인가? 가능하다면 진정한 요구 사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라.

1. 응답시간은 500ms 이하여야 한다.

흔히 성능에 대한 요구사항은 비기능적 요구사항으로 분류가 된다. 즉 요구사항이긴 하다.

당연히 빠른 응답이 선호되기는 하지만 좋은 일에는 대가가 따르는 법, 이 요구사항을 만족하기 위하여 많은 부분을 포기해야할 수도 있다. 예를 들면 한 페이지에 노출할 수 있는 데이터 건 수가 제한되거나 좋은 품질의 큰 이미지를 사용하지 못할 수 있다. 고성능을 위해 데이터베이스 사양이 높아지거나 고가의 캐시 서비스를 사용해야 할 수도 있다.

제공되는 서비스의 종류에 따라 500ms는 너무 빠를 수도 아니면 적당한 수준일 수도 있다. 서비스에 비해 너무 과한 목표라면 적절한 타협점을 찾아야하고, 목표로 정한 수치를 이루기 위해서 포기해야할 것들을 이해시키는 것이 중요할 것 같다.

2. 모달 창modal window의 바탕색은 회색이다.

디자인 요소는 자체만으로는 요구사항으로 보기는 어려울 것이다. 하지만 퍼블리싱을 하는 디자이너 관점에서는 요구사항이 될 수도 있을 것 같다.

시각적인 요소는 전체적인 조화를 고려하여 설계되어야 하지만 고객이 어떤 주장을 한다면 아마 타당한 이유가 있을 것이다. 주장을 들어 보고 타협하기 어렵다면 요구사항에 근거하여 디자인을 손봐야할지 모른다. 그렇지 않다면 전문가의 견해임을 들어 탁월한 색감으로 고객을 만족시킨다. Look&Feel 기능이나 UI 탬플릿을 지원하는 시스템이라면 고객이 직접 선택할 수 있도록 제공하는 것도 방법일 것이다.

3. 애플리케이션은 프론트엔드 프로세스 몇 개와 백엔드 서버로 구성된다.

아키텍처는 시스템이 이루려고하는 진정한 목적이 아니다. 원하는 바를 이루기 위한 수단이 아키텍처일 것이다. 고객이 처한 상황에 따라 아키텍처의 제약이 있을 수는 있겠지만 목적을 이루기 위해 언제든 수정될 수 있다.

고객이 이런 요구사항을 이야기한다면 빠듯한 인프라 예산을 고려한 현실적인 제안일 수 있다. 인프라에 제약이 있다면 시스템의 능력에도 제약이 따를 수 밖에 없다. 프로토타입을 작성한 뒤 성능테스트를 통해 이런 제약 사항을 수치로 제공하는 것도 의미 있을 것이다.

4. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면 시스템은 입력 필드를 깜빡이고 입력을 거부한다.

요구사항이다. 사용자 인터페이스도 응답시간 제약의 사례와 비슷하다고 생각한다. 다만 UI는 시스템 전반에 걸쳐 통일된 사용자경험을 제공해야 하므로 그 세부 구현은 계속 보완되고 바뀔 것이다. 요구사항이라면 이런 세부 구현까지 제약하는 것은 바람직하지 않다. 큰 의미에서 고객이 의도하는 바를 이룰 수 있다면 적절히 추상화하는 것이 필요하다.

5. 이 임베디드 애플리케이션의 코드와 데이터 크기는 32Mb 이내여야 한다.

제약조건이다. 아마 타협할 수 없는 요구사항일 것이다. 언뜻보면 아키텍처를 제약하는 3번 항목과 유사하게도 느껴지지만 임베디드 애플리케이션의 특성상 하드웨어에 강하게 의존할 수 밖에 없고, 구동될 하드웨어를 특정해서 개발할 수 밖에 없다. 반면에 일반적인 웹 애플리케이션은 범용 서버에서 구동될 수 있으므로 그 선택지가 다양하다. 구성할 수 있는 아키텍처가 무척 다양한데 그 가능성을 미리 제한할 필요는 없어보인다.