#action Blog 블로그 더하기 ##Blog {{{#!blog hyacinth 2010-03-22T01:26:24 Understanding Requirements 요구사항의 단계 * Inception * Elicitation * Elaboration * Negotiation * Specfication * Validation * Requirements management ==== Inception ==== Identify stakeholder 누가 이 소프트웨어에 관여하고 누가 참여하고 개발할 것인가. 사용자 입장에서, 개발자 입장에서 파악. 관리. 비용 관리 등. 각자의 관여자, 참여자간의 이해관계. Recognize multiple points of view 각 사용자들이 원하는 바 파악. Work toward collaboration 기획자, 개발자 등들을 어떻게 모아서 일을 할 것인가. ==== Eliciting Requerements ==== 이 단계에서 구체화 Collaborative Requirement Gathering 각 단계의 구체적인 requrements를 구체적으로 수집. 문제가 무엇인가. 솔루션 제시. QFD 우선순위를 정하는데 쓰는 도구. 직관적이 아닌 Formal하게. Building the Analysis Model Scenario-based elements Class-based elements Use-Cases 시나리오 단계에서 많이 사용. 기본적으로 actor를 만듬. Use-Case Diagram 작대기 사람이 formal한 actor (-_-;) 말풍선 등으로 entity들을 표현. Class Diagram || ''' Sensor ''' || || name/id || || type || || location || || area || || characteristics || || identify() || || enable() || State Diagram class diagram이 구체적으로 어떠한 값들을 가질 것인지, state를 정의. Negotiating Requrements 진행된 부분을 프로젝트에 관여된 사람들에게 보여주고 부족한 부분은 없는지 수정할 부분은 없는지. Validating Requirements Is each requirement consistent with the overall objectives? Have all requirements been specified at the proper level? Is the requirement really necessary or does it represent an add-on feature that may not be essential? Is each requirement unambiguous? 요구사항이 전체적인 프로젝트 목적과 맞는지 '' 쓸만할 정도로 디테일하게 되었는지. 모호하거나 쓸모없는 부분은 없는지. 구현 가능한지, 테스트가 가능한지 전체적으로. || Requirements -> Scenario -> Use-case -> Class Diagram -> State Diagram -> Negotiating Requrements -> Validating Requirements || ==== Requirements Modeling ==== Requirements Analysis Domain Analysis Use-case Diagram Activity Diagram 필요한 액션 step-by-step 순서도 Data Modeling ERD Class-Based Modeling CRC Modeling 오퍼레이션을 하는데 필요한 클래스가 무엇인지 명세 || Use-case Diagram -> Activity Diagram(Swimlane Diagram) -> Data Modeling(ERD) -> Class-Based Modeling -> CRC Modeling || }}} [[HTML(