[Software Engineering] Requirements Capture

User Requirements

• 집단이 현재 어떻게 수행 ,진행되는지 이해할 필요가 있음

• 현재 시스템이 어떤 문제를 가지고 있는가?

• 현재 시스템이 아닌 새로운 시스템에 대하여 user들은 어떠한 requirements를 갖고있는가?

  • Customize software라고 생각하면 이해하기 쉽다. 예를 들어 학교에 classnet의 무언가가 안된다고 생각해 볼 때,
    • 그 학교가 어떻게 운영되는지 확인해야함 그것을 이해하는 것
    • 기존 시스템이 있을 터인데 현재 시스템에서의 문제점을 분석한다.
    • Current system에 없는 requirements를 찾아내야함

• 현재 시스템을 조사하는 이유

  • 기존 시스템의 기능이 새로운 시스템에서 분명히 필요할 것
  • 기존 시스템의 데이터를 새로운 시스템으로 이동 시켜야한다.
    • DB에 저장되어있는 데이터의 이동(migration) , 기존의 것을 봐야한다.
  • 기존 시스템에 있는 techincal documnetation(processing algorithm 의 디테일)을 봐야한다.
  • 기존 시스템에 있던 버그(defects)를 알아내야함
  • 기존 시스템이 있는 baseline information이 performance targets에 도움을 준다.
  • 수강신청 시 수용 인원에 의해 서버가 죽는다면, 용량을 늘려야하는데 그런 것에 대한 baseline 정보를 얻을 수 있다. 어떠한 defects이 있었는지 HW문제인지 확인

• New Requirements

  • 새로운 것을 만들어야하겠다는 동기가 되는 요소
    • Business environment가 급격히 변함
    • Technical environment의 변화
    • 법규(법률 , 규제)를 만듦

Types of Requirements

• Functional (시스템이 반드시 수행해야 하는 행위)
  • 시스템이 꼭 해야할 것들을 설명
  • 포함하는 것
    • System이 실제 처리해야하는 processing
    • 처리하기 위한 input필요
      • 외부 network, documents , …
    • 시스템으로부터 나오는 outputs
      • documents, screen displays, …
  • ==Modelled with Use Case Diagrams==
• Non-Functional
  • Functional 을 제외하고 모두에 해당
  • 기능은 사용자가 사용하고 있는 것들을 제외한 나머지
  • 시스템이 functional requirements를 얼마나 잘 제공하느냐에 관련된 것
  • 포함하는 것:
    • Performance criteria(response times)
      • 동시 유저 접속 수를 10000명까지 문제 없이 처리하겠다는 것은 기능은 아니지만 requirements이다
    • anticipated volumes of data
    • security considerations
      • 이것 또한 기능이 아님 non-functional
  • Documented in Requirements Lists
    • 그림으로 그릴 수 있나? 1만명까지 접속 수를 늘린다는 것을 그림으로 그리는 것은 의미가 없으며 글로 쓴다.
• Usability
  • 사용하기 쉬운가? 거꾸로 얘기하면 user가 acceptable해야한다. 시스템이 보통 사람들이 원래 일하는 방식에 맞게 얼마나 매칭시켜주느냐에 관련된 것이다.
  • 모아야할 정보
    • 유저가 실제 하고 있는 일의 성격, 특성
    • Working system의 acceptance기준
  • Documented in Requirements List
    • 글로 표현하며 그림으로 표현하는 것은 functional 밖에 없다.
  • 이러한 requirements를 넣기 전 본인이 usable하다고 넣지 말고 user에게 확인해야한다. 예를 들어 font 13size어때요? 라고 물어보면 대답을 못한다
  • 즉 , prototype을 만들어야함(UI관련)

Fact Finding Techinques (Background 이해 ⇒ 인터뷰 ⇒ 관찰 ⇒ 설문조사)

• Background Reading

  • Organization 과 business objectives 의 이해를 목표
    • Ex) Consulting
  • 포함하는 것
    • reports
    • organization charts
    • policy manuals
    • job descriptions
    • documnetation of existing systems
      • 기존 시스템의 documentation
  • 장점:
    • Meeting을 하기 전, 위의 것들로 조직에 대해서 이해를 해야한다.
    • 다른 fact finding에 대비하며 준비하는데 도움을 준다.
  • 단점 :
    • 쓰여진 documents들이 update를 잘 안한다.
    • 현재 상황을 알 수 없는 경우가 많다.
    • 적혀있는 것은 ideal한데 그렇지 않은 경우가 많다.
  • 적합한 상황은 initial stages of fact finding

• Interviewing

  • 조직의 목적, users’ requirements, 사람들의 roles를 깊이 있게 알기 위해서 인터뷰 진행
  • Includes:
    • 목표를 이해하기 위한 managers
    • 어떤 정보를 필요로 하는지 이해하기 위한 staff
    • ==고객==과 일반인들과의 interview
  • 장점
    • 얘기하는 것에 맞추어 답변과 질문을 할 수 있으며 personally하게 진행 가능
    • 깊이 있게 진행 가능
  • 단점
    • 시간과 비용이 오래 걸림
    • 질문의 유도성이 있음 ( Bias: 한쪽으로 치우친)
      • can be subject to bias
    • 다 같은 답이 안나올 수 있기에 검증해야할 필요성이 있다.
  • 적합한 상황:
    • 대부분의 projects들에 활용 가능
    • Fact finding 단계에서 기존 존재하는 system의 깊이 있는 정보와 사람들의 requirements가 필요하다

• Observation

  • 실제로 가서 확인하는 것
  • Includes:
    • 사람들의 process를 어떻게 수행하는지 직접 본다.
    • 기존 시스템에 비해 새로운 시스템에서 제공하게 될 성능을 높여야 하기에 그런 것을 정하기 위한 baseline data를 수집
  • 장점
    • System이 어떻게 수행되는지 실제 체험을 할 수 있다.
    • 다른 sources를 검증할 수 있다.
    • Baseline data를 수집할 수 있다.
  • 단점
    • 관찰당하는 것을 좋아하지 않고, 원래 하던대로 하지 않으며 왜곡될 수 있다.
  • 적합한 상황
    • 다른 sources로부터의 정보를 검증할 때
    • 충돌되는 정보가 있을 떄 해결할 수 있음

• Questionnaries

  • 설문조사
  • 많은 사람들한테 그들의 의견을 추합할 수 있으며 통계적으로 분석하여 사용가능하다.
  • 포함하는 것
    • Web or email로 진행 가능
    • 의견을 반영할 수 있다.
  • 장점
    • 많은 이들한테 정보를 얻을 수 있으며 비용의 절감
    • 지리적으로 떨어져있는 사람들의 정보 또한 모을 수 있다.
  • 단점
    • 설문 조사의 질문을 잘해야한다.
    • Automatic 하게 분석해주는 방법이 필요하지만 쉽지 않다.
    • 질문 자체를 만들고 분석하는 방법이 좋아야하지만 여의치 않을 경우가 많다.
  • 적합한 상황
    • 많은 사람들의 의견이 필요할 때
      • Generic software에 적합
    • User or staff가 지역적으로 떨어져 있을 경우
    • Generic system, user의 profiling하고 싶을 때 효과적
    • 하지만 미참률이 많을 수 있다.

• Documenting Requirements

  • Requirements를 기록해야 한다
  • tool은 제공되어진다.
  • Functional requirements
    • use cas diagrams
  • All types of requirements
    • seperate requirement lists

Use Case Diagrams

• Specification 단계에서 진행된다.
• 목적
  • ==User 관점에서의 시스템의 기능적 문서화 하기 위해==
  • User와 use case description 을 하는 system사이에서의 interaction document
  • System 과 user간의 interaction
  • 시스템 내부는 생각도 하지 말것

• Actors
  • 사람만 되는 것이 아니라 다른 시스템, device도 actor가 될 수 있다. (Ex. 비행기 예약 시스템, 스케쥴러 etc..)
  • 시스템 외부에서 시스템과의 communication하는 모든 것들이 actor이다.
  • 소프트 웨어 외부에서 소통하는 것들 모두 actor이다.
  • stick man으로 표현하고 그 밑에 역할을 적어준다.
  • Actor는 사람이 될 수도 있고 system or device가 될 수 있다. 시스템 외부에서 시스템과의 communication하는 모든 것들이 actor
  • 이름은 역할로 쓴다. 부장이란 건 직책이며 무슨 일을 하는지 알 수 없다. 역할이라는 건 시스템 관리자, 사이트의 회원
  • 논쟁의 여지
    • Event(주기적인 활동, 예약작업)은 내부의 일, Actor는 외부의 일이다. 그러면 actor가 내부의 일을 간섭할 수 없는 것 아닌가? 그 관점에서는 맞다.
    • 하지만 actor로 표현하지 않으면 어딘가에 표현해야하는데 마땅치 않다. Event를 actor로 보자
• Use cases
  • 이름을 영어로는 동사 혹은 명사.
  • 항상 actor하고 연결되어 있음
  • Actor에게 의미 있는 결과를 주기 위해 system이 수행하는 action의 sequence이다.
  • 중요한 것은 use case를 볼 때 사용자의 입장을 본다 ! 시스템 내부의 입장은 보지 않는다.
  • use case이므로 누군가가 사용하는 것인데 사용자는 actor이며 use case항상 actor와 연결되어 있어야한다.
• Communication associations
  • Actor와 use case를 연결하는 선
  • 화살표로 쓸 수 도 있고 안쓸 수도 있다.
    • 안쓴다는 것은 누가 먼저 시작하는지를 얘기를 안한 것, 양쪽 다 interaction 일어난다, 해도되고 안해도 된다.
    • 화살표가 있으면 그 방향으로 communication 시작한다는 뜻
  • Association이 있다는 것은 link 가 있다는 얘기
  • Class와 object의 차이 : class 는 definition, object을 만들기 위한 definition, 실체화된 것을 object (instance) 라고 한다.
  • 어떤 use case의 실제 예와 actor의 실제 예 사이의 링크가 생긴다.
• Sub-systems
  • 직사각형이며 use case를 넣으면 된다.
  • 같은 subsystem안에 있다는 뜻이다.
• Dependencies
  • Use case간의 relationships을 Extend와 include를 통하여 지어주는 것
  • Stereotype ( 고정관념) 의 dependencies
  • Stereotype
    • 모델의 special use( 미리 정한 특별한 방법으로만 동작하게 제한)
    • <> and <>
• Extend relationship
  • 어떤 한 use case가 추가적인 기능을 제공할 때 사용
    • 다른 use case에서 쓰일 수 있음 (Option)
  • Actor들이 여러 use case와 여러가지 variation을 준다.
  • Extension points
    • Extend가 일어나는 곳을 보여준다.
  • Extend가 메뉴, 실행 순서로 표현하고자 하면 안되며 끊고 다른 기능을 쓰면 되지 extend의 연속으로 쓰면 안된다.
  • Extend는 확장이라는 의미로 Print campaign summary가 print기능을 추가해서 check campaign budget을 확장 시킨다는 의미로 옵션이라고 생각
  • 방향을 잘 보자. Print가 check 의 기능을 확장 시켜주는 것 이기에 방향이 밑에서 위로간다.
• Include relationship
  • 광고 회사의 software를 만들며 중요한 object들은 client(회사)-campaign(제품) -advert(제품을 광고하기 위한 매체)
  • Campaign 찾는 것과 staff 찾는 것이 필요하다
  • 처음에는 client부터 찾으며 선택 시 client의 campaign의 나올 것이고 선택하면 배정할 staff list가 나와야 매칭이 된다.
  • 무조건 campaign을 찾는 기능이 필요하다.
  • Assign이 find를 포함한다.
  • Include를 통하여 해당 use case가 다른 use case의 내용을 포함
    여러 use case가 이 use case의 내용을 공통적으로 갖고 있음
    
  • Find campaign이 아예 없어도 나머지 use case에서 campaign을 찾는 것이 없어지지는 않지만 include를 통해서 표현력을 높이기 위해 사용
  • extend는 option으로 선택적 수행을 뜻하며 sub가 main을 extend
  • Check campaign하는데 print invoice를 누르면 print가 되겠지만 association 직접 연결의 의미는 직접 print campaign inovoice를 할 수 있다는 의미
• Notation of Use Case Diagrams
  • Generalization
    • 공통된 기능(use case)과 역할(actor)을 generalizing을 통해 ‘super use case ‘ or ‘super actor’를 만든다.
    • 공통된 기능을 일반화 한다.
    • 공통된 역할을 일반화 한다.
    • Super class : 상속 관계, 밑에 있는 공통적인 것들을 위로 올리는 것
    • Campaign manager는 Staff contact의 역할도 할 수 있다.
    • Staff manager: contact담당 staff
    • Staff manager ← Campaign manager ( is a 관계)
    • 둘다 일반화 시키면 staff을 campaign에 assign하는 것에 없어져도 기능이 사라지지는 않는다.
    • ‘공통된 것이 이것이다’라는 것을 표현하는 것
    • include는 포함되어 있다는 뜻이고 이 것은 개념을 일반화 시키는 것
    • Description
      • 캠페인 매니저가 특정 캠페인을 선택한다. Assign되지 않는 staff의 list를 보여준다. Campaign에 assign될 staff을 선택한다.
    • Intention
      • 어떤 staff가 어떤 캠페인에 일하고 있는지 기록하고 싶어서 얼마나 일했는지, 연말 보너스 계산할 때 사용
• Drawing Use Case Diagrams
  1. Actor와 use case를 indentify
  2. Use case 우선순위
  3. 각 use case를 develop, 우선순위 정하며, 각 description작성
  4. Use case model 에 structure 추가: Generalization, include and extend relationships and subsystems