요구사항정의 (UML)

전제, UML 문서를 가장 엄격히 준수했다고해서 상 줄 사람은 아무도 없다.

UML은 방법론이 되지만 절대적이지 않다. 풀어서 이야기 하자면 지침으로서 그 안에 내포된 뜻을 따르며 문서를 작성하면 성과에 이르게 되는 좋은 지침(방법)이지만 업무를 진행하다 보면 방법론이 맞지 않을 경우가 존재한다(꼬인다/아닌거같다). 그러한 경우 방법론을 많이 알고 있으면 그에 적합한 것을 적용하면 되지만 그렇지 않을 경우 과감하게 방법론을 제외한다. 또한 유용한 방법론(기법)을 만난다면 본인이 맡고있는 문제를 방법론에 적응 시키도록 최선을 다해본다.

 

 

좋은 객체 모델을 정직하게 구축하려면 구축하고 있는 시스템에 대해 근본적으로 중요한 질문들에 대해서만 엄격히 초첨을 맞추고, 불필요한 모델링 문제에서는 허우적거리지 말고 빠져 나온다. 그러한 철학이 use case 방법의 중심에 자리잡고 있다.

 

UML 객체 모델링 (발췌)

요구사항(requirement)이란 한 마디로 사용자가 지정한 기준으로서 시스템이 만족시켜야할 것들이다. 시스템과 관련하여 제안된 요구사항들을 다 모으면, 그것이 바로 시스템에 대해 사용자가 요구하는 행동과 기능을 정의 한 것이라고 할 수 있다.

요구사항은 보통 “반드시 shall” 나 “꼭 must” 같은 단어들을 포함하는 문장들로 구성된다. 그러나 아래와 같은 다양한 형태의 요구사항도 있을 수 있다.

요구사항은 파생되어 신규(파생) 요구사항이 발생될 수 있다

요구사항은 반드시 추적성(traceablility)을 요한다.

처음 개발을 진행한 사람과 중간에 시작한 사람 또는 개발을 하지 않고 인수인계만 받은 사람은 추적성에 근거하여 알아야하는 사항을 요구하여야 한다.

• 자료 획득 (capture) 단계

: 각 생명주기 단계별 분석 요소들과 (요구사항, 기능분석, 기능할당, 하드웨어/소프트웨어 설계, 코딩, 테스트, 문서화, 데이터) 각 요소들간의 할당/추적성 관계를 효과적으로 확보하는 방안을 말한다. 또한 이 정보를 해당 생명주기 단계 활동을 반복하는 동안에 어떻게 관리하며 각 요소들과 관계에 대한 변경과 갱신을 어떻게 관리할 것인지도 고려해야 한다.

• 자료 보고 (reporting)

: 자료 확보와 자료분석 및 축소의 결과를 즉시 효과적으로 보고할 수 있는 능력을 말한다. 특히 이것은 진행되는 프로젝트 문서에 반드시 포함되게 마련인 커다란 도표들을 포함한다.

기능(functional) 요구사항 - 다양한 기능적인 목표를 말한다

데이터(data) 요구사항 - 실제 요구한 데이터와의 정합도를 체크한다

성능(performance) 요구사항 - 대부분 반응 속도와 관련이 있다

용량(capacity) 요구사항 - 동시접속 처리에 대한 부분과 실제 용량과 관련이 있다

시험(testing) 요구사항 - 기능, 데이터, 성능, 용량에 관한 시험을 말한다

유스케이스 중요 세 가지 개념

• 범위 (scope) : 무엇이 진짜 목표 시스템인가?
• 일차 액터 (primary actor) : 누구의 목표인가?
• 수준 (level) : 그 목표 수준이 얼마나 높은가 혹은 낮은가?

객체지향 분야 세 가지 이론

• 데이터 중심 방법
  • 구조적 분석/설계에 경험이 있는 사람에게 익숙한 기법이다
  • 데이터 경계를 따라가면서 시스템을 분할하는 것이다
• 구조 중심 방법
  • 객체지향 프로그래밍 관점에서 시작되어 쌓아 올라간 것이다
• 시나리오 중심 방법
  • 사용 시나리오에 기반을 둔다
  • 사용 경계를 따라가면서 시스템을 분할한다

범주별 방법 강약

• Rumbaugh - OMT (domain model)
  • 새로운 시스템 개발에서 “문제 영역”을 탐구할 수 있도록 강력한 도구와 기법을 제공한다.
  • 반면에 “해법 영역”은 상대적으로 소홀히 다루었다
• Jacobson - OOSE/Objectory (use case)
  • 해법 영역에 관해서는 가장 유용하다.
  • 그런데 이 방법은 문제 영역에 대해서는 강조하지 않기 때문에 상위수준 설계단계를 지나서 진행할 때 정보가 충분하지 않다.
• Booch
  • 상세 설계와 구현 분야에서 매우 강하다.
  • 그러나 분석은 상대적으로 소홀히 다루었다
  시스템에 관해 근본적으로 중요한 질문에 대한 답을 찾을 수 있는 질문
  1. 누가 시스템 사용자 즉, 행위자인가, 또 그들은 무엇을 하려고 하는가?
  2. “실세계” 즉, 문제 영역 객체란 무엇이며, 그들간의 연관은 무엇인가?
  3. 각 use case 에서 필요로 하는 객체는 무엇인가?
  4. 각 use case 안에서 협력 collaborate하는 객체들은 어떻게 서로 교류 interact 하는가?
  5. 실시간 제어 문제는 어떻게 처리할 것인가?
  6. 시스템을 구축할 때 상세 수준(nuts-and-bolts) 구현은 어떻게 할 것인가?