Chapter4. Requirements Engineering

개발자, 고객 모두 requirement 정의하기 어려움. 정의한다해도 말로 requirement 에 대해 개발자와 고객이 서로 다른 걸 생각하고 있을 수도 있음. 

 

 

Requirements Engineering

requirements

- system이 반드시 제공해야하는 services에 대한 description = functional req

- system operations에 대한 제약(constraints) = non-functional req

- 시스템에 대한 고객의 need를 반영하는 것

 

Requirements engineering(RE)

- services, constraints에 대해 추출, 문서화, 검증하는 프로세스

 

requirements engineering processes

1. requirements elicitation 추출

2. requirements specification 문서로 작성

3. requirements validation 

4. requirements change management (waterfall도 마찬가지임..!)

 

User and System requirements

User requirements

- high-level abstract statements

- natural language. 누구든지 읽기 쉽도록. 

- 핵심만 쓴 것. 큰 그림 (for 높으신 양반들)

 

System requirements

- detailed descriptions

- 뭘 구현해야하는지 자세히 정의.

- buyer와 developers 간의 계약할 때. (for 실무 일하는 사람들)

 

 

구분하는 절대적인 기준같은거 X. 상대적인 개념.

 

 

 

Functional and non-fucntional requirements

Fuctional requirements

- 시스템이 제공해야 하는 서비스. - 특정 입력에 대해 어떻게 반응해야하는지 - 특정 상황에서 어떻게 작동해야하는지 - 어쩔 때는, 시스템이 하지 말아야 할 것도 정의.

 

Functional user requirements

: 기능을 누구나 이해할 수 있도록 쉽게 쓴 것

 

Functional system requirements

: 기능을 디테일하게 묘사. (functions, inputs, outputs, exceptions)

 

 

 

Non-functional requirements

시스템 전체적으로 제약들constraints을 묘사한 것 (reliability, reponse time, memory use, performance, security, h/w spec, interfaces)

non-functional req를 충족하지 못한다는 건 = 전체시스템을 사용할 수 없다는 것.

 

Product requirements

제품 자체에 관한 제약. s/w 본연의. 

performance, space, security, usability req(사용하기 쉬워야함) 

 

Organizational requirements

s/w 개발, 사용 조직에서 거는 제약. 

environment(환경적인 제약. ex-리눅스, 윈도우와 호환되도록 해야함), operational(ex-이 학교 학번을 가진 사람만 가입되도록), development req(개발언어, 개발툴 등) 

 

External requirements

외부 요인에 의한 것. 

regulatory, legislative req(법적인 제약. ex-19세 미만 게임은 피가 초록색으로, 개인정보 처리방침)

 

 

"Testable" non-functional requirements

모든 requirements는 testable하다. non-functional requirements는객관적으로 test가 가능하도록 수치적으로 quantitatively 나타내야한다.

 

EX) 사용하기 쉬워야함 -> 4시간 훈련받으면 사용할 수 있어야함

     시스템 구조가 잘 잡혀서, 오류가 최소화 ->오류가 시간당 평균 2개를 넘지 않아야함.

 

특성	척도 (구체적인 수치)
performance	Processed transactions/second  User/event response time  Screen refresh time
size	Gigabytes
usability (=ease of use)	Training time, Number of help frames
reliability	Mean time to failure(MTTF) : 한번 죽고 다음 죽을 때까지 걸리는 평균 시간. 길수록 좋은 것 Probability of unavailability : 죽어있는 시간 (ex. downtime이 5% 미만이어야함) Rate of failure occurrence.
robustness (강건성:빠르게 원상태로 회복)	Time to restart after failure  Percentage of events causing failure  Probability of data corruption on failure
portability (이식성)	Percentage of target dependent statements (ex. 코드 내에서 플랫폼 의존적인 코드가 10% 미만) Number of target systems (ex. 최소 4개 이상의 플랫폼에 설치할 수 있어야함)

 

 

 

Imprecision in requirements

고객-개발자 간의 논쟁 야기

이 경우, 새로운 요구 사항을 설정하고 시스템을 변경해야 한다. 물론 이로 인해 시스템 제공이 지연되고 비용이 증가할 수 있다.

 

Complete and Consistent requirements

complete : 우리가 하기로 한게 문서 안에 '다 있는지'

consistent : 서로 상충하는 req 묘사가 없는지. 앞뒤가 안맞는, 모순되는 것

크고 복잡한 시스템에서 실수나 누락이 발생하기 쉽다. (이해 관계자가 서로 다른 요구사항을 가질 수 있기 때문에 )

 

 

 

Requirements Engineering processes

1. Reqruirements elicitation

2. Reqruirements specification

3. Reqruirements validation

4. Reqruirements change management

 

 

1. Reqruirements elicitation

stakeholder와 회의하여 reqruirements 알아내기

 

Difficulties in Requirements Elicitation

- 고객도 원하는 바를 자세하게는 모를 때가 많음

- 고객이 그들만의 용어로 얘기. 개발자도 그 분야 도메인에 대해서 좀 알아야함

- 여러 stakeholder들이 서로 상충되는 이야기할 때도 있음

- 정치적인 면이 끼어들 때도 있음

- 분석과정에서 req가 변경될 수도 있음

 

Requirements Elicitation Techniques

- Interviewing : 고객, 개발자들 모여서 인터뷰

- Observation or ethonography : 직접 가서 보기

- Stories ( scenarios) : 실제 사용하는 것처럼 작성 -> 고객이 이해하기 편함

 

 

2. Requirements Specification

문서화하는것

User requirements

- 대부분 natural language로 간단하게. 그림이나 표도 사용.

 

System requirements

- natural language로 쓰임. 

- 그러나 상세히 쓰기 위해서 다양한 기법이 사용된다. (forms, graphicla diagrams, mathematical notations)

 

Notations for System Requirements

1) Natural language sentences

그냥 말로.

보통 앞에 user req -> 뒤에 system req 순서로 적음

 

2) Structured specifications 구조화된 상세설명

Function, Description

Input, Outputs, Action

Precondition, Postcondition

exception handling

 

 

 

 

 

3) Graphical notation

UML : 소프트웨어를 묘사하는 표준그림

정해진 기호를 이용해서 그림

 

4) Mathematical specifications

수학적 기호로 엄격하게, 정확하게 나타냄. 

 

 

 

 

Software Requirements Document(Specification) (SRS)

앞부분에 user req, 뒷부분에 system req.

-agile에서는 필요없음 ( user story로 대신함)

 

 

User of a Requirements Documentation

역할에 따라 어떤 취지로 읽는가