[소프트웨어공학] 6장. 요구사항 개념

6장. 요구사항 개념

---

what-analysis(problem)

how-design(solution)

 

[ 요구공학 : Requirements Engineering (RE) ]

 

RE Tasks

• Understanding what the customer wants
• Analyzing needs
• Assessing feasibility (타당성 평가)
• Negotiation a reasonable approach (합리적 접근방식 협상)
• Specifying the problem unambiguously (문제를 명확하게 지정)
• Validating the specification (사양 유효성 검사)
• Managing the requirements (요구사항 검증관리)

RE Process (7 Tasks) ☠️

1. Inception (착수)
2. Elicitation (추출)
3. Elaboration (상세)
4. Negotiation (협상)
5. Specification (명세)
6. Validation (검증)
7. Management (관리)

1. Inception - 착수

A set of context free question

→ Better understanding of the problem

→ Effectiveness of communication activity

2. Elicitation - 추출

목표, 요구사항에 부합하는지, 사용법 등을 물어봄.

Difficulties of Elicitation

Problems of Scope : 경계가 불명확할 때

Problems of Understanding : 뭐가 필요한지 이놈들이 확실하게 모를 때

Problems of Volatility (변동성/휘발성) : 요구 변경

3. Elaboration - 상세(정규화)

정규화하는 동안 정보(데이터)가 확장 및 정제됨

analysis modeling action - Data(Information), Function, Behavior

 

💡 Requirement analysis에 대한 설명

1. information, function, behavior
2. basis for SW design
3. means to assess quality

(not : focus on why, not how → 틀림. how에 집중해야함)

4. Negotiation - 협상

reconcile the conflicts

각 주장 및 갈등을 조정하고, 각 요구사항의 영향을 평가

이해관계 식별 및 win-win condition 찾기

5. Specification - 명세(구체화)

Standard template

Consistent, understandable (논리적으로 일관성있고, 이해가능하도록)

6. Validation - 검증

Quality, standards established

애매함 없이 완벽하게

요구사항이 제한적이고 명확한지?

요구사항 모델이 시스템의 정보, 기능, 행동을 적절히 반영하고 있는가?

7. Management - 관리

프로젝트 진행 시 언제든지 요구사항 및 변경사항을 식별할 수 있게 관리

 

[ 시스템 분석가의 자격 ]

• 추상적, 논리적 개념화 능력
• 애매하거나 모순된 것들로부터 정확한 사실을 이끌어 낼 능력
• 고객의 환경을 이해할 능력
• HW, SW 요소를 고객의 환경에 적용시킬 능력
• 대화 능력, To see the forest for the tree

-

 

< Requirements Analysis > : 요구사항 분석

1. Specification of operation characteristics, interface, constraints
2. Allows the SW engineer to elaborate on basic requirements established during earlier requirement engineering tasks and build models that depict user scenarios, function activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.
3. Provides the SW designer with information, function, and behavior for architectural, interface, and component-level design
4. Provides the developer and customer with the means to assess quality
5. Focus is on "What" not "how"

1. 작동 특성, 인터페이스, 제약 조건의 구체화.
2. SW 엔지니어는 이전 요구사항 엔지니어링 작업 중에 수립된 기본 요구사항을 상세히 설명하고 사용자 시나리오, 기능 활동, 문제 클래스 및 문제 클래스의 관계, 시스템 및 클래스 동작, 변환되는 데이터 흐름을 설명하는 모델을 구축.
3. SW 설계자(디자이너)에게 아키텍처, 인터페이스 및 구성요소 수준 설계를 위한 정보, 기능 및 동작을 제공.
4. 개발자와 고객에게 품질을 평가할 수 있는 수단을 제공.
5. "어떻게"가 아니라 **"무엇"**에 초점을 맞춤.

 

Overall objectives and philosophy : 전반적인 목표와 철학

1. To describe what the customer requires : 고객이 요구하는 것을 설명
2. To establish a basic for the creation of a software design : SW 디자인 작성을 위한 기초 확립
3. To define a set of requirements that can be validated once the software is built. : SW구축 후 검증할 수 있는 요구사항 정의

< Analysis Modeling Rules > : 분석 모델링 규칙

1. The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high.
2. Each element of the analysis model should add to an overall understanding of SW requirements and provied insight into the information, function and behavior of the system.
3. Delay consideration of infrastructure and other non-functional models until design.
4. Minimize coupling throughout the system.
5. Be sure that the analysis model provides value to all stakeholders.
6. Keep the model as simple as it can be.

1. 모델은 문제 또는 비즈니스 영역 내에서 볼 수 있는 요구사항에 초점을 맞춰야 합니다. 추상화의 수준은 상대적으로 높아야 한다.
2. 분석 모델의 각 요소는 SW 요구 사항에 대한 전반적인 이해와 시스템의 정보, 기능 및 동작에 대한 통찰력을 제공해야 합니다.
3. 인프라 및 기타 비기능 모델에 대한 고려를 설계 시까지 연기합니다.
4. 시스템 전체에서 커플링을 최소화합니다.
5. 분석 모델이 모든 이해관계자에게 가치를 제공하는지 확인하십시오.
6. 모델을 가능한 한 단순하게 유지하세요.

< Domain Analysis > : 도메인 분석

“SW 도메인 분석”

→ 특정 애플리케이션 도메인의 공통 요구사항을 분석하는 것, 일반적으로 해당 애플리케이션 도메인 내의 여러 프로젝트에서 재사용하기 위한 것

“객체 지향 도메인 분석”

→ 공통 객체, 클래스, 하위 어셈블리 및 프레임워크 측면에서 특정 응용 프로그램 도메인 내에서 공통적이고 재사용 가능한 기능을 분석하는 것

< Requirement Modeling approaches > : 요구사항 모델링 분석법

1. Structured analysis : 구조화 분석

• Data and the processes that transform the data as separate entities. : 데이터 & 데이터를 개별 엔터티로 변환하는 프로세스
• Data object are modeled in a way that defines their attributes and relationships. : 데이터 개체는 속성과 관계를 정의하는 방식으로 모델링
• Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system.
• : 프로세스는 시스템을 통과할 때 개체가 데이터로 어떻게 변환하는지 보여주는 방식으로 모델링
•  
• 2. Object-oriented analysis : 객체지향 분석

• Focus on the definition of classes and the manner in which they collaborate with one another to effect customer requirement.
• : 클래스의 정의와 클래스가 고객 요구사항에 영향을 미치기 위해 협력하는 방식에 초점.
• UML and the Unified Process(UP)

OOA(Object-oriented analysis) is to define all classes that are relevant to the problem to be solved : 문제와 관련된 모든 클래스를 정의함

1. Basic user requirements must be communicated between the customer and the software engineer : 고객과 소프트웨어 엔지니어 간에 기본적인 사용자 요구 사항을 전달
2. Classes must be identified : 클래스는 식별되어야함
3. A class hierarchy is defined : 클래스 계층 정의
4. Object-to-object relationships : 객체 사이의 관계
5. Object behavior must be modeled : 객체 동작은 모델링되어야함
6. Tasks 1 through 5 are reapplied iteratively until the model is complete. : 모델이 완료될때까지 반복

---

1. Scenario-based Modeling

(1) Use-cases 는 시스템 외부에 존재하는 것과 시스템이 수행해야 하는 것을 정의하는 데 도움이 된다.

• 이해관계자의 요청에 응답하는 시스템의 동작 혹은 최종사용자가 시스템과 상호작용하는 방식에 대한 사례를 보여줌

(2) UML : Activity Diagram 은 특정 시나리오 내에서 상호작용의 그래픽 표현을 제공하여 Use-case를 보완한다.

(3) UML : Swinlane Diagram 은 Activity Diagram의 유용한 변형이며 모델러가 사용 사례에 의해 설명된 활동의 흐름을 표현하는 동시에 활동 사각형에 의해 설명된 활동에 대해 어떤 분석 클래스나 행위자가 책임이 있는지를 표시할 수 있다.

2. Class-based Modeling

클래스간의 관계 : aggregate(합계/부모&자식), multiplicity(연관), dependencies(종속/클라이언트&서버), package

Identifying analysis classes : 분석 클래스 식별

Specifying attributes : 속성 지정

Defining operations : 작업 정의

Modeling CRC (Class-Responsibility-Collaborator) : 클래스 책임 공동작업자(CRC) 모델링

 

< Class >

object-oriented thinking begins with the definition of a class, often defined as:

• template : 견본
• generalized description : 일반적인 설명
• blueprint, describing a collection of similar items : 청사진(유사한 항목들의 모임)

a meta-class (superclass) establishes a hierarchy of classes : 슈퍼클래스는 클래스의 계층 구조 설정

once a class of items is defined, a specific instance of the class can be identified : 클래스가 정의되면 클래스의 특정 인스턴스 식별 가능

 

What is a Class? → occurrences, things, external entities, roles, organizational units, places, structures

(발생, 사물, 외부 엔터티, 역할, 조직 단위, 장소, 구조)

 

< Encapsulation / Information Hiding >

개체는 데이터와 데이터를 조작하는 데 필요한 논리적 절차를 모두 캡슐화합니다.

 

< Methods(Operations, Services) >

클래스에 캡슐화되고 하나 이상의 데이터 속성에서 작동하도록 설계된 실행 절차.

메소드는 메시지 전달을 통해 호출됨.

• Entity Class : model / business class, 문제의 문장에서 직접 추출됨(ex: 평면도, 센서)
• Boundary Class : 사용자가 SW사용 시 보고 상호작용하는 인터페이스를 만드는 데에 사용(ex: 대화형 화면/ 인쇄물)
• Controller Class : 처음부터 끝까지의 작업 단위 관리.
  • 엔티티 개체의 생성/업데이트
  • 객체로부터 정보를 얻을 때 경계 객체의 인스턴스화
  • 객체간의 복잡한 통신
  • 개체 간/ 사용자와 프로그램 간 통신되는 데이터의 유효성 검사 등을 관리하도록 설계된다.

Responsibilities

• System Intelligence는 문제의 요구를 가장 잘 해결할 수 있도록 클래스 전체에 분산되어야함
• 각 책임은 가능한 일반적으로 명시되어야 함
• 정보 및 정보와 관련된 동작은 동일한 클래스 내에 있어야 함
• 한가지에 대한 정보는 단일 클래스로 지역화되어야 하며, 여러 클래스로 분산되면 안됨
• 관련 계층 간 책임을 적절할 때에 분담해야 함

< Collaborations >

클래스는 다음 두 방법 중 하나로 그들의 책임을 다한다.

1. 클래스는 자체 작업으로 자체 속성을 조작함
2. 클래스는 다른 클래스와 협력함.

Collaboration은 클래스 간의 관계를 식별한다.

공동작업자를 식별하는데에 도움이 되도록 클래스 간의 관계를 조사.

1. is-part-of relationship (aggregate) : 합계
2. has-knowledge-of relationship (associate) : 연관
3. depends-upon relationship (dependency) : 의존

 

3. Data Modeling

데이터 모델링

• Data Object
  • SW가 이해해야 하는 거의 모든 복합정보의 표현
  • 다른 복합 속성 정보 또는 속성에 의해 다음 요소를 가진 것들을 의미한다.
  • Entity, thing, Occurrence, Event, Role, Organizational unit, Place, Structure
  • 데이터 개체는 데이터만 캡슐화한다.

데이터 개체 및 속성

: 데이터 개체에는 개체의 측면(aspect), 품질, 특성, 설명자 역할을 하는 특정 집합이 포함된다.

이름 속성, 식별자, 설명 속성, 참조 속성 등

 

• Data attributes
  • 데이터 개체의 속성 정의
    1. 데이터 개체의 인스턴스 이름
    2. 인스턴스 설명
    3. 다른 테이블의 인스턴스 참조
  • 식별자 : 데이터 개체의 인스턴스를 찾고자 할 때 “key”가 된다.
• Relationships
  • 데이터 개체는 서로 다른 방식으로 연결된다.
  • 개체/관계 쌍 : 사람은 차를 소유한다, 사람은 운전보험에 가입되어 있다.
• Cardinality & Modality
  • 농도 : 데이터 모델은 주어진 관계에서 개체의 호출 횟수를 나타낼 수 있어야 한다.
  • 양상 : 관계가 발생할 필요가 없거나 선택사항일 경우 관계가 0이다. / 관계 발생이 필수인 경우 관계가 1이다.
    • • • • • • • • • • • • • • • • • • •