[Software Engineering] Chapter 03. 프로세스 - 요구사항

전통적인 소프트웨어 프로세스 정형화

• 소프트웨어 개발 관련자
  1. 요청 고객 (Client)
  2. 사용자 (실제 Customer)
  3. 프로젝트 관리자 (PM)
  4. 개발자 (Developer)

 

요구사항(Requirement)

시스템 개발 분야에서 어떤 과제를 수행하기 위해 필요한 조건이나 능력

 

사용자 요구사항 ---- 구체화 ----- > 시스템 요구사항

-> 사용자의 요구사항은 추상적이지만, 이것을 점점 구체화 시키면 시스템 요구사항이 된다

 

요구사항의 종류

• 기능 요구사항(Functional Requirement)
  • 어떤 기능이 제공되어야 하는지
  • 특정 input이 주어졌을 때, 시스템이 어떻게 동작해야 하는지(output) 등 기능적인 측면을 서술하는 요구사항
  • 예) 검색 기능, 메세지 전송 기능, 마이 페이지 확인, ...
• 비기능 요구사항(Non-Functional Requirement)
  • 특정한 동작이 아닌, 전체적인 시스템을 운영하기 위해 사용되는 기준을 정의한 요구사항
  • 예) 성능, 보안성, 효율성, 안정성, 응답시간, 접근성 ,법 등 ...
  • 기능 요구사항보다 명확하게 정의하기 어려움
  • 비기능 요구사항을 검증 가능하게 정의하는 것이 좋음
    • 예) 사용자들이 사용에 불편을 겪는 시간을 최소화해야 한다. -> 장애 발생 시, 불편을 겪는 시간이 10분 이내여야 한다. (-> 이에 맞춰서 장애 복구 시나리오 수립)

 

Requirement Engineering 프로세스

• 요구사항 도출 - 요구사항 분석 - 요구사항 정의 - 요구사항 검증(리뷰)
• 단계가 진행될 수록 점점 요구사항이 구체화되고, 명확해진다
• 요구사항에 오류가 있는 경우가 많으므로, 검증 과정이 매우 중요함
• 개발 도중 나중에 오류를 발견했을 때, 요구사항을 변경하는 비용이 매우 큼

요구사항 정의서(명세서, document, requirement specification)

• 요구사항을 서술하는 공식 문서
• 서술 방식 : input, output, 동작 방식, pre and post condition(사전/사후 조건), side effect, 다이어그램 등
• 무엇을(What) 구현해야 하는지 O, 어떻게(How) 구현할건지 X
  • 완전히 분리해서 생각하기는 어렵지만, How는 아키텍처 설계에 가까운 느낌
• 사실 최근에는 PPT 기획안, 디자인 그 자체가 요구사항이 되는 경우가 많음