Requirements Engineering(요구공학)

728x90

요구사항은 소프트웨어 설계의 기초적인 문서로서 테스트케이스를 만드는 등의 기초가 됨.

요구사항이 조기에 파악되지 못하면 추가 비용이 매우 크며, 변경된 요구사항이 다른 기능에 영향을 미칠 수 있음.

Requirements Management Activities
- 요구사항에 대한 형상 관리
- 제안된 변화를 검토하고 그 영향 평가
- 요구사항 변경으로 예상되는 영향을 기반으로 새로운 약속 및 협상
- 각 요구사항에 대응되는 설계, 소스코드, 테스트케이스 추적
Source of Requirements: 잠재적 사용자와의 인터뷰, 경쟁사 제품 분석, 유사 시스템 참고, 사용자 업무 시나리오 분석 등

형상관리를 위한 도구
- CVS: 무료 서버-클라이언트 형상관리 시스템. 히스토리 보존. 속도 느림
- SVN: CVS 단점 보완. 처음에는 원본을 저장하고 이후에는 차이점 저장
- Git: 분산형 버전관리 시스템. 처리속도가 빠르지만 대용량 코드 관리에 부적절

10 Step RE Process (by Alexander)
1. 미션과 범위 설정: 처리할 외부의 입력, 주요한 기능, 생성하는 출력 등 파악 (Use case diagram)
2. Stakeholders 식별: 사용자 및 관계자가 누구인지. 각 집단마다 용어 및 이해정도가 다름
3. Stakeholders의 목적 파악: 구체적이고 실현 가능한 목적으로 정제
4. Stakeholders 간의 목표 절충: 목표가 충돌하는 경우 우선순위를 고려하여 결정
5. 요구사항을 시나리오로 형태로 기술: Use case description 방법 사용. 각 시나리오는 기능의 일부를 기술한 것에 불과.
6. Requirements: 인터페이스, 제한사항, 비기능적 요구사항 등
7. Justifications: 요구사항이 필요한 이유와 검증가능한지 확인(Testcase 필요)
8. Identify assumptions: 프로젝트가 의존하는 가정을 검증, 가정이 틀렸을 때의 행동을 고려 (비기능 요구사항과 각종 제약사항에 집중)
9. Agreed Priorities: 요구사항의 중요성에 따라 등급을 매김
10. Acceptance criteria: 요구사항이 제대로 구현되었는지 판단하는 기준을 정립. 극한 상황/실전과 가까운 시험 환경/시스템 악용에 대한 대응을 확인

Specific Requirements
- External interfaces (input, output) 서술: 이름, 목적, source와 destination, 유효한 범위/정확성/허용성, 측정 단위, timing, 다른 input/output과의 관계, data formats 등
- Operation의 정확한 순서
- 비정상적인 상황(overflow, 에러)에 대한 반응

Requirements Traceability
- 요구사항이 다른 요구사항에 미치는 영향을 추적
- 요구사항 변경 시 전체 요구사항을 분석하지 않기 위해서 필요

Software Requirements Specification (SRS, 요구사항 명세서)
- 소프트웨어 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물
- 소프트웨어가 수행해야 할 모든 기능과 제약 조건 등이 기술되어 있으며 이후 소프트웨어 개발과 테스팅의 완료 승인에 대한 기준으로 사용됨
- 작성 내용
  1. Introduction (문서 목적/범위/용어정의/참조 등)
  2. Overall description (소프트웨어의 주기능/제약사항/가정/의존성, 사용자의 특성)
  3. Specific requirement (세부적인 요구사항: 외부 인터페이스/기능/성능/논리적 데이터베이스 요구사항, 설계 제약 사항, 소프트웨어 시스템 속성)
- 기능 요구사항을 적는 방법 - 모드 별로/user class 별로/ feature 별로 등 상황에 맞게 분류하여 작성
- SRS review를 통해 잠재적 오류를 찾음

진진진 개발일지