software-design
맞춤 정장을 만들기 위해 가장 먼저 하는 일은 고객의 체형을 정확히 측정하고, 어떤 스타일과 기능을 원하는지 파악하는 일입니다. 고객이 원하는 색상, 옷의 용도, 주머니 위치 등 세부사항까지 꼼꼼히 확인한 뒤에야 본격적인 제작이 들어가죠. 소프트웨어 개발에서도 이와 마찬가지로, 개발을 시작하기 전에 무엇을, 왜 만들 것인지 명확히 정의하는 과정이 바로 요구사항 분석입니다.
요구사항(Requirements)은 소프트웨어가 무엇을 해야 하며, 어떤 제약 조건 하에서 동작해야 하는지를 정의하는 사전 조건입니다. 이는 사용자의 기대와 비즈니스 목표를 충족시키기 위해 필수적인 정보를 포함하며, 개발자, 디자이너, 기획자 모두가 참고하는 기준점 역할을 합니다.
기능적 요구사항은 실제로 시스템이 어떤 기능을 해야 하는지 명시한 것입니다. 예를 들어, 은행 시스템에서 ‘조회’, ‘인출’, ‘입금’, ‘송금’ 같은 구체적인 작업이 바로 기능적 요구사항이라 할 수 있습니다.
비기능적 요구사항은 시스템 성능, 품질, 보안처럼 기능을 보조적으로 지원하는 요소를 의미합니다. 예를 들어, “모든 화면이 3초 이내에 로딩되어야 한다” 같은 요구사항이죠. 기능의 유무가 아니라, 성능이나 품질 같은 기대 수준을 정의한다고 보면 됩니다.
정리하면 아래와 같습니다.
요구사항은 단순히 문서화된 목록이 아니라, 사용자와의 커뮤니케이션 도구이자 개발 명세서입니다. 애자일 개발에서는 사용자 스토리(user story) 형식으로, 폭포수 모델에서는 SRS(Software Requirements Specification) 문서 형식으로 표현되며, 설계 및 구현의 기반이 됩니다.
정확하고 완전한 요구사항 정의는 프로젝트 성공의 핵심입니다. 불명확한 요구사항은 구현 오류, 개발 지연, 불필요한 재작업을 유발할 수 있으며, 결과적으로 사용자 불만족으로 이어질 수 있습니다. 따라서 요구사항 도출, 분석, 검증은 반복적이고 협업적인 과정으로 수행되어야 합니다.
| 분류 | 설명 |
|---|---|
| 기능 요구사항 (Functional Requirements) | 시스템이 어떤 기능을 수행해야 하는지를 정의 (예: 사용자는 로그인을 할 수 있어야 한다) |
| 비기능 요구사항 (Non-functional Requirements) | 성능, 보안, 확장성, 유지보수성 등 시스템의 품질 속성을 정의 (예: 로그인은 2초 이내에 완료되어야 한다) |
요구사항은 다음 네 가지 단계를 거쳐 개발됩니다.
요구사항을 제대로 작성했는지 확인하는 방법은 세 가지가 있습니다.
작성자가 요구사항 문서를 동료에게 설명하고, 동료가 내용을 들으며 결함을 찾습니다. 가장 가벼운 느낌의 방식입니다.
요구사항 문서를 사전에 나눠준 뒤, 미리 읽어보고 짧게 회의하며 결함을 찾습니다. 이름 그대로 '가볍게 걸어가면서 전단지를 보는 듯한 느낌'으로 진행하는 방식입니다.
작성자가 아닌 전문가들이 요구사항 문서를 꼼꼼히 살펴 결함을 발견하는 방식입니다. 전문가가 등장하는 만큼 가장 무겁고 철저한 방식입니다.
요구사항은 소프트웨어가 무엇을 해야 하고 어떤 조건을 만족해야 하는지를 정의하는 기준 문서입니다. 기능적 요구사항과 비기능적 요구사항으로 나뉘며, 프로젝트의 방향성과 품질을 결정짓는 핵심 요소로 작용합니다. 성공적인 시스템 개발을 위해서는 정확한 요구사항 분석과 사용자와의 지속적인 소통이 필수적입니다.