요구사항정의 - 비기능

이번에는 비기능적인 요구사항을 정의 해 보도록 한다. 굳이 어떤 특별한 프로젝트가 아니여도 보편적으로 통용 될 만한 요소들을 아주 최소한의 요건 정도만 넣어서 정의 해봤다. 토이프로젝트이며, 최소한의 인프라 비용을 추구하기 때문에 성능적인 요소는 자세히 정의 하지는 않았다 (대규모 트래픽 상정 하지 않음) 또 웹 접근성 같은 부분도 정의 할 수 있을 것 같은데, 이 부분은 상대적으로 나의 능력 밖 부분이라 일부러 정의 하지 않았다 (완벽하게 할 자신이 없음).
결과적으로 기능적인 요소에 비하면 나도 잘 몰?루는 부분이 많아서 빈약한 요구사항정의를 하게 되었다.

성능

• 시스템은 사용자의 직접 요청은 2초 이내에 처리 해야 합니다.
• 시스템의 내부 처리 로직은 30초 이내에 모든 처리가 완료 되어야 합니다. (graceful shutdown: 구현)

보안

• 모든 사용자의 데이터는 암호화되어 저장되어야 합니다.
• 사용자가 직접 접근하여 볼 수 있는 정보는 오로지 해당 회원만이 접근이 가능하며, 시스템도 해당 정보를 암호화 하여 저장하고, 해당 회원만이 정보를 확인 할 수 있습니다.(시스템, 관리자도 해당 정보에 접근 할 수 없습니다.)
• 일반적인 SQL 인젝션, XSS, CSRF와 같은 보안취약점에 시스템은 보호되어야 합니다.
• 악의적인 사용자의 데이터 위변조, 해킹 등 시스템에 문제를 일으킬 수 있는 행위에 보호되어야 합니다.

확장성

• 시스템은 가용 자원의 범위 내에서 처리 능력이 쉽게 확장 될 수 있습니다.
• 노드의 추가와 같은 처리 능력 향상을 쉽게 구현 할 수 있습니다.

유지보수성

• 시스템의 코드는 모듈화 되어 있어야 하고, 적절한 주석과 문서화로 유지보수가 용이하게 관리 되어야 합니다.
• API의 경우 OpenAPI(Swagger)를 통한 설계와 문서화로 코드에 대한 정의를 내리고 관리합니다.
• 관련 문서는 코드의 변동과 동시에 항상 업데이트 되어야 합니다.
• 시스템은 수정이나, 기능 개선 등을 쉽게 처리 할 수 있도록 설계, 개발되어야 합니다.
• 주요 도메인 코드와 핵심 비지니스 로직 등은 테스트 코드와 함께 개발되어야 합니다.
• 테스트 코드 또한 기존 코드 변경에 따라 항상 업데이트 되어야 합니다.
• 테스트 코드는 가능한 모든 예외 상황에 대해서 테스트 하도록 설계 합니다.

호환성

• 웹 애플리케이션은 주요 브라우저 (Chrome, Firefox, Safari 등) 에서 문제없이 작동하고 동일한 기능을 제공해야 합니다.
• 시스템은 다양한 디바이스에 맞게 (예: 데스크톱, 태블릿, 모바일) 호환성을 고려해서 설계 되어야 합니다.