SW공학 – 요구사항

고객의 요구 결정하기

  • 많은 고객은 무엇을 원하는지 잘 모를 수도 있다.
  • 객체지향 접근법은 고객과 사용자들의 초기정보를 획득하고 요구사항 workflow의 초기정보로 사용한다.

요구사항 workflow

  • 도메인의 이해 -> UML을 사용하여 서술 -> 요구사항 결정 -> 반복

도메인 이해

  • 도메인 : 대상 프로덕트가 사용될 일반 영역
  • 개발팀원이 도메인의 용어를 이해하지 못하면 결함이 생길 수 있다.
  • 전문용어를 설명하기 위해 용어사전(glossary를 만들어야 함.

비지니스 모델

  • 비지니스 모델 : 비지니스 프로세스들의 서술. 고객의 비지니스의 이해를 도와줌
  • 인터뷰 : 고객과 사용자의 모든 정보를 추출할때까지 고객의 멤버와 모임을 계속 가진다.
  • 인터뷰 방법 : 폐쇄형 질문(명시된 질문과 대답), 개방형 질문(자유 발언)
  • 인터뷰 유형 : 구조적 인터뷰(폐쇄형 질문을 사용), 비구조적 인터뷰(1~2개의 폐쇄형 질문으로 시작하여 폭넓은 개방형 질문을 사용)

다른 기법

  • 설문지 : 구두로 응답을 듣는것보다 정확할 수 있음.
  • 비지니스 양식 조사 : 양식의 필드와 흐름을 파악
  • 직접 관찰 : 해당 회사의 직원과 동행하여 업무를 관찰

유스케이스

  • 액터(actor)와 인터렉션(interaction)으로 표현
  • 액터는 반드시 사람일 필요는 없으며 시스템이 될 수도 있다.

초기 요구사항

  • 요구사항은 동적으로 계속 변경되므로, 개발팀이 동의하고 고객이 승인한 요구사항들의 리스트를 유지해야 함.
  • 기능적 요구사항 : 프로덕트가 수행해야만 하는 액션을 명세
  • 비기능 요구사항 : 플렛폼 제약, 신뢰성 등의 성질을 명세

요구사항 workflow용 CASE 도구

  • 장점 : UML용 drawing tool은 손으로 작성하는 것보다 빠르며, 저장/갱신이 용이
  • 단점 : 도구를 사용하기 위한 학습곡선이 있으며, 가격이 비싸다.

요구사항 workflow용 척도

  • 요구사항의 불안정성을 측정하여야 함.
  • 척도 : SW개발 프로세스의 동안의 변경된 요구사항의 수

요구사항 workflow의 난제

  • 초기부터 대상 프로덕트 사용자의 진심어린 협력이 어려움
  • 고객과의 협상능력이 필요함.
  • 정보를 소유한 사람과 깊이 있는 논의를 위해 만날 시간이 적다.
  • 유연성과 객관성을 가져야 한다.

CC BY-NC-ND 2.0 KR

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스

저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.

댓글 남기기