Transcript Software Requirements

Software Requirements
What is a requirement?
Requirement?
 소프트웨어 시스템이 제공하는 기능과 시스템을 운
용하는데 따르는 제반 제약사항을 기술
 고수준에서 추상적으로 기술한 것으로부터 수학적
함수와 같이 상세하게 기술한 것에 이르기까지 다양
Requirement의 양면성
 계약 요청으로서의 성격 --> 자유롭게 해석할 여지
가 필요
 계약 자체로서의 성격 --> 상세하고 명확하게 정의
되어야 할 필요l
 2가지 모두 요구라 할 수 있음
Types of requirement
사용자 요구 (User requirements)
 시스템이 제공하는 기능과 시스템 운용상의 제약사항
을 자연어나 도표를 사용하여 비정형적으로 기술
 발주자를 위하여 작성
시스템 요구 (System requirements)
 시스템 서비스를 상세하게 기술한 구조화된 문서
 발주자와 개발자 사이의 계약서로 작성
소프트웨어 명세 (Software specification)
 설계 및 구현 단계에서 사용하기 위하여 소프트웨어
시스템에 관하여 상세하게 기술
 개발자를 위하여 작성
요구 정의 및 명세
Requirements definition
1. The software must provide a means of repr esenting and
1. accessing external files created by other tools.
Requirements specification
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
Functional & non-functional
requirements
기능적 요구 (Functional requirements)
 시스템이 제공하는 기능이나 서비스를 기술
 주어진 상황에서 특정 입력에 대하여 어떻게 반응해
야 하는지를 기술
비기능적 요구 (Non-functional requirements)
 시스템이 제공하는 기능이나 서비스에 대한 제약사항
 반응시간, 개발절차, 적용 표준 등
응용영역 요구 (Domain requirements)
 개발대상영역의 특성을 반영하기 위한 요구사항
 도서관 시스템에서 지적재산권으로 인하여 시스템이
지켜야 할 사항 등
Functional requirements(1)
기능적 요구: 외부로 보이는 시스템의 모습
기능적 요구는 다음 사항에 종속적
 소프트웨어의 종류
 소프트웨어의 사용자
 소프트웨어가 사용되는 시스템의 종류
요구의 구분에 따라 상세도에 차이
 사용자 요구: 시스템의 기능을 고수준에서 기술
 시스템 요구: 시스템의 기능을 상세히 기술
Functional requirements (2)
기능적 요구의 예
 사용자는 데이터베이스에 저장된 자료의 전부 또
는 일부를 검색할 수 있어야 한다.
 시스템은 문서저장소에 저장된 문서를 사용자가
볼 수 있도록 적절한 문서편집기를 제공하여야 한
다.
 모든 주문에는 유일한 식별자(ORDER_ID)를 부여
함으로써, 고객의 영구 계정으로 복사하여 보존할
수 있어야 한다.
 교재 100-101쪽
Non-functional requirements (1)
시스템의 특성 및 운용상의 제약사항을 기술
 신뢰도, 반응시간, 자료 처리량, …
 메모리 용량, 입출력장치의 성능, platform, …
 CASE 도구, 프로그래밍 언어, 개발방법, …
비기능적 요구가 기능적 요구보다 더욱 중요
 비기능적 요구를 충족시키지 못하면 시스템은 완전
히 사용할 수 없음
 기능적 요구는 충족되지 못한 부분만 사용하지 않음
Non-functional requirements (2)
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Non-functional requirements (3)
비기능적 요구의 예
 Product requirement
 4.C.8 시스템과 사용자 사이의 모든 통신은 Ada 문자 세트
로 표현 할 수 있어야 한다.
 Organizational requirement
 9.3.2 시스템 개발 절차 및 산출물은 XYZCo-SP-STAN95에 규정한 바에 따라야 한다.
 External requirement
 7.6.5 고객의 이름과 시스템에서의 사용하는 개인식별번호
를 제외한 모든 개인 정보를 노출시켜서는 안 된다.
Requirements measures
Pro perty
Speed
Size
Eas e of u se
Rel iabi li ty
Rob u st ness
P ortabi li ty
Meas ure
P ro cess ed t rans acti o ns /s econ d
User/ Event res po n se ti me
Screen refresh t ime
K By tes
Nu mb er o f RAM ch ip s
Train in g time
Nu mb er o f h elp frames
Mean ti me t o failu re
P ro b ab il ity o f u n av ailab ili ty
Rat e of failu re o ccu rren ce
Av ai lab i lit y
Time to rest art aft er failu re
P ercent ag e o f event s caus in g fail ure
P ro b ab il ity o f d ata co rru pt io n on fail ure
P ercent ag e o f targ et d ep end ent st at ement s
Nu mb er o f t arget sy st ems
Requirements Engineering Processes(1)
요구를 발견하고, 분석하며, 확인하는 과정
개발대상 영역, 참여하는 사람, 개발팀에 따라
다양한 절차를 사용
일반적인 절차





요구추출 (Requirements elicitation)
요구분석 (Requirements analysis)
요구기술 (Requirements specification)
요구확인 (Requirements validation)
요구분석명세서 작성 (Requirements Documents)
Requirements Engineering Processes(2)
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
Requirements Engineering Processes(3)
요구의 추출, 분석, 기술 절차
Requir ements
definition and
specification
Requirements
validation
Process
entry
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
Requirements Elicitation(1)
요구 추출
 응용영역에 관하여 조사하여 시스템이 제공해야 할
기능과 시스템 운용상의 제약사항을 발견하는 작업
 많은 제3의 관련자(stakeholders)들이 존재
 최종사용자
 경영자
 유지보수자
 응용영역 전문가
 노동조합
Requirements Elicitation(2)
요구 추출의 어려움





관련자들이 자신이 진실로 원하는 것을 모름
관련자들은 요구를 표현할 때 자신의 용어를 사용
관련자들의 요구가 서로 충돌
조직상 또는 정책적 요인이 시스템 요구에 영향
새로운 관련자의 출현과 기업환경의 변화로 인한
잦은 요구 변경
정보 수집 방법
 인터뷰
 설문조사
 현장 실사
인터뷰 기법(1)
인터뷰란?
 개발대상조직의 구성원 및 필요한 분야의 전문가
와 직접 대화하여 정보를 수집하는 방법
 인터뷰를 통하여 수집하는 정보
 조직 안에서 수행하는 일의 수행과정
 요구되는 다양한 데이터
 개인의 임무를 완수하기 위해 요구되는 업무 진행과정
등에 관한 정보
 분석가는 분석 대상 시스템을 완벽하게 이해할 필
요가 있음
인터뷰 기법(2)
인터뷰 가이드라인
 누구(WHO): 분석 과정 참여자 및 역할, 시스템
사용자
 무엇(WHAT): 현재 상태 및 문제점, 시스템의 기
능
 언제(WHEN): 시스템의 설치 시기
 어디(WHERE): 시스템의 사용 장소
 왜(WHY): 시스템의 개발 사유
 어떻게(HOW): 시스템의 운용상 제약 조건
인터뷰 기법(3)
인터뷰 계획
 사전 준비
 관련 서적 탐독 및 Domain 용어 숙지
 구체적인 인터뷰의 목적 확립
 인터뷰 대상 결정: 다양한 레벨의 고객
 실행 계획
 인터뷰 대상이 준비할 수 있는 여유를 가지도록
 인터뷰 대상의 업무에 지장을 주지 않도록: 한 시간 정도
 질문의 유형과 질문의 구조를 준비
인터뷰 기법(4)
질문의 유형
 열린 질문 (open questions)
 닫힌 질문 (closed questions)
 추가 질문 (probes questions)
인터뷰의 구조
 피라미드 구조(pyramid structure): closed --> open
 깔때기 구조 (funnel structure): open --> closed
 다이아몬드 구조(diamond structure): closed --> open
--> closed
인터뷰 기법(5)
인터뷰할 때 주의할 사항
 인터뷰를 성공적으로 진행하여 필요한 정보 획득
 분석가는 주도적으로 인터뷰를 진행
 정직하고 직접적으로 자신의 의사를 표현
 인터뷰에 응하는 사람의 기분을 상하지 않도록 진
행
 상대방을 속박하거나 마음을 불편하게 하는 질문
은 회피
설문지(1)
설문지란?
 설문 문항을 통하여 간접적으로 정보를 모으는 방
법
 사람들의 자세, 믿음, 행위 등에 관한 정보 획득
 열린 질문 및 닫힌 질문 가능
 많은 사용자의 응답을 구하여 정량화할 수 있음
 인터뷰를 수행하기 전에 예상되는 문제점이나 논
쟁의 대상을 미리 파악하는데 사용
 분석가는 설문지를 통하여 수집할 정보를 사전에
결정
설문지(2)
설문지가 적당한 경우




사람들이 지역적으로 널리 분산되어 있는 경우
시스템에 의해 영향 받는 사람이 많은 경우
시스템에 대한 전체 의사가 필요한 경우
현재 시스템의 문제점을 파악하고 싶은 경우
설문지의 주의점





직접적인 교류가 불가능 함을 전제
명확히 이해할 수 있고, 논리적인 순서대로 흐르는 질문
열린 질문의 경우 가능한 응답을 예측
구체적인 방법으로 대답할 수 있는 질문이 바람직함
잘 설계된 설문지가 응답자의 호기심을 자극
고객과의 분쟁 최소화
 사용자와 개발자가 회의를 하면 회의록을 작성하여
확인한 후, 서명하라.
 시제품을 빨리 만들어 사용자에게 보여 주어라.
 고객과의 대화 도구를 확립하라. 사용자에게 요구사
항 분석이나 설계기법에서 사용하는 모델링 기법을
설명하여 주고 이를 공통의 대화 언어로 사용
 주 고객이 누구인지 찾아라.
 시스템을 블랙박스로 보라. 사용자가 무엇을 원하는
지 파악한 후, 원하는 기능을 구현하는데 필요한 자
료를 확보하기 위한 분석을 하여야 한다.
 고객과 좋은 인간관계를 유지하라.
Requirements Analysis(1)
요구 분석방법




구조적 분석 방법: Structured Analysis, SREM
객체지향 분석 방법: RUP, OMT, Fusion
정보공학 방법: Information Engineering
정형화 방법: VDM, Z, Petri Net
구조적 분석 방법
 시스템을 기능적 관점에서 분석
 추상적인 개념부터 차례로 세분화
Requirements Analysis(2)
객체지향 분석 방법
 객체 = 자료와 operation을 함께 추상화
 시스템 = 객체들의 모임
정보공학 방법
 비즈니스 프로세스로부터 요구분석 및 DB 설계
 ER Diagram을 사용하여 자료를 찾은 후, 기능분석
정형화 방법
 자연어의 문제점을 극복하기 위한 기법
 수학적 또는 논리적 표현 기법 적용
Requirements specification(1)
Guidelines for writing requirements




표준 양식을 개발하여 모든 종류의 요구 기술시 사용
요구 기술 언어는 일관성 있게 사용
중요한 부분은 강조하여 표현
컴퓨터 분야의 전문 용어는 가능한 한 억제
Problems with natural language





Lack of Clarity & Ambiguity
기능적 요구와 비기능적 요구가 혼합
여러 개의 요구사항을 한꺼번에 표현
같은 내용을 여러 가지로 다르게 표현
구조적인 표준이 어려움
Requirements specification(2)
자연어 이외의 요구기술 언어
Notation
Structured natural
language
Design description
languages
Graphical
notations
Mathematical
specifications
Description
This approach depends on defining standard forms or templates to
express the requirements specification.
This approach uses a language like a programming language but with
more abstract features to specify the requirements by defining an
operational model of the system.
A graphical language, supplemented by text annotations is used to
define the functional requirements for the system. An early example of
such a graphical language was SADT. More recently, use-case
descriptions have been used.
These are notations based on mathematical concepts such as finite-state
machines or sets. These unambiguous specifications reduce the
arguments between customer and contractor about system functionality.
However, most customers don’t understand formal specifications and
are reluctant to accept it as a system contract.
Requirements specification(3)
Interface specification
 인터페이스 명세
 다른 시스템과의 인터페이스를 기술
 요구 명세의 일부분으로 반드시 기술하여야 함
 인터페이스 기술시 포함할 사항
 Procedural interfaces
 Data structures that are exchanged
 Data representations
 정형적 표기법을 사용하는 것이 효과적
 예: PDL interface description
Requirements specification(4)
 PDL interface description
interface PrintServer {
// defines an abstract printer server
// requires:
interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
Requirements validation(1)
요구 확인: 파악한 요구가 고객이 진실로 원하
는 시스템을 반영하고 있는지를 확인하기 위한
제반 활동
요구 확인의 중요성
 요구 단계의 오류는 엄청난 비용을 초래
 구현 단계의 오류에 비하여 100배의 비용이 소요
Requirements validation(2)
요구 확인 사항
 Validity: 시스템이 고객이 원하는 기능을 정확하게
반영하고 있는가?
 Consistency: 요구사항이 서로 충돌하지는 않는가?
 Completeness: 고객이 필요로 하는 기능을 모두
포함하고 있는가?
 Realism: 파악된 요구가 현재의 기술과 주어진 예산
범위 안에서 구현 가능한가?
 Verifiability: 요구가 검증 가능한가?
Requirements validation(3)
요구 확인 기법
 Requirements reviews
 요구 정의시 고객과 계약담당자가 참석하는 검토회의 개최
 검토는 정형적/비정형적으로 수행할 수 있음
 원활한 의사소통이 필수 요소
 Prototyping
 Using an executable model of the system to check
requirements
 Test-case generation
 Developing tests to check testability of requirements
 Automated consistency analysis
Requirements validation(4)
Automated consistency analysis
Requirements
in a formal language
Requirements
problem report
Requirements
processor
Requirements
analyser
Requirements
database
Requirements document(1)
요구분석명세서란?
 요구분석명세서는 개발대상 시스템에 관하여 고객
과 개발자가 합의한 공식적인 중요 문서
 요구의 정의(definition) 및 명세(specification)를
포함
 시스템이 무엇(WHAT)을 해야 하는가를 기술하며,
어떻게(How) 할 것인가는 기술하지 아니 함
 시스템의 외부적 행동 및 구현상의 제약조건을 기술
 변경되기 쉬운 특성
 유지보수에 참조 자료로서의 역할
요구분석명세
서이용자
System customers
Specify the requirements and
read them to check that they
meet their needs. They
specify changes to the
requirements
Managers
Use the requirements
document to plan a bid for
the system and to plan the
system development process
System engineers
Use the requirements to
understand what system is to
be developed
System test
engineers
Use the requirements to
develop validation tests for
the system
System
maintenance
engineers
Use the requirements to help
understand the system and
the relationships between its
parts
Requirements document(2)
요구분석명세서 작성시 주의 사항




사용자와 개발자 모두가 이해하기 쉽게 작성
사용자와 개발자가 동의한 내용만 포함
시스템이 수행하는 기능을 정확하게 기술
시스템의 운용에 영향을 미치는 모든 제약조건을
기술
 시스템 인수 기준을 제시
 시스템의 품질 기준 및 측정 방법을 명시
Requirements document(3)
요구분석명세서의 구조









Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
Requirements document(4)
요구분석명세서의 평가 기준








정확성 (correct)
완전성 (complete)
일관성 (consistent)
명확성 (unambiguous)
기능적 (functional)
검증 가능성 (verifiable)
추적 가능성 (traceable)
변경 용이성 (changeable)
요구 단계의 CASE tools
Requirements storage
 Requirements should be managed in a secure,
managed data store
Change management
 The process of change management is a
workflow process whose stages can be defined
and information flow between these stages
partially automated
Traceability management
 Automated retrieval of the links between
requirements