[ENG][아키텍처]Requirement Engineering

Error/Fault/Failure

Error/Fault/Failure 각각을 설명하세요.
Error
- Incorrect usage of software by users - Bad design by architects - Bad programming by developers - Inadequate testing by testers - Incorrect configuration by build members
Fault
- An incorrect statement - Wrong data type - Wrong formula in design document - Missing functionality in the system
Failure
- Faulty piece of code is executed leading to an incorrect state that propagates to the program’s output.

Error : 개발 개발자에의해 나온 도중에 나온 문제점
Fault: 기능 동작상의 비정상적 상황 발생 > 개발 끝난 이후에 나온 운용중에 나온 문제, 원치 않는 입력이나 원치 않는 상황
System Failure : Server의 system down > 서버나 component가 아예 멈추는 것

유입의 순서 : Error - Fault - Failure 
발견의 순서 : Failure - Fault - Error

 

Needs와 Requirements 무엇이 다른가?

needs
: 고객이 실제 원하는것, 인포말
requirement
: 시스템이 무엇을 할 것인가, 완전한 문장, 개발자 측면

 

Requirements 대상과 목적에 따른 구분 세 가지는?

Business Requirements
조직의 목표, 프로젝트 이유, Business Use Cases, 비즈니스 규칙은 프로젝트 수준이 아니라 전사적 수준으로 다루어야 함

User Requirements
사용자 엑세스 서비스 조건, 사용자 서비스, Functional Requirements, Non-functional Requirements

System Requirements
운영상의 제약, 시스템의 기능, System Specification,  Sub-system specification  Software Requirements Specification (SRS)

 

요구 추출 기법 대강 방법 말해보시오.

 

요구 모델링 목적은?

추상적 요구사항을 정확하고 상세하게 정의
- 식별된 고객의 needs 만족을 확인하는 방법 제공 
-  business owner’s view를 architect’s view으로 변환

 

요구 모델링 단계는?

 

모델링의 관점은?

구조 관점 : Structured Analysis
Data Flow Diagram (DFD)
Entity-Relation Diagram (ERD)
State Transition Diagram (STD)
Class Diagram

기능 관점 : Use Case Analysis, Goal and Scenario Based Analysis
Use Case Modeling (UC)
Goal-Scenario Modeling (GS)

행위 관점: Behavior Analysis
Sequence Diagram, Communication Diagram (UML)

 

요구사항 우선순위화, 우선순위는 어떻게 매기는가?

Value, Cost, Risk 제약 안에서 Product value를 최대화

 

요구 명세, 요구문서 품질 요소 세 가지

Correct  정확성
Complete  완전성
Consistent 일관성

 

Definition of SW Quality, 품질 요구란 무엇인가?

소프트웨어가 수행할 작업이 아니라 소프트웨어가 수행하는 방식을 설명하는 소프트웨어 요구사항(예: 소프트웨어 성능 요구사항, 소프트웨어 외부 인터페이스 요구사항, 설계 제약 및 소프트웨어 품질 속성).

서비스 품질 요구 사항은 시스템 또는 시스템 환경의 일부 속성을 설명하는 데 가장 자주 사용됩니다. 이러한 요구 사항은 솔루션에 대한 제약 조건입니다. 비기능적 요구사항이라고도 합니다.

 

품질 속성, Types of Quality Aspects, 품질 속성 네가지?

 

각 품질 속성의 관계는?

Process Quality : Quality of Life-cycle Process
Internal Quality 주로 개발자나 유지보수자가 보는 품질 속성으로 소프트웨어 실행 중 발견하기 힘든 속성임, Development-time 품질
External Quality 사용자 시각에서 소프트웨어의 runtime시 관찰되는 속성, Run-time 품질
Quality in Use : 소프트웨어가 포함된 환경의 품질에 대한 사용자 관점
환경에서 소프트웨어를 사용한 결과에서 평가

 

Quality Model of ISO 9126 , 6 Main Factors and Sub-Factors for each 

PERFUM - 향수

Functionality 기능을 사용할 때 오류가 있는가?, 기능들이 모두 잘 동작하는가?

 - Suitability
 - Accurateness
 - Interoperability
 - Compliance
 - Security

Usability 사용성은시스템의 입력을 준비시키고, 동작시키며, 출력하는데 드는 노력을측정함
 - Understandability
 - Learabiliiy
 - Operability

Efficiency 시스템이 프로세서 자원이나 디스크 용량, 메모리, 통신 대역폭 등을 얼마나잘 이용하는지에 관한 척도임
 - Time Behavior
 - Resource Behavior

Maintainability 소프트웨어를 얼마나 쉽게 수정할 수 있는지 측정한 느력, 수정에는 정정 개선 환경변화 수용, 요구사항 수용 등이 있다.
 - Analyzability
 - Changeability
 - Stability
 - Testability

Portability 소프트웨어가 다른 환경으로 이식될 수 있는 능력
 - Adaptability
 - Installability
 - Conformance(일치성)
 - Replaceability

Reliability 소프트웨어가 특정상황에서 특정기간 동안 일정 수준 이상으로 동작할 수 있는 능력
 - Maturity
 - Fault Tolerance
 - Recoverability

하위 특성 대강 나열

 

품질 요구 카테고리, 몇가지 예를 들어 보시오.

Availability 서비스가 이용가능하고 완벽하게 작동하는 기간에 대한 비율 (예: 가용성 99.9%

Integrity(무결성) 정보손실을 방지하고 시스템에 입력된 데이터의 정확성을 지키는 문제를 다룸

Interoperability(상호운영성) 시스템이 다른 장비와, 소프트웨어와 얼마나 쉽게 데이터와 서비스를 교환할 수있는지, 외부 하드웨어와 손쉽게 통합할 수 있는지를 말함

Performance 성능은 사용자의 조회 및 동작에 대한 시스템의 민첩한 정도를 말하며

Reliability 소프트웨어가 실행되는 특정시간 동안 장애가 발생하지 않을 확률을 말함 0.001%

Modifiability SW 설계나 코드가 얼마나 쉽고, 수정하기 쉬우며, 확장이 용이한가를 다룸

Scalability 성능이나 정확성 차이 없이 더 많은 사용자, 데이터, 서버, 트랜잭션, 네트워크 트래픽 등 다른 서비스를 수용할 수 있는 애플리케이션의 능력을 나타냄

 

Process of Requirement Engineering, 요구공학 절차는?

요구사항 추출
요구 사항 모델링과 분석
요구사항 우선순위화
요구사항 명세
품질요구
요구사항 검증
요구사항 관리

 

Agile Constructs for Requirement Management, 무엇인가요?

Agile Development: 빠른 프로토타이핑과 빠른 개발 경험에 비중을 둔 방법론 중 하나. 문서화나 과정 사양의 비중은 낮춤. ex) XP(eXtream Programming, 
 
요구사항에 대한 백로그를 만들고
계획과 우선순위를 하며
분할 그룹 생성 등에 이점을 줌
 
반복적으로 진행하고 결과물을 한 번에 배포하는 것이 아니라 나눠서 공유함. 사용자로부터 적극적으로 요구사항을 받아서 반영함.

 

Agile Principles, 무엇인가요?

짧은 변경주기를 적용한다.
- 변경을 수용할 수 있는 가능성을 확보한다. (60% baseline)
- 문서를 강조하지 않고 변경 장려, 개발 초기부터 테스트 병행을 권고
- Pair programming, informative workspace 유지
- 고객이 가장 중요하게 생각하는 것을 먼저 구현 
- 1～3주 내에 구현할 수 있는 요구사항(유저 스토리)

Requirements for Platform Software에서 고려해야할 품질은?
Scalability
Distributed processing capabilities

 

SW품질이란?

explicit req.(문서로 정확히 정의된 요구사항), 
implicit req.(예상되는 변경/요구) 모두 만족해야함.

 

SW품질 달성 방안

신뢰성 달성 방안 - Fault Tolerance

 

변경용이성 달성 방안 - 응집성, Information Hide, 커플링 제한, 인터페이스화, Polymorphism, Plug-in, Configuration files

효율성 달성 방안 - 계산 시간 축소, 큐 사이즈 제한, 수행시간 제한, 동시 처리

가용성 달성 방안 - Active Redundancy, Ping/echo, Heartbeat

사용성 달성 방안 - Cancel, undo, 쓰는 메뉴만 노출, 예상 시간, 진행률 표시

Security 달성 방안 : 메시지 무결성 검증, 사용자 인증, 노출 제한, 접근 제한, 데이터 암호화, 

Performance 달성 방안 : Periodic cleaning, 실행 횟수 제한, 동시성 도입, 큐 크기 제한

Testability 달성 방안 : 데이터 소스 추상화, 구조 복잡성 제거

Interoperability 달성 방안 : 인터페이스 관리, 

Modifiability 달성 방안 : 모듈 분할, 결합성 감소, 캡슐화, 중재자 사용

Traceability 달성 방안 : 고유한 데이터 조각(예: 주문 날짜/시간 또는 일련 번호)의 사용