Requirements Engineering

Requirements Engineering

Requirements Engineering(요구 공학)은 사용자가 시스템에 요구하는 서비스를 만들고 시스템이 작동하는데 걸리는 제약 사항들을 정의하는 방법이다.

• Services : Functional Requirements (FR)
• Constraints : Non-Functional Requriments (NFR)

User Requirements

사용자로부터 도출한 요구사항을 정리한 것이다. 자연어나 표식도로 작성된 사용자의 요구들이다. 사용자에 의해 정의된다. 사용자에게 원하는 요구사항이 맞는지 확인하며 비즈니스적인 관점이다.
ex) "의료 시스템의 달마다 들어가는 약의 비용을 한번에 알 수 있으면 좋겠어"라는 사용자들의 요구

System Requirements

사용자의 요구사항을 만족하기 위해서 어떤 시스템을 구축해야 하는 지를 규격화된 문서로 정리해놓은 것이다. 시스템의 작동 원리나 서비스, 제한사항들을 적어놓는다. 개발자들을 위한 것이며 개발을 위해서 무엇을 해야 하는지를 확인한다.
ex) 그 달 마지막 날 진료시간 전에 각각의 진료에 무슨 약이 얼마나 들어갔는지에 대한 데이터를 모은다. 데이터를 모아서 여러가지 분야로 정리한다. 비용에 대한 보고서를 작성하여 사용자가 불 수 있게 한다.

System Stackholders

시스템에 영향을 받거나 주는 모든 사람이나 단체를 말한다.

• User
• Designer
• System Analyst
• Training and User Support
• Business Analyst
• Technical Author
• Project Manager
• Customer

---

FR / NFR

Funtcional Requirements(FR)

시스템이 필수적으로 수행 가능한 서비스(기능)들을 말한다. 특정한 입력에 어떻게 반응하는지, 특정한 상황에 어떻게 동작하는지를 말해 놓은 것이다.

• Functional User Requirement : 전체적인 시스템이 무엇을 해야하는지를 자연어나 높은 수준의 언어로 적어놓은 것을 의미한다. ex) 모든 약들의 비용을 정리해야 한다
• Functional System Requirements : 각각의 서비스(요구사항)를 달성하기 위해 무엇을 해야하는 지 자세하게 적어놓은 것을 의미한다. ex) 매일 매 진료마다 어떤 약이 청구되는지 기록해야 한다.

대부분이 자연어로 작성되기 때문에 알아보기 편하다는 장점이 있다. 하지만 보는 사람에 따라 해석의 여지가 달라질 수 있다는 단점이 있다. 예를 들어, "찾기"라는 서비스에 대해서 찾는 범위를 어디로 정하냐에 따라서 서비스가 완전히 달라질 가능성이 있다.
규명된 요구사항은 Complete와 Consistenet(C&C)를 완수해야한다.

• Complete : 사용자가 원하는 기능상의 모든 요구사항을 완수해야한다.
• Consistent : 설명과 시스템의 작동 사이에 차이가 있으면 안된다.

Non-Functional Requirements(NFR)

시스템적으로 구현 불가능한 제약사항들을 말한다. 개발 과정의 제약, 타이밍 문제 등등이 해당된다. 각각의 서비스나 요구사항에 대해서 말하기 보단 전체적인 시스템에 대해서 말하는 경우가 많다.
시스템의 속성이나 제한 사항을 정의한다.

• 속성 : 종속성, 반응 시간, 저장 공간, I/O 등등
• 제한 사항 : IDE의 제한사항, 프로그래밍 언어의 제한사항, 개발 방법의 제한사항

NFR은 시스템 전체에 영향을 줄 가능성이 높기 때문에 굉장히 중요하며 무슨 영향을 줄 지를 정확히 말해놓아야 한다.
ISO 26262

---

Quality Attributes

시스템의 측정 가능하고 테스트 가능한 속성들을 의미한다.

• 시스템이 요구사항을 잘 만족하는지를 확인하기 위해 사용한다.
  • 성능, 구현도, 보안, 유지 보수성 등등...
• 시스템들은 각각의 속성에 따라 요소들의 중요도가 다르다. 은행 시스템은 보안이 중요할 것이고, 게임은 성능이 중요할 것이다. 특정한 기준을 마련하여 이를 만족하는지 확인한다.
• Emergent properties : 시스템을 다 만들고 나서야 확인할 수 있는 속성을 의미한다. 아무리 작은 시스템들이 속성을 다 만족해도 합치면 나타나는 문제점이 있을 수 있다. 그렇기 때문에 전체 시스템에서 속성을 정의하는 과정은 중요하다.
  • ilities
  • ities
  • ness
  • others

Quality에는 Internal Quality와 External Quality가 있다. Process Quality를 통해서 개발 조직의 성숙도나 요소들을 점검한다. 그 후 소프트웨어 개발을 거친다.

• Internal Quality : 사용자가 알 수 없는 내부적인 요소이다. ex) maintanability
• External Quality : 사용자가 알거나 느껴지는 외부적인 요소이다. ex) security
  나온 제품에 대해서 Quality를 확인할 수 있는데, Quality in Use라고 부른다.
  

ISO/IEC 25010

System and sofrware Quality Requirements and Evaluation(SQuaRE)는 여러가지 PRoduct Quality와 Quality in Use를 정리해 놓은 모델이다.

• Product Quality
  • Function Sustability : 기능 적합성
  • Reliability : 신뢰성
  • Performance Effciency : 성능
  • Usability : 사용성
  • Maintability : 유지보수성
  • Security : 보안
  • Compability : 호환성
  • Portability : 이식성
• Quality in use
  • Satisfaction : CX(Customer eXperience) 라고도 불린다. 고객의 만족도를 말하며 사용이 쉬운지, 신뢰 가능한지, 기분이 좋고 편안한지 등등이 모두 CX이다. 오늘날 CX는 굉장히 중요한 요소로 자리 잡았다.
    • Usefulness
    • Trust
    • Pleasure
    • Comfort
  • Effectiveness : 효율성
  • Freedom for risk : 위험 회피도
  • Effciency : 성능
  • Context Converage : 정황 범위

---

Goals and Requrements

NFR은 상태를 정의하고 판단하기 어려운 경우가 많이 있다. 시스템적으로 구현이 불가능하기 때문에 수치화하기도 쉽지 않고, 전체 시스템에 대해서 얘기하기 때문에 딱 말하기 어렵다.
Quality factor : Usability. 사용성에 대해서 말한다.

• Verifiable Non-Functional Requirement(System Requirement) : 어떤 부분에 대해서 수치화 할 수 있고 테스트 가능한 NFR이다.
• Goal(User Requirement) : 사용자의 대중적인 관점으로, "사용하기 쉬움"에 집중한다. 수치화하기 힘들며 테스트도 어렵기 때문에 Non-Verifiable NFR이라고도 불린다.

Goal Analysis

Goal Analysis는 추상적이고 수치화하기 어려운 Goal을 분석하여 알기 쉽게 하는 과정이다. Goal Tree Analysis를 이용하기도 한다.

• 시스템이 왜 필요한지 집중한다. 다시 말해 사용자들의 Goal인 "why"를 표현한다.

• Goal refinement는 특정한 요구사항에 도달하기 위해 필요하다. 문서나 정규화로 goal을 재정의한다.

• Goal evolution : Refine, elaborate, operationalize같은 과정을 거친다.

• Goal hierachies : 구조를 통해 refinement와 alternative를 보여준다.

• Soft Goal : NFR(Quality)로, 모두 만족하지는 않는다.

• (Hard) Goal : FR으로, 기능 요구사항을 말한다. 모두 만족해야 한다.
  

Goal Elaboration

• higher goals로 갈 수록 "Why"가 많아진다.(context)
• lower goals로 갈 수록 "How"가 많아진다.(operations)
• alternative를 찾다보면 "How else"가 나온다.
  
• (+)는 기능이 수행되도록 돕는다.
• (++)는 기능이 수행되도록 만든다.
• (-)는 기능이 수행되지 않도록 방해한다.
• (--)는 기능이 수행되지 않도록 한다.

기차의 예시

---

Requirements Engineering Process

RE process는 다음과 같은 단계로 나뉘어진다.
1. Requirements elicitation and analysis
2. Requirements specification
3. Requirements validation
4. Requirements change management

Requirements elicitation and analysis

user requirement와 system requirement를 파악한다. 파악하는 내용들은 아래와 같다.

• 시스템이 구현하는 기능을
• 시스템이 제공하는 서비스
• 구현하기 위해 필요한 성능
• 하드웨어적인 제한사항
• 그 외 고객이 원하는 모든 것들...

Requirements elicitation은 많은 어려움이 있는데 그 이유는 다음과 같다.

• 고객은 실제로 자신이 무엇을 원하는지 모른다. 자신이 무엇을 원하는지 모르는데 요구사항을 제대로 전달 할 수 있을리가 없다.
• 고객은 자신들의 용어를 사용해서 요구사항을 나타낸다. 그 용어를 개발자에 맞게 바꿔야 한다.
• 고객들간에 요구사항이 다를 수 있고, 갈등을 만들어낸다.
• 조직이나 행정적인 부분이 요구사항에 영향을 줄 수 있다.
• 요구사항 파악 과정에서 요구사항이 바뀔 수 있다. 실시간으로 변하는 환경에 따라 바뀌거나 새로운 고객이 추가되며 요구사항이 늘어날 수 있다.
  

Requirements elicitation

user requirement를 확인한다. Requriemets elicitation에는 다음과 같은 4가지 과정이 있다.

• Requirements discovery
• Requirements classification and organization
• Prioritization and negotiation
• Requirements specification
  

requirements discovery는 Requirements ELication의 활동으로, 요구사항을 찾는 과정이다. requirements discovery에서 사용하는 기술은 다음과 같다.

1. Requirements workshop : 프로젝트를 만나는 사람들이 모여서 워크샵을 거친다.
2. Brainstorming
3. Storyboards (Use-Case scenario)
4. Interviews
5. Questionnaires
6. Role playing
7. Prototypes
8. Customer requirement specification review

Requirements Analysis

system reqirements를 확인한다.

SASD

OOAD

Requirements specification

파악한 requirement들을 토대로 SRS(Software requirements specification)를 만든다. 요구사항들은 실제 시스템 개발과 차이가 있기에 이 차이를 줄이고자 SRS를 만들어 정리한다.

Software Requirements Document

공식적인 내용이 적혀있는 문서들의 집합으로 "무엇"을 개발해야 하는지가 적혀있다. user requirement와 system requirement에 대한 정의가 모두 들어가 있으며 "어떻게"하기 보단 "무엇"을 해야하는지에 대한 내용이 많게 때문에 design document의 성질을 가지고 있진 않다.

좋은 Specification을 위해 들어가야 하는 내용은 다음과 같다

• Valid (Correct)
• Unambiguous
• Complete
• Understandable (Clear)
• Consistent
• Ranked
• Verifiable
• Modifiable
• Traceable

SRS Conent

SRS의 내용은 다음과 같은 내용이 들어가야 한다.
– Functionality : 소프트웨어가 무엇을 하는가?
– External interfaces : 소프트웨어가 사람, 하드웨어, 다른 소프트웨어와 어떻게 소통하는가?
– Required performance : 속도, 반응 시간, 메모리 사용량 등은 어느정도인가?
– Quality attributes : Quality를 만족하는가?
– Design constraints imposed on an implementation : 구현할 때 어떤 언어를 써야하며, 제한사항은 없는가?

SRS를 만들 때 자주 실수하는 부분은 다음과 같다.

SRS는 정의되어있는 standard가 있다.
IEEE standards 830-1998

Requirements validation

require가 실현 가능하고 시스템이 사용자가 원하는 방향으로 만들어졌는지를 확인한다. validation은 다음과 같은 요소를 확인한다.

• Validity
• Consistency
• Completeness
• Realism
• Verifiability

validation은 다음과 같은 기술이 있다.

• Requirements reviews
• Prototyping
• Test-case generation

Requirements change management