[Software Architecture] Requirement Engineering - 2

Use Case Analysis

 

개요

• A means for capturing the desired behavior for the system under development
  • Communication 방법
  • 모든 요구사항이 도출되었는지 확인할 수 있는 방법
•  Benefit
  • 이해하기/읽기 쉬움
  • Customer와 합의 이루는데 도움
• 구성 (Use Case = Use Case Diagram + Texture)
  • Actor
    • 같은 특성을 모아서 표현 (Sam, Ivan -> Student)
    • 역할이 다르면 쪼개기도 함
    • 시스템에 직접 interface 하는 개체가 Actor가 될 수 있음
      - use the system
      - get  information from this system
      - provide information to the system
      - support and maintain the system
      - other system using this system
    • Checkpoint
      - 하나의 Actor가 최소 한 개 이상의 Use case와 연결 되어야 함
      - 최소 2사람 이상의 Actor에 해당해야 함
      - 비슷한 역할을 수행하면 합치는게 좋음
  • Use Case
    • 여러 Scenario가 Use Case의 Instance가 될 수 있음
    • 동사/동명사로 표현 (To-do list의 내용과 같이 표시하면 좋음)
    • Actor에게 visible한 event만 표시 = "Actor-activated Use Case"
    • Goal 중심으로 찾아야 함 / 이 시스템에 대한 Goal (What ar the goals of each actor?)
    • Are NOT functional decoposition
      - 기능분리 개념으로 접근하면 안됨 
         예) 너무 하위 Level operation으로 가져갈 필요 없음 
      - 어떤 내용을 이루기를 원하는지...의 수준으로 작성 필요
    • Text description 
      - Name
      - Brief description
      - Relationship with use cases
    • 절차
      - Actor 찾고
      - Use case 찾고
      - Write the use case
    • Checkpoint
      - present the behavior of the system
      - 기능요구사항 등을 판별했을때 Use-case에 최소 하나에는 mapping이 되어야 함
      - 직관적이고 자체로 설명이 가능하게 표현 필요 (모호하면 개명 필요)
      - Customer도 동일하게 이해할 수 있는 수준 -> 섦여이 충분한지 확인 필요
      - 하나 이상의 Actor와 연결되어야 함
      - 비슷한 Behavior가 존재하면 하나로 묶을 수 있음
  • Communicate-Associateion
    • 화살표가 있는 경우 = Initiate를 표시하고자 하는 경우, 보통은 화살표 없이
    • 각 화살표는 Whole Dialog 를 표시함
  • Texture 

 

---

Quality Attributes

 

Non-Functional Requirement

• IEEE 9126/25010
  • A Software requirement that described not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints, and software quality attributes
• Sommerville
  • “Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.”
• Wikipedia
  • “An requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.”

 

Quality Attributes (품질 속성)

• 시스템에 대해서 테스트 및 측정가능한 속성
  
  • 시스템이 얼마나 잘 만족하는지를 측정하는 수단
    - Availability, configurability, modifiability, performance, reliability, reusableity, security 등
  • Emergent proferty (SW 단독으로는 알 수 없는 것도 있음)
    
    
• SW 품질 = 이해당사자의 목적(기대하는 바)을 얼마나 잘 충족하는지에 대한 것
  
  
• Stakeholders and Quality Attributes 관련성
  
  • Stakeholder의 Need를 얼마나 잘 만족시키는지가 Quality Attributes Requirement로 변환 되어야 함
  • 예)
    - Increase market share -> Modifiablity, Usability
    - Maintain a quality reputation -> Performance, Usability, Availablity
    - Integrate with other system easiliy -> Interoperability, Portability, Modifiability
    
    
• Architecture and Quality Attribute 관련성
  • Qaulity Attribute Requirement -> Software Architecture Design (Key input이 됨)
• 문제점
  • Non-operational requirement
    - 쓰기 좋았으면 좋겠어요
    - 고성능이었으면 좋겠어요 등 모호한 표현이 될 수 있음
    
  • Quality Attribute 가 한 부분에만 포함되는지 아리까리한 부분이 있을 수 있음
  • 기대하는 수준이 다른 표현이 있을 수 있음
    - 고성능 = 어떤 수준? 인지 사람마다 다름
  • Inter-dependency가 다양하게 나타남
    - 성능 요구사항 -> 보안 요구사항에 영향을 주기도 함
       보안성을 높이면 사용성이 떨어질 수 있음
    - 100% 모두 만족시키기 어려울 수 있음
    
    
• Quality Requirements : Example
  • Product requirements
    - Availability 
    - Staff이 사용하기 쉬워야 한다 = Usability 
  • Organization requirements
    - 사용자는 인증 후 사용해야 한다 - Security
  • External requirements
    - 국제 표준을 맞추어야 한다 = Standard compliance
• 필요한 경우 참조할 만한 것들 존재

 

• MS Application Architecture Guid
  • Design Qualities
    - Conceptual Integrity, Maintainability, Reusability
  • Run-time Qualities
    - Availability, Interoperability, Manageability, Performance, Reliability, Scalability, Security
  • System Qualities
    - Supportability, Testability
  • User Qualities
    - Usability