L09-Requirement Engineering (Ch04)

Requirements engineering

• 고객이 시스템에서 요구하는 서비스와 시스템이 작동하고 개발되는 제약 조건을 설정하는 과정.
• 시스템 요구 사항은 요구 사항 공학 프로세스 중에 생성된 시스템 서비스 및 제약에 대한 설명이다.

What is a requirement?

• 요구 사항은 서비스나 시스템 제약에 대한 고수준의 추상적 진술부터 상세한 수학적 기능 사양까지 다양할 수 있다.
• 이는 요구 사항이 두 가지 기능을 수행할 수 있기 때문에 불가피하다.
  • 계약 입찰의 기초가 될 수 있으므로 해석이 가능해야 한다.
  • 계약 자체의 기초가 될 수 있으므로 상세히 정의되어야 한다.
  • 이 두 가지 진술 모두 요구 사항이라고 할 수 있다.

Requirements abstraction (Davis)

“회사가 대규모 소프트웨어 개발 프로젝트에 대한 계약을 체결하려면, 해결책이 미리 정의되지 않도록 충분히 추상적인 방식으로 요구 사항을 정의해야 한다. 요구 사항은 여러 계약자가 고객 조직의 요구를 충족하는 다양한 방법을 제안할 수 있도록 작성되어야 한다. 계약이 체결되면, 계약자는 클라이언트가 소프트웨어가 수행할 작업을 이해하고 검증할 수 있도록 시스템 정의를 보다 자세히 작성해야 한다. 이 두 문서 모두 시스템에 대한 요구 사항 문서라고 할 수 있다.”

Types of requirement

• User requirements
  • 시스템이 제공하는 서비스와 운영 제약을 설명하는 자연어 및 다이어그램의 진술. 고객을 위해 작성됨.

• System requirements
  • 시스템의 기능, 서비스 및 운영 제약에 대한 상세한 설명을 설정한 구조적 문서. 무엇이 구현되어야 하는지를 정의하므로 클라이언트와 계약자 간의 계약의 일부가 될 수 있다.

User and system requirements

Readers of different types of requirements specification

System stakeholders

• 시스템에 영향을 받는 모든 개인이나 조직으로, 정당한 이해관계를 가진다.
• 이해관계자 유형
  • 최종 사용자
  • 시스템 관리자
  • 시스템 소유자
  • 외부 이해관계자

Example: Stakeholders in the Mentcare system

• 환자 **시스템에 정보가 기록되는 사람들.
• 의사 **환자의 평가 및 치료를 책임지는 사람들.
• 간호사 **의사와의 상담을 조율하고 일부 치료를 수행하는 사람들.
• 의료 접수 담당자 **환자의 예약을 관리하는 사람들.
• IT 직원 **시스템 설치 및 유지 관리를 책임지는 사람들.
• 의료 윤리 관리자 **시스템이 환자 치료에 대한 현재의 윤리적 지침을 충족하는지 확인해야 하는 사람.
• 의료 관리 책임자 **시스템에서 관리 정보를 얻는 사람들.
• 의료 기록 직원 **시스템 정보가 유지되고 보존될 수 있도록 책임을 지며, 기록 유지 절차가 올바르게 시행되었는지 확인하는 사람들.

Agile methods and requirements

• 많은 애자일 방법론은 상세한 시스템 요구 사항을 작성하는 것이 시간을 낭비한다고 주장하며, 요구 사항은 매우 빠르게 변화한다.
• 따라서 요구 사항 문서는 항상 최신 상태가 아니다.
• 애자일 방법은 일반적으로 점진적인 요구 사항 공학을 사용하며 요구 사항을 '사용자 스토리'로 표현할 수 있다(3장에서 논의됨).
• 이는 비즈니스 시스템에는 실용적이지만, 사전 분석이 필요한 시스템(예: 중요한 시스템)이나 여러 팀에서 개발하는 시스템에는 문제가 될 수 있다.

 

 

 

Functional and non-functional requirements

Functional and non-functional requirements

• Functional requirements
  • 시스템이 제공해야 하는 서비스에 대한 진술, 특정 입력에 대한 시스템의 반응 및 특정 상황에서의 시스템 동작 방법을 설명한다.
  • 시스템이 수행하지 않아야 할 일을 명시할 수도 있다.

• Non-functional requirements
  • 타이밍 제약, 개발 프로세스에 대한 제약, 표준 등과 같이 시스템이 제공하는 서비스나 기능에 대한 제약 사항이다.
  • 종종 개별 기능이나 서비스보다 시스템 전체에 적용된다.

• Domain requirements
  • 작동 영역에서 시스템에 대한 제약 사항
  • 예: https://iansommerville.com/software-engineering-book/web/domain-requirements/

Functional requirements

• 기능 또는 시스템 서비스를 설명한다.
• 소프트웨어의 유형, 예상 사용자 및 소프트웨어가 사용되는 시스템 유형에 따라 달라진다.
• 기능 사용자 요구 사항은 시스템이 수행해야 하는 작업에 대한 고수준의 진술일 수 있다.
• 기능 시스템 요구 사항은 시스템 서비스를 자세히 설명해야 한다.

Mentcare system: functional requirements

• 사용자는 모든 클리닉의 예약 목록을 검색할 수 있어야 한다.
• 시스템은 각 클리닉에 대해 하루에 한 번 그날 예약에 참석할 것으로 예상되는 환자 목록을 생성해야 한다.
• 시스템을 사용하는 각 직원은 고유한 8자리 직원 번호로 식별되어야 한다.

Requirements imprecision

• 기능 요구 사항이 정확하게 명시되지 않으면 문제가 발생한다.
• 애매한 요구 사항은 개발자와 사용자에 의해 다르게 해석될 수 있다.
• 요구 사항 1에서 '검색'이라는 용어를 고려해보자.
  • 사용자 의도 – 모든 클리닉의 모든 예약에서 환자 이름 검색;
  • 개발자 해석 – 개별 클리닉에서 환자 이름 검색. 사용자가 클리닉을 선택한 후 검색.

Requirements completeness and consistency

• 원칙적으로 요구 사항은 완전하고 일관되어야 한다.
• Complete
  • 요구되는 모든 시설에 대한 설명을 포함해야 한다.

• Consistent
  • 시스템 시설의 설명에 충돌이나 모순이 없어야 한다.

• 실제로 시스템 및 환경의 복잡성으로 인해 완전하고 일관된 요구 사항 문서를 작성하는 것은 불가능하다.

Non-functional requirements

• 시스템의 속성과 제약을 정의하며, 예를 들어 신뢰성, 응답 시간 및 저장 요구 사항을 포함한다. 제약 사항으로는 입출력 장치의 기능, 시스템 표현 등이 있다.
• 비기능 요구 사항은 기능 요구 사항보다 더 중요할 수 있다. 이러한 요구 사항이 충족되지 않으면 시스템이 쓸모 없을 수 있다.

Types of nonfunctional requirement

Non-functional requirements implementation

• 비기능 요구 사항은 개별 구성 요소보다 시스템의 전체 아키텍처에 영향을 미칠 수 있다.
  • 예를 들어 성능 요구 사항을 충족하기 위해 구성 요소 간의 통신을 최소화하도록 시스템을 구성해야 할 수 있다.

• 보안 요구 사항과 같은 단일 비기능 요구 사항은 필요한 시스템 서비스를 정의하는 여러 관련 기능 요구 사항을 생성할 수 있다.
  • 또한 기존 요구 사항을 제한하는 요구 사항을 생성할 수도 있다.

Non-functional classifications

• Product requirements
  • 제공되는 제품이 특정 방식으로 동작해야 함을 명시하는 요구 사항으로, 예를 들어 실행 속도, 신뢰성 등을 포함한다.

• Organisational requirements
  • 조직의 정책 및 절차의 결과로 발생하는 요구 사항으로, 예를 들어 사용되는 프로세스 표준, 구현 요구 사항 등을 포함한다.

• External requirements
  • 시스템 및 개발 프로세스 외부의 요인에서 발생하는 요구 사항으로, 예를 들어 상호 운용성 요구 사항, 법적 요구 사항 등을 포함한다.

Examples of nonfunctional requirements in the Mentcare system

Goals and requirements

• 비기능 요구 사항은 정확하게 진술하기 매우 어려울 수 있으며, 불명확한 요구 사항은 검증하기 어려울 수 있다.
• Goal
  • 사용자에게 사용의 용이성과 같은 일반적인 의도. (그러나 이해관계자와 개발자 간에 해석의 차이를 초래할 수 있어 문제적이다.)

• Verifiable non-functional requirement
  • 객관적으로 테스트할 수 있는 측정을 사용하는 진술.

• 목표는 시스템 사용자의 의도를 전달하므로 개발자에게 유용하다.

Example: Usability requirements

• 시스템은 의료 직원이 사용하기 쉽고 사용자 오류를 최소화하도록 구성되어야 한다. (목표)
• 의료 직원은 4시간의 교육 후 모든 시스템 기능을 사용할 수 있어야 한다. 이 교육 후, 숙련된 사용자가 시스템 사용 중 발생하는 평균 오류 수는 시간당 2회를 초과하지 않아야 한다. (검증 가능한 비기능 요구 사항)

Metrics for specifying nonfunctional requirements

속성	측정 지표
속도	• 초당 처리된 트랜잭션 수• 사용자/이벤트 응답 시간• 화면 갱신 시간
크기	• 메가바이트• ROM 칩 개수
사용 용이성	• 교육 시간• 도움말 프레임 수
신뢰성	• 평균 고장 시간• 사용 불가능 확률• 고장 발생 비율• 가용성
견고성	• 고장 후 재시작 시간• 고장을 일으키는 이벤트 비율• 고장 시 데이터 손상 확률
이식성	• 대상 의존적 구문의 비율• 대상 시스템 수

 

 

 

Requirements engineering processes

Requirements engineering processes

• 요구 사항 공학(RE)에 사용되는 프로세스는 응용 도메인, 관련된 사람들 및 요구 사항을 개발하는 조직에 따라 매우 다르다.
• 그러나 모든 프로세스에 공통적으로 존재하는 몇 가지 일반적인 활동이 있다.
  • 요구 사항 도출 및 분석;
  • 요구 사항 명세;
  • 요구 사항 검증.

• 실제로 RE는 이러한 프로세스가 서로 얽히는 반복적인 활동이다.

A spiral view of the requirements engineering process

 

 

 

Requirements elicitation

Requirements elicitation and analysis

• 때때로 요구 사항 도출 또는 요구 사항 발견이라고 불린다.
• 고객과 협력하여 응용 도메인, 시스템이 제공해야 할 서비스 및 시스템의 운영 제약을 파악하는 기술 직원이 포함된다.
• 최종 사용자, 관리자, 유지 보수에 관련된 엔지니어, 도메인 전문가, 노동 조합 등이 포함될 수 있다. 이를 *이해관계자(stakeholders)*라고 한다.

Requirements elicitation

• 소프트웨어 엔지니어는 다양한 시스템 이해관계자와 협력하여 응용 도메인, 시스템이 제공해야 할 서비스, 필요한 시스템 성능, 하드웨어 제약, 기타 시스템 등을 파악한다.
• 단계에는 다음이 포함된다:
  • 요구 사항 발견 및 이해,
  • 요구 사항 분류 및 조직화,
  • 요구 사항 우선순위 지정 및 협상,
  • 요구 사항 명세화.

Problems of requirements elicitation

• 이해관계자는 자신이 정말 원하는 것이 무엇인지 모른다.
• 이해관계자는 자신의 용어로 요구 사항을 표현한다.
• 서로 다른 이해관계자가 상충하는 요구 사항을 가질 수 있다.
• 조직적 및 정치적 요인이 시스템 요구 사항에 영향을 미칠 수 있다.
• 분석 과정 중에 요구 사항이 변경된다. 새로운 이해관계자가 나타날 수 있으며 비즈니스 환경이 변화할 수 있다.

The requirements elicitation and analysis process

Process activities

• Requirements discovery
  • 이해관계자와 상호작용하여 그들의 요구 사항을 발견한다. 이 단계에서 도메인 요구 사항도 발견된다.

• Requirements classification and organisation
  • 관련 요구 사항을 그룹화하고 일관된 클러스터로 조직한다.

• Prioritisation and negotiation
  • 요구 사항의 우선순위를 정하고 요구 사항 충돌을 해결한다.

• Requirements specification
  • 요구 사항이 문서화되고 다음 스파이럴 단계에 입력된다.

Requirements discovery

• 요구되는 시스템 및 기존 시스템에 대한 정보를 수집하고, 이 정보를 통해 사용자 및 시스템 요구 사항을 정제하는 과정이다.
• 시스템 이해관계자와의 상호작용이 포함된다. 이해관계자는 관리자에서 외부 규제 기관까지 다양하다.
• 시스템은 일반적으로 다양한 이해관계자를 가진다.

 

 

 

Requirement elicitation technique 1: Interview

Interviewing

• 이해관계자와의 공식 또는 비공식 인터뷰는 대부분의 요구 사항 공학(RE) 프로세스의 일부이다.
• 인터뷰 유형
  • 미리 정해진 질문 목록에 기반한 폐쇄형 인터뷰
  • 이해관계자와 다양한 문제를 탐색하는 개방형 인터뷰.

• 효과적인 인터뷰
  • 열린 마음으로 요구 사항에 대한 선입견을 피하고 이해관계자의 말을 경청해야 한다.
  • 인터뷰이가 대화를 시작하도록 유도하기 위해 스프링보드 질문, 요구 사항 제안 또는 프로토타입 시스템 작업을 활용한다.

Interviews in practice

• 일반적으로 폐쇄형과 개방형 인터뷰를 혼합하여 사용한다.
• 인터뷰는 이해관계자가 수행하는 작업과 시스템과의 상호작용 방식을 전반적으로 이해하는 데 좋다.
• 인터뷰어는 시스템이 수행해야 할 작업에 대한 선입견 없이 열린 마음을 가져야 한다.
• 사용자가 무엇을 원하는지를 단순히 질문하기보다 요구 사항을 제안하여 시스템에 대해 이야기하도록 유도해야 한다.

Problems with interviews

• 응용 전문가가 자신의 작업을 설명하는 데 사용하는 언어가 요구 사항 엔지니어가 이해하기 어려울 수 있다.
• 인터뷰는 도메인 요구 사항을 이해하는 데 적합하지 않다.
  • 요구 사항 엔지니어는 특정 도메인 용어를 이해할 수 없다;
  • 일부 도메인 지식은 너무 익숙해서 사람들이 이를 표현하기 어렵거나 표현할 가치가 없다고 생각할 수 있다. (이해관계자 관점에서 명백한 사항을 잊고 말하지 않음)

 

 

 

Requirement elicitation technique 2: Ethnography

Ethnography

• 사회 과학자는 사람들이 실제로 작업하는 방식을 관찰하고 분석하는 데 상당한 시간을 보낸다.
• 사람들은 자신의 작업을 설명하거나 표현할 필요가 없다.
• 중요한 사회적 및 조직적 요인이 관찰될 수 있다.
• 민족지학적 연구는 작업이 일반적으로 단순한 시스템 모델이 제안하는 것보다 더 풍부하고 복잡하다는 것을 보여주었다.

Scope of ethnography (Effective for the following two types of requirements)

• 사람들이 실제로 작업하는 방식에서 유도된 요구 사항, 즉 프로세스 정의에서 제안하는 방식이 아닌 요구 사항.
• 다른 사람의 활동에 대한 협력 및 인식에서 유도된 요구 사항.

- 다른 사람들이 무엇을 하고 있는지에 대한 인식은 우리가 작업하는 방식을 변화시킨다.

• 민족지학은 기존 프로세스를 이해하는 데 효과적이지만, 시스템에 추가해야 할 새로운 기능을 식별할 수는 없다. (Nokia vs. Apple)

Ethnography and prototyping for requirements analysis

Focused ethnography

• 항공 교통 관제 프로세스를 연구하는 프로젝트에서 개발됨.
• 민족지학과 프로토타입을 결합한 방법이다.
• 프로토타입 개발은 민족지학적 분석을 집중시키는 질문을 남긴다.
• 민족지학의 문제는 기존 관행을 연구하여 역사적 기반이 있는 경우 더 이상 관련이 없을 수 있다는 것이다.

 

 

 

Requirement elicitation technique 3: Stories and scenarios

Stories and scenarios

• 시나리오와 사용자 이야기는 시스템이 어떻게 사용될 수 있는지에 대한 실제 사례이다.
• 이야기와 시나리오는 특정 작업을 위해 시스템이 어떻게 사용될 수 있는지에 대한 설명이다.
• 실용적인 상황에 기반하므로, 이해관계자는 이를 관련짓고 자신의 상황에 대해 이야기와 관련하여 의견을 제시할 수 있다.

User story example: Photo sharing in the classroom (iLearn)

• Jack는 Ullapool(스코틀랜드 북부의 한 마을)의 초등학교 교사이다. 그는 지역의 어업 산업을 주제로 한 수업 프로젝트를 계획했으며, 어업의 역사, 발전 및 경제적 영향을 살펴보도록 했다. 이 일환으로 학생들은 친척들의 추억을 수집하고 신문 아카이브를 활용하며 지역 어업과 어업 공동체와 관련된 오래된 사진을 모으도록 요청받았다. 학생들은 iLearn 위키를 사용하여 어업 이야기를 수집하고, SCRAN(역사 자료 사이트)을 통해 신문 아카이브와 사진에 접근한다. 그러나 Jack은 학생들이 서로의 사진을 촬영하고 댓글을 달 수 있도록 하고, 가족이 보유하고 있는 오래된 사진의 스캔본을 업로드할 수 있는 사진 공유 사이트가 필요하다.

Jack은 자신이 소속된 초등학교 교사 그룹에 이메일을 보내어 적절한 시스템을 추천해줄 수 있는 사람을 찾고자 한다. 두 명의 교사가 응답하고 둘 다 KidsTakePics라는 사진 공유 사이트를 사용하라고 제안한다. KidsTakePics는 교사가 콘텐츠를 확인하고 조정할 수 있도록 해준다. KidsTakePics가 iLearn 인증 서비스와 통합되어 있지 않기 때문에 그는 교사 계정과 학급 계정을 설정한다. 그는 iLearn 설정 서비스를 사용하여 KidsTakePics를 자신의 학급의 학생들이 볼 수 있는 서비스에 추가하여 로그인할 때 즉시 시스템을 사용해 모바일 장치와 학급 컴퓨터에서 사진을 업로드할 수 있도록 한다.

Scenarios

• 사용자 이야기의 구조화된 형태이다.
• 시나리오에는 다음이 포함되어야 한다:
  • 시작 상황에 대한 설명;
  • 사건의 정상적인 흐름에 대한 설명;
  • 문제가 발생할 수 있는 상황에 대한 설명;
  • 기타 동시 활동에 대한 정보;
  • 시나리오가 끝날 때의 상태에 대한 설명.

Uploading photos (iLearn)

• 초기 가정: 사용자 또는 사용자 그룹이 사진 공유 사이트에 업로드할 하나 이상의 디지털 사진을 보유하고 있다. 이들은 태블릿이나 노트북 컴퓨터에 저장되어 있다. 그들은 KidsTakePics에 성공적으로 로그인했다.
• 정상: 사용자가 사진 업로드를 선택하면, 컴퓨터에서 업로드할 사진을 선택하고 사진이 저장될 프로젝트 이름을 선택하라는 메시지가 표시된다. 또한 각 업로드된 사진과 관련된 키워드를 입력할 수 있는 옵션이 제공되어야 한다. 업로드된 사진은 사용자 이름과 로컬 컴퓨터의 파일 이름을 결합하여 이름이 지정된다.
• 업로드가 완료되면, 시스템은 프로젝트 조정자에게 새로운 콘텐츠를 확인하라는 이메일을 자동으로 전송하고, 사용자에게 완료되었다는 메시지를 화면에 표시한다.

Uploading photos

• 무슨 일이 잘못될 수 있는가:
• 선택한 프로젝트에 조정자가 연결되어 있지 않다. 학교 관리자에게 프로젝트 조정자를 지명해달라는 이메일이 자동으로 생성된다. 사용자는 자신의 사진을 볼 수 있도록 하는 데 지연이 있을 수 있음을 통보받아야 한다.
• 같은 이름의 사진이 이미 동일한 사용자에 의해 업로드되었다. 사용자는 같은 이름의 사진을 다시 업로드할 것인지, 사진의 이름을 변경할 것인지, 업로드를 취소할 것인지 물어야 한다. 사용자가 사진을 다시 업로드하기로 선택하면, 원본이 덮어쓰기 된다. 사진의 이름을 변경하기로 선택하면, 기존 파일 이름에 숫자를 추가하여 새로운 이름이 자동으로 생성된다.
• 기타 활동: 조정자가 시스템에 로그인해 사진이 업로드될 때 승인할 수 있다.
• 완료 시 시스템 상태: 사용자가 로그인되어 있다. 선택한 사진이 업로드되었고 상태가 '승인 대기 중'으로 지정되어 있다. 사진은 조정자와 업로드한 사용자에게 표시된다.

 

 

 

Requirements specification

Requirements specification

• 사용자 및 시스템 요구 사항을 요구 사항 문서에 작성하는 과정이다.
• 사용자 요구 사항은 기술 배경이 없는 최종 사용자와 고객이 이해할 수 있어야 한다.
• 시스템 요구 사항은 더 상세한 요구 사항이며, 더 많은 기술 정보를 포함할 수 있다.
• 요구 사항은 시스템 개발 계약의 일부가 될 수 있다.
  • 따라서 이러한 요구 사항이 가능한 한 완전한 것이 중요하다.

Ways of writing a system requirements specification

표기법설명

자연어요구 사항은 자연어로 번호가 매겨진 문장으로 작성된다. 각 문장은 하나의 요구 사항을 표현해야 한다.

구조화된 자연어요구 사항은 표준 양식이나 템플릿에 자연어로 작성된다. 각 필드는 요구 사항의 한 측면에 대한 정보를 제공한다.

설계 기술 언어이 접근 방식은 프로그래밍 언어와 유사하지만 시스템의 운영 모델을 정의하여 요구 사항을 명시하기 위한 더 추상적인 기능을 갖춘 언어를 사용한다. 이 접근 방식은 인터페이스 명세에 유용할 수 있지만 현재는 거의 사용되지 않는다.

그래픽 표기법텍스트 주석이 보완된 그래픽 모델을 사용하여 시스템의 기능적 요구 사항을 정의한다; UML 유스케이스 및 시퀀스 다이어그램이 일반적으로 사용된다.

수학적 명세이러한 표기법은 유한 상태 기계나 집합과 같은 수학적 개념에 기반한다. 이러한 명확한 명세는 요구 사항 문서의 모호성을 줄일 수 있지만, 대부분의 고객은 공식적인 명세를 이해하지 못한다. 그들은 이것이 자신들이 원하는 것을 나타내는지 확인할 수 없으며 시스템 계약으로 받아들이기를 꺼린다.

Requirements and design

• 원칙적으로 요구 사항은 시스템이 무엇을 해야 하는지를 명시해야 하며, 설계는 이를 어떻게 수행하는지를 설명해야 한다.
• 실제로 요구 사항과 설계는 분리할 수 없으며(깊게 연결되어 있음)
  • 시스템 아키텍처는 요구 사항을 구조화하기 위해 설계될 수 있다;
  • 시스템은 설계 요구 사항을 생성하는 다른 시스템과 상호 작용할 수 있다;
  • 비기능 요구 사항을 충족하기 위해 특정 아키텍처를 사용하는 것은 도메인 요구 사항일 수 있다.
  • 이는 규제 요구 사항의 결과일 수 있다.

Natural language specification

• 요구 사항은 다이어그램과 표가 보완된 자연어 문장으로 작성된다.
• 요구 사항 작성을 위해 사용되며, 표현력이 풍부하고 직관적이며 보편적이다. 이는 요구 사항이 사용자와 고객에 의해 이해될 수 있음을 의미한다.

Guidelines for writing requirements

• 표준 형식을 발명하고 이를 모든 요구 사항에 사용한다.
• 언어를 일관되게 사용한다. 필수 요구 사항에는 shall, 바람직한 요구 사항에는 should를 사용한다.
• 요구 사항의 주요 부분을 식별하기 위해 텍스트 강조를 사용한다.
• 컴퓨터 전문 용어 사용을 피한다.
• 요구 사항이 필요한 이유에 대한 설명(근거)을 포함한다.

Problems with natural language

• 명확성 부족
  • 문서의 가독성을 떨어뜨리지 않으면서 정밀성을 확보하기 어렵다.

• 요구 사항 혼란
  • 기능 요구 사항과 비기능 요구 사항이 혼합되는 경향이 있다.

• 요구 사항 통합
  • 여러 가지 다른 요구 사항이 함께 표현될 수 있다.

Example requirements for the insulin pump software system

• 요구사항 3.2
  • 시스템은 10분마다 혈당을 측정하고 필요한 경우 인슐린을 전달해야 한다. (혈당 변화는 비교적 느리게 진행되므로 더 빈번한 측정은 불필요하며, 덜 빈번한 측정은 불필요하게 높은 혈당 수준으로 이어질 수 있다.)
• 요구사항 3.6
  • 시스템은 매 분마다 자가 테스트 루틴을 실행해야 하며, 테스트할 조건과 관련 조치는 표 1에 정의되어 있다. (자가 테스트 루틴은 하드웨어 및 소프트웨어 문제를 발견하고 정상 작동이 불가능할 수 있다는 사실을 사용자에게 알릴 수 있다.)

Structured specifications

• 요구 사항 작성을 위한 접근 방식으로, 요구 사항 작성자의 자유가 제한되고 요구 사항이 표준 방식으로 작성된다.
• 이는 일부 유형의 요구 사항(예: 임베디드 제어 시스템 요구 사항)에는 잘 작동하지만, 비즈니스 시스템 요구 사항을 작성하는 데에는 너무 경직될 수 있다.

Form-based specifications

• 기능 또는 개체에 대한 정의.
• 입력 및 출처에 대한 설명.
• 출력 및 목적지에 대한 설명.
• 계산 및 사용되는 기타 개체에 필요한 정보에 대한 설명.
• 수행해야 할 작업에 대한 설명.
• 사전 및 사후 조건(적절한 경우).
• 함수의 부작용(있는 경우).

A structured specification of a requirement for an insulin pump

인슐린 펌프에 대한 요구사항의 구조화된 명세

• Insulin Pump/Control Software/SRS/3.3.2*
• 기능*: 인슐린 용량 계산: 안전 혈당 수준.
• 설명*: 현재 측정된 혈당 수준이 3에서 7 단위 사이의 안전 구역 내에 있을 때 전달할 인슐린 용량을 계산합니다.
• 입력*: 현재 혈당 측정값(r2), 이전 두 측정값(r0 및 r1).
• 소스*: 센서에서의 현재 혈당 측정값. 메모리에서의 다른 측정값.
• 출력*: CompDose—전달할 인슐린 용량.
• 목적지*: 메인 제어 루프.
• 동작*: 혈당 수준이 안정적이거나 감소하고 있는 경우, 또는 수준이 증가하고 있지만 증가율이 감소하고 있는 경우 CompDose는 0입니다. 수준이 증가하고 있고 증가율도 증가하고 있는 경우, CompDose는 현재 혈당 수준과 이전 수준 간의 차이를 4로 나누고 결과를 반올림하여 계산됩니다. 결과가 0으로 반올림되면 CompDose는 전달 가능한 최소 용량으로 설정됩니다. (그림 4.14 참조)

• 요구사항*: 혈당 수준의 변화율을 계산할 수 있도록 이전 두 측정값이 필요합니다.
• 사전 조건*: 인슐린 저장소에는 최대 허용 단일 용량의 인슐린이 최소한 포함되어 있어야 합니다.
• 사후 조건*: r0는 r1으로 대체되고, r1은 r2로 대체됩니다.
• 부작용*: 없음.

Tabular specification

• 자연어를 보완하는 데 사용된다.
• 여러 가능한 대체 행동 경로를 정의해야 할 때 특히 유용하다.
• 예를 들어, 인슐린 펌프 시스템은 혈당 변화율에 기반하여 계산을 수행하며, 표 형식의 명세는 다양한 시나리오에 대한 인슐린 요구 사항을 계산하는 방법을 설명한다.

Tabular specification of computation for an insulin pump

조건	동작
혈당 수치 감소 중 (r2 < r1)	CompDose = 0
혈당 수치 안정 (r2 = r1)	CompDose = 0
혈당 수치 증가 중이며 증가율 감소 중((r2 – r1) < (r1 – r0))	CompDose = 0
혈당 수치 증가 중이며 증가율 안정 또는 증가 중((r2 – r1) ≥ (r1 – r0))	CompDose = round((r2 – r1)/4)만약 반올림 결과 = 0이면CompDose = MinimumDose

Graphical notation: Use cases

• 유스케이스는 UML에 포함된 시나리오의 일종이다.
• 유스케이스는 상호작용의 행위자를 식별하고 상호작용 자체를 설명한다.
• 유스케이스 세트는 시스템과의 모든 가능한 상호작용을 설명해야 한다.
• 고수준 그래픽 모델에 더 상세한 표 형식의 설명이 보완된다(5장 참조).
• UML 시퀀스 다이어그램은 시스템 내 이벤트 처리의 순서를 보여줌으로써 유스케이스에 세부 사항을 추가하는 데 사용될 수 있다.

Use cases for the Mentcare system

The software requirements document

• 소프트웨어 요구 사항 문서는 시스템 개발자에게 요구되는 사항에 대한 공식적인 진술이다.
• 사용자 요구 사항의 정의와 시스템 요구 사항의 명세를 모두 포함해야 한다.
• 이것은 설계 문서가 아니다. 가능한 한 시스템이 무엇을 해야 하는지를 명시해야 하며, 어떻게 수행해야 하는지는 포함하지 않아야 한다.

Users of a requirements document

Requirements document variability

• 요구 사항 문서의 정보는 시스템 유형과 사용되는 개발 접근 방식에 따라 달라진다.
• 점진적으로 개발된 시스템은 일반적으로 요구 사항 문서에 세부 정보가 적다.
• 요구 사항 문서의 표준이 설계되었다(e.g. IEEE 표준). 이는 주로 대형 시스템 엔지니어링 프로젝트의 요구 사항에 적용된다.

The structure of a requirements document (요구 사항 문서의 구조)

장	설명
서문(Preface)	문서의 예상 독자를 정의하고, 버전 이력을 설명하며, 새로운 버전의 생성 이유와 각 버전에서 변경된 내용을 요약해야 한다.
소개(Introduction)	시스템의 필요성을 설명해야 한다. 시스템의 기능을 간략히 설명하고, 다른 시스템과 어떻게 작동할 것인지 설명해야 한다. 또한, 시스템이 소프트웨어를 의뢰한 조직의 전체 비즈니스 또는 전략적 목표에 어떻게 부합하는지 기술해야 한다.
용어집(Glossary)	문서에서 사용된 기술 용어를 정의해야 한다. 독자의 경험이나 전문 지식을 가정해서는 안 된다.
사용자 요구 사항 정의(User requirements definition)	사용자에게 제공되는 서비스에 대해 설명해야 한다. 비기능적 시스템 요구 사항도 이 섹션에서 기술되어야 한다. 이 설명에는 자연어, 다이어그램 또는 고객이 이해할 수 있는 기타 표기법을 사용할 수 있다. 제품 및 프로세스 표준도 명시해야 한다.
시스템 아키텍처(System architecture)	예상되는 시스템 아키텍처의 개요를 제시해야 한다. 시스템 모듈 전반에서 기능이 어떻게 분배되는지를 보여주며, 재사용되는 아키텍처 구성 요소가 강조되어야 한다.
시스템 요구 사항 명세(System requirements specification)	기능적 및 비기능적 요구 사항을 더 자세히 설명해야 한다. 필요할 경우 비기능적 요구 사항에 대한 추가 설명도 포함될 수 있다. 다른 시스템과의 인터페이스도 정의될 수 있다.
시스템 모델(System models)	시스템 구성 요소 간의 관계 및 시스템과 환경 간의 관계를 보여주는 그래픽 시스템 모델을 포함할 수 있다. 가능한 모델의 예로는 객체 모델, 데이터 흐름 모델, 의미적 데이터 모델 등이 있다.
시스템 발전(System evolution)	시스템이 기반을 두고 있는 기본 가정과 하드웨어 발전, 사용자 요구 변경 등에 따른 예상 변경 사항을 설명해야 한다. 이 섹션은 시스템 디자이너가 향후 변경을 어렵게 만들 수 있는 설계 결정을 피하는 데 도움이 될 수 있다.
부록(Appendices)	개발 중인 애플리케이션과 관련된 자세하고 구체적인 정보를 제공해야 한다. 예를 들어, 하드웨어 및 데이터베이스 설명이 포함될 수 있다. 하드웨어 요구 사항은 시스템의 최소 및 최적 구성을 정의하며, 데이터베이스 요구 사항은 시스템에서 사용되는 데이터의 논리적 구성과 데이터 간의 관계를 정의한다.
색인(Index)	문서에 대한 여러 개의 색인을 포함할 수 있다. 일반적인 알파벳 순 색인뿐만 아니라 다이어그램 색인, 기능 색인 등이 있을 수 있다.

 

 

 

Requirements validation

Requirements checking

• 유효성. 시스템이 고객의 요구를 가장 잘 지원하는 기능을 제공하는가?
• 일관성. 요구 사항 간에 충돌이 있는가?
• 완전성. 고객이 요구하는 모든 기능이 포함되어 있는가?
• 현실성. 사용 가능한 예산과 기술을 고려할 때 요구 사항을 구현할 수 있는가?
• 검증 가능성. 요구 사항을 검증할 수 있는가?

Requirements validation techniques

• 요구 사항 검토
  • 요구 사항의 체계적인 수동 분석.

• 프로토타입
  • 시스템의 실행 가능한 모델을 사용하여 요구 사항을 확인한다. 2장에서 다룸.

• 테스트 케이스 생성
  • 요구 사항을 확인하기 위해 테스트를 개발한다.

Requirements reviews

• 요구 사항 정의가 작성되는 동안 정기적인 검토를 실시해야 한다.
• 고객과 계약자 직원 모두가 검토에 참여해야 한다.
• 검토는 공식적(완성된 문서 포함)일 수도 있고 비공식적일 수도 있다. 개발자, 고객 및 사용자 간의 원활한 커뮤니케이션은 초기 단계에서 문제를 해결할 수 있다.

Review checks

• 검증 가능성
  • 요구 사항이 현실적으로 테스트 가능합니까?

• 이해 가능성
  • 요구 사항이 제대로 이해되고 있는가?

• 추적 가능성
  • 요구 사항의 출처가 명확하게 명시되어 있는가?

• 적응 가능성
  • 다른 요구 사항에 큰 영향을 미치지 않고 요구 사항을 변경할 수 있는가?

 

 

 

Requirements change

Requirements validation (motivation for requirements change)

• 요구 사항이 고객이 실제로 원하는 시스템을 정의하고 있음을 입증하는 것과 관련이 있다.
• 요구 사항 오류 비용이 높기 때문에 검증이 매우 중요하다.
  • 배달 후 요구 사항 오류를 수정하는 데 드는 비용은 구현 오류 수정 비용의 최대 100배에 이를 수 있다.

Changing requirements

• 시스템의 비즈니스 및 기술 환경은 설치 후 항상 변한다.
  • 새로운 하드웨어가 도입될 수 있으며, 시스템을 다른 시스템과 연결해야 할 수도 있고, 비즈니스 우선 순위가 변경될 수 있으며(이에 따른 시스템 지원 변경 포함), 시스템이 반드시 준수해야 할 새로운 법률 및 규제가 도입될 수 있다.

• 시스템에 비용을 지불하는 사람과 그 시스템의 사용자는 거의 동일하지 않다.
  • 시스템 고객은 조직적 및 예산적 제약으로 인해 요구 사항을 부과한다. 이는 최종 사용자 요구 사항과 충돌할 수 있으며, 배달 후 시스템이 목표를 달성하기 위해 사용자 지원을 위해 새로운 기능을 추가해야 할 수 있다.

• 대형 시스템은 일반적으로 다양한 사용자 커뮤니티를 가지며, 많은 사용자가 서로 상충하거나 모순되는 요구 사항과 우선 순위를 가진다.
  • 최종 시스템 요구 사항은 불가피하게 이들 간의 타협이 되며, 경험이 쌓이면서 종종 다양한 사용자에게 제공되는 지원의 균형이 변경되어야 함을 발견하게 된다.

Requirements evolution

Requirements management

• 요구 사항 관리는 요구 사항 공학 과정과 시스템 개발 동안 변화하는 요구 사항을 관리하는 프로세스이다.
• 새로운 요구 사항은 시스템이 개발되는 동안 및 사용에 들어간 후에 나타난다.
• 개별 요구 사항을 추적하고 의존 관계에 있는 요구 사항 간의 연결을 유지하여 요구 사항 변경의 영향을 평가할 수 있어야 한다. 변경 제안을 수립하고 이를 시스템 요구 사항에 연결하기 위한 공식적인 프로세스를 설정해야 한다.

Requirements management planning

• 요구 사항 관리에 필요한 세부 수준을 설정한다.
• 요구 사항 관리 결정:
  • 요구 사항 식별: 각 요구 사항은 다른 요구 사항과 교차 참조할 수 있도록 고유하게 식별되어야 한다.
  • 변경 관리 프로세스: 이는 변경의 영향 및 비용을 평가하는 일련의 활동이다. 이 프로세스는 다음 섹션에서 더 자세히 설명한다.
  • 추적 가능성 정책: 이 정책은 각 요구 사항과 요구 사항과 시스템 설계 간의 관계를 정의하며, 기록해야 할 사항이다.
  • 도구 지원: 사용 가능한 도구는 전문 요구 사항 관리 시스템에서 스프레드시트 및 간단한 데이터베이스 시스템에 이르기까지 다양하다.

Requirements change management

• 요구 사항 변경 수용 여부 결정
  • 문제 분석 및 변경 명세
    • 이 단계에서는 문제나 변경 제안이 유효한지 확인하기 위해 분석된다. 이 분석 결과는 변경 요청자에게 피드백으로 제공되며, 요청자가 보다 구체적인 요구 사항 변경 제안을 하거나 요청을 철회할 수 있다.
• 변경 분석 및 비용 산정
  • 제안된 변경의 효과는 추적 가능성 정보 및 시스템 요구 사항에 대한 일반적인 지식을 사용하여 평가된다. 이 분석이 완료되면 요구 사항 변경을 진행할지 여부에 대한 결정이 내려진다.
• 변경 구현
  • 요구 사항 문서와 필요한 경우 시스템 설계 및 구현이 수정된다. 이상적으로 문서는 변경 사항이 쉽게 구현될 수 있도록 구성되어야 한다.

Key points

• 소프트웨어 시스템에 대한 요구 사항은 시스템이 수행해야 할 작업을 설정하고 운영 및 구현에 대한 제약을 정의한다.
• 기능 요구 사항은 시스템이 제공해야 하는 서비스에 대한 진술이거나 수행해야 하는 계산 방법에 대한 설명이다.
• 비기능 요구 사항은 개발 중인 시스템과 사용되는 개발 프로세스에 제약을 부과하는 경우가 많다.
• 이들은 종종 시스템의 긴급 특성과 관련이 있으며, 따라서 시스템 전체에 적용된다.
• 요구 사항 공학 프로세스는 요구 사항 도출, 명세 및 검증을 포함하는 반복적인 프로세스이다.
• 요구 사항 도출은 요구 사항 발견, 요구 사항 분류 및 조직화, 요구 사항 협상 및 요구 사항 문서화와 같은 활동의 나선형으로 표현될 수 있는 반복적인 과정이다.
• 인터뷰 및 민족지학을 포함한 다양한 기술을 사용하여 요구 사항을 도출할 수 있다. 사용자 이야기와 시나리오는 논의를 촉진하는 데 사용될 수 있다.
• 요구 사항 명세는 사용자 및 시스템 요구 사항을 공식적으로 문서화하고 소프트웨어 요구 사항 문서를 만드는 과정이다.
• 소프트웨어 요구 사항 문서는 시스템 요구 사항에 대한 합의된 진술이다. 시스템 고객과 소프트웨어 개발자가 모두 사용할 수 있도록 조직되어야 한다.
• 요구 사항 검증은 유효성, 일관성, 완전성, 현실성 및 검증 가능성을 검사하는 과정이다.
• 비즈니스, 조직 및 기술 변화는 불가피하게 소프트웨어 시스템에 대한 요구 사항의 변화를 초래한다. 요구 사항 관리는 이러한 변화를 관리하고 통제하는 프로세스이다.