*** 요구사항 정리
– 기초공사
– 사용자로부터 필요
– 시스템 구축의 첫 과정
– 요구사항 도출, 기술, 확인하는 활동
+ 유스케이스 모델링 기법 이용
+ 체계적인 요구사항 도출
+ 명확한 기술 방법 설명
** 요구사항의 유형
* 기능적 요구사항 : 시스템이 제공해야 하는 동작/행위에 대한 요구사항
– 교수/학생 정보를 등록, 검색, 수정, 삭제, 조회할 수 있는 기능
– 강좌/강의를 등록, 검색, 수정, 삭제, 조회할 수 있는 기능
– 수강 신청, 성적 등록, 성적 조회, 출석부 조회 기능
– 로그인, 로그아웃, 암호 변경 기능
* 비기능적 요구사항 : 동작/행위와 관련된 제약사항
– 성능
– 신뢰도
– 사용 편의성
– 유지 보수성
** 비기능적 요구사항
* 성능
– 정해진 특정 시간 내에 결과가 나와야 한다는 조건
– ex) “학번, 이름을 입력한 후에 검색 명령을 내리고 검색 결과를 2초 이내에 화면에 보여 주어야 한다.”
– 설계 활동의 중요한 요소로 작용
– ex) JDBC로 직접 데이터베이스 조작, 무상태 세션 빈 사용, 성능 향상을 위한 프로그래밍 기술 사용
* 신뢰도
– 오류가 발생하지 않으면서 시스템이 동작할 확률
– ex) 항공기 제어 시스템, 미사일 추적 시스템 등의 실시간 시스템
– 특별한 기술 사용
* 사용 편의성
– 사용자들이 얼마나 편리하고 쉽게 시스템을 사용할 수 있는가
– ex) 효과적인 메뉴 체계 정의
– ex) UI화면의 일관되고 효과적인 정의
– ex) 도움말 온라인 제공
* 유지 보수성
– 얼마나 유지 보수를 쉬우면서 효율적으로 할 수 있는가의 정도
– 설계 시 약속된 기능을 정확히 제공
– 설계 시 유지 보수 측면 고려
** 요구사항 정의의 중요성
* 요구사항 정의 활동의 산출물
– 개발자들에게 구축할 시스템의 정보 제공
– 개발할 시스템 파악(개발자)
* 요구사항 정의 활동 개발자와 분석/설계 개발자가 다른경우
– 산출물을 바탕으로 한 작업 진행
– 정확성과 완전성이 중요함
* 요구사항의 명확한 정의 이후 개발 진행
* 결정된 요구사항에 대한 사용자와 개발자 간의 합의 필요
** 요구사항 정의 활동
– 시스템이 제공할 기능과 범위 밖을 명확하게 구분
– 시스템의 결계 결정
** 유스케이스 모델링
– Ivar Jacobson에 의해서 제안
– 요구사항 도출 및 기술에 사용
– 액터 : 개발할 시스템 외부의 존재
– 유스케이스 : 시스템 범위 안에서 개발될 시스템의 단위 기능
*** 액터
* 개발될 시스템과 상호 작용을 하는 모든 대상
– 사용자 액터
– 시스템 액터
* 사용자 액터
– 개발될 시스템의 기능을 이용하는 사용자
* 시스템 액터
– 개발될 시스템과 연동 되는 또 다른 시스템
– ex) 신용 대출 시스템 : 신용 정보 제공 시스템
– ex) 대학 정보 시스템 : 수강료 청구서 발급 시스템
** 액터 이름
* 액터의 이름
– 액터의 의미를 명확히 애해할 수 있는 단어 사용
* 사용자 액터
– 시스템 관점의 사용자 역할
– ex) 교수, 학생, 학사 담당자, 수업 담당자
– 역할 추측 가능한 구체적인 단어 사용
* 시스템 액터
– 해당 시스템의 이름 사용
– 문제 기술서에 시스템의 이름이 명시되어 있음
– ex) 수강료 청구서 발급 시스템, 신용 평가 시스템
** 액터 설명
* 액터가 할 수 있는 일 기록
– ex) 학사 담당자 : 교수 및 학생 정보를 관리한다.
** 액터의 특성
* 개발될 시스템 범위 밖에 존재
– 개발자가 개발할 범위가 아니라는 것.
– ex) 대학 정보 시스템 : 수강료 청구서 발급 시스템
* 역할을 나타내야 함
– 구체적인 실제 사용자가 아님
– 시스템의 관점에서 바라본 그 사용자의 역할
– 한 명이 두 개 이상의 역할을 하는 경우 : 대응되는 각각 사용자 액터를 정의
– ex) 1명(도서 관리, 학생/교수 관리) : 사서, 학사 담당자 액터
** 액터 찾기
* 질문 : 누가 개발될 시스템의 주요 기능을 이용하는가?
– 문제 기술서 활용
– 학적과의 학사 담당자는 학생 및 교수 정보를 관리해야 한다.
– 수업 담당자는 새로운 강좌를 등록할 수 있다.
– 학생을 수강 신청을 온라인 상으로 직접 할 수 있다.
– 교수는 매 학기마다 자신이 강의하는 강좌를 신청한 학생 명단을 확인할 수 있다.
* 질문 : 누가 이 시스템을 통해서 자신의 업무를 지원 받을 수 있는가
– ex) 대학 정보 시스템 : 학사 담당자
* 질문 : 누가 시스템이 만들어 낸 결과에 관심을 가지는가?
* 질문 : 누가 시스템이 잘 운영될 수 있도록 유지 보수 및 관리를 하는가?
– Primary actor : 시스템 본연의 기능을 이용하는 사용자
– Secondary : 시스템의 유지 보수 기능을 이용하는 사용자
– 음료수 자동 판매기 : 청소 및 관리자
– 현금 자동 인출기 : 유지 보수 담당자
– 시스템이 유지 보수 기능을 제공하지 않으면 유지 보수 담당자는 액터로 표기될 수 없음
* 질문 : 개발할 시스템과 연동되는 다른 시스템에는 어떤 것이 잇는가?
– 시스템 액터를 찾을 때 유용
– ex) 대학 정보 시스템 : 기존에 존재하는 수강료 청구서 발급 시스템
Tags: Software Engineering, 소프트웨어 공학
