* what are requirements?
요구사항은 시스템이 제공하는 서비스와 운영상의 제약에 대한 설명이다. 요구사항 엔지니어링은 이러한 서비스와 제약조건을 파악, 분석, 문서화 및 확인하는 프로세스임.
Classifications of requirements
- Functional and Non-functional requirements
Functional requirement : 시스템에서 수행해야 할 작업, 소프트웨어의 유형, 예상 사용자 및 소프트웨어가 사용되는 시스템의 유형에 따라 다름. 기능적 사용자 요구 사항은 시스템이 수행해야 하는 작업에 대한 상위 수준의 내용일 수 있지만 기능적 시스템 요구 사항은 시스템 서비스를 자세하게 설명해야 한다.
Non-functional requirement : 시스템이 제공하는 특정 기능과 직접 관련이 없다. 신뢰성, 응답시간 및 점유율과 같은 급격한 시스템 특성과 관련이 될 수는 있다. 대안적으로 I/O장치의 기능 및 시스템 인터페이스에 사용되는 데이터 표현과 같은 시스템에 대한 제약사항을 정의할 수 있다. - functional requirement보다 중요할 수 있다. 이들이 충족되지 않으면 시스템이 쓸모 없음.
근데 이 두 개는 실제로 단순한 정의가 제시하는 것 만큼 명확하지는 않다.
보안과 관련도니 사용자 요구사항은 non-functional requirement로 보일 수 있다. 그러나 보다 상세하게 개발되면, 이 요구사항은 시스템에 사용자 인증 기능을 포함싴리 필요성과 같이 명확하게 기능하는 다른 요구사항을 생성할 수 있다.
비기능 요구 사항의 공통적인 문제점은 검증하기 어려울 수 있다는 것이다. 사용자 또는 고객은 종종 사용 용이성, 실패로부터 복구할 수 있는 시스템의 기능 또는 빠른 사용자 응답과 같은 일반적인 목표로 이러한 요구 사항을 기술한다.
가능하면 객관적으로 테스트할 수 있도록 비기능적 요구 사항을 정량적으로 작성해야 한다.
- user and system requirements
* user requirements
계약이 수주되면 계약자는 클라이언트가 이해할 수 있고 소프트웨어가 수행할 작업을 검증할 수 있도록 클라이언트에 대한 시스템 정의를 보다 자세히 작성해야함.
사용자 요구사항은 상세한 기술 지식이 없는 시스템 사용자가 이해할 수 있는 방식으로 기능 및 비기능 요구사항을 설명해야한다. 그들은 시스템의 외부 동작만을 지정해야하며 가능한 한 시스템 설계 특성을 피해야한다. 소프트웨어 전문용어, 표기법을 사용거나 시스템 구현을 설명하여 요구사항을 설명해서는 안됨.
사용자 요구사항은 모든 사용자가 이해할 수 있는 모든 언어, 표 및 다이어그램을 사용해서 정의해야함.
* system requirements
시스템 요구사항은 사용자 요구사항의 확장판임. 시스템 구현을 위한 계약의 일부로 사용될 수 있으므로 전체 시스템의 완전하고 일관된 사양이어야 함. 이상적으로 시스템 요구사항은 단순히 시스템의 외부 동작과 운영 제약을 설명해야 한다. 그들은 시스템ㅇ르 설계하거나 구현하는 방법에 관심을 가져서는 안된다.
그러나 복잡한 소프트웨어 시스템을 완전하게 지정하는데 필요한 상세 수준에서는 실제로 모든 설게 정보를 제외시키는 것은 불가능함.
* requirements specification languages
1. natural language-based specification
자연 언어는 종종 시스템 요구 사항 명세를 작성하는 데 사용됩니다. 그러나 시스템 요구 사항은 사용자 요구 사항보다 세부적이므로 자연 언어 사양은 혼란스럽고 이해하기 어려울 수 있습니다. 보다 특수화 된 표기법으로 시스템 요구 사항을 작성할 수 있습니다.
- structured natural language, design description languages, graphical notation, mathematica lspecifications.
2. Form-based specification
표준 양식이 요구사항명세에 사용될 때 다음 정보가 포함되어야 함.
- definition of the function or entity, description of inputs and where they come from, description of outputs and where they go to, indication of other entities required, pre and post conditions, the side effects of the function.
* Tabular specification
*Graphical specification (ATM기)
* Formal specification languages - UML
UML?ー Unified Modeling Languages.
VDM? - Vienna Development Method - 프로그래밍 언어와 같음. - numeric, character, token and quote types.
* Guidelines for requirements specification.
-필요성 ; 자연어의 문제 : 명확성이 부족, 요구사항 혼란, 다른 요구사항들이 함께 표현되어야함.
requirements specifications
모호성 - 요구 사양의 부정확성은 많은 소프트웨어 엔지니어링 문제의 원인입니다. 모호한 요구 사항은 개발자와 사용자가 다른 방식으로 해석 할 수 있습니다. '적절한 시청자'라는 용어를 고려하십시오. 고객 의도 - 각기 다른 문서 유형에 대한 특수 목적 뷰어. 개발자의 해석 - 문서의 내용을 보여주는 텍스트 뷰어를 제공하십시오. 개발자는 요구 사항이 충족되었다고 주장 할 수 있습니다.
완전성 및 일관성 - 원칙적으로 요구 사항은 완전하고 일관성 있어야합니다. 그들은 필요한 모든 기능에 대한 설명을 포함해야합니다. 상호 배타적이며, 전체적으로 포괄적이다. 시스템 시설에 대한 설명에는 갈등이나 모순이 없어야합니다.
테스트 가능성 - 대부분의 요구사항은 테스트할 수 있어야한다. (안되면 다른 검증 방식을 함.)
* Requirements Engineering
요구 사항 엔지니어링 프로세스의 목표는 시스템 요구 사항 문서를 작성하고 유지 관리하는 것입니다. 3가지 sub-processes. (요구사항 유도(요구사항 찾기), 검증, 관리)
*Requirements Elicitation
요구 사항 추출은 응용 프로그램 도메인, 시스템에서 제공해야하는 서비스, 시스템의 필수 성능, 하드웨어 제약 조건 등을 알아야합니다.
- stake holder : 시스템에 영향을 받는 사람들. 이해 관계자는 최종 사용자, 관리자, 유지 보수에 관련된 엔지니어, 도메인 전문가, 노동 조합 등을 포함합니다.
* liciting stakeholder requirement의 어려움의 이유
이해 관계자는 그들이 정말로 원하는 것을 모릅니다. 이해 관계자는 자신의 용어로 요구 사항을 표현하고 자신의 작업에 대한 암묵적인 지식을 표현합니다. 이해 관계자마다 서로 상충되는 요구 사항이있을 수 있습니다. 정치적 요소가 시스템 요구 사항에 영향을 미칠 수 있습니다. 분석이 이루어지는 경제 및 비즈니스 환경은 역동적입니다
프로젝트의 4가지를 결정하는 것이 중요하다
1. 목적 : 컴퓨터 솔루션이 필요한 문제에 대한 기본적인 이해가 있어야 함.
2. 프로젝트가 진행될 상황과 환경에 대한 이해.
3. 고객이 시스템에 기대하는 것에 대한 이해.
4. 고객의 동기와 기대에 대한 이해.
* 요구사항 추출 기술
1. interviewing - stake holder한테 질문 던지기, 답으로부터 요구사항 도출.
두 가지 방법 : closed interview(정해진 질문), open interviews.
일반적으로는 두 가지를 혼합해서 함.
2. scenarios - 실생활의 예. 세부사항에 추가하기 좋음.
3. use-cases
4. ethnography - 사회적 조직적 요구사항을 이해하는데 사용할 수 있는 관측 기술. 일상 관찰. 공식 프로세스가 아닌 실제 시스템 요구사항을 발견할 수 있음.
5. other - questionnaires(설문지 - 다량 데이터 도출 가능(단점많음)), focus groups, apprenticing, brainstorming(다양한 아이디어 가능), document inspection (apprenticing - 직접 해보는 것임 사용자가 되어서. )
* 요구사항 검증.
= 사용자가 원하는 것이 시스템에 정의되어 있는지 검증하는 것. 요구사항에 문제가 있는지를 분석하는 것이랑 동일. (에러있으면 다시 해야함)
! 꼭 해야 할 요구사항 체크 !
1. 정당성 검사. - 꼭 필요한가?
2. 일관성 검사. - 충돌 없는가?
3. 완전성 검사. - 고객이 요구하는 모든 기능 포함했는가?
4. 실현성 검사. - 실현 가능한가 ( 돈, 기술 으로)
5. 검증성 검사. - 요구사항 테스트 가능한가?
* 요구사항 관리.
큰 시스템의 요구사항은 계속 바뀐다. 요구 사항 관리는 시스템 요구 사항의 변경 사항을 이해하고 제어하는 프로세스입니다.
- traceability matrices. : 추적 가능성 정보는 흔히 추적 가능성 매트릭스를 사용하여 표현됩니다. D : 열의 요구사항에 따라 행의 요구사항이 달라짐. R : 요구사항 사이에 약한 관계.
3--
System models
시스템 모델은 분석 모델이라고도 합니다. 시스템 또는 분석 모델은 시스템의 첫 번째 기술 표현입니다. 시스템 모델은 시스템 설계 프로세스를 분석하는 요구 사항 간의 중요한 다리 역할을 합니다.
Analysis model :
분석 프로세스는 사용자 또는 고객이 볼 수있는 문제의 측면에 초점을 둡니다. 분석 모델의 추상화 수준은 상대적으로 높습니다.
Design model :
설계 프로세스는 모델을 구현할 수 있도록 세부 사항을 제공하여 분석 모델을 구체화하고 사용자와 고객이 볼 필요가없는 새로운 모델 요소 집합을 만듭니다 (개발자에게만 표시).
디자인 모델의 추상화 수준은 상대적으로 낮습니다.
Context Models
요구 사항 추출 및 분석 프로세스의 초기 단계에서 시스템의 경계를 결정해야합니다.
Structural Models (Data Models)
- 데이터 모델을 사용한 시스템 모델링은 시스템이 처리하는 데이터의 논리적 형식을 정의하는 것임. 일반적으로 ERA(entity, relation, attribute) modelling
데이터 사전은 시스템 모델에서 사용되는 이름의 사전 순 목록이다.
Behavioural Models
행동 모델은 시스템의 전반적인 동작을 설명하는 데 사용됩니다.
- Data-flow model (order processing)
data-flow 모델의 장점 : 간단하고 직관적임 , 전체 작업 순서를 보여준다. (end to end)
- State machine model (micro wave oven model)
- State machine model의 문제점
가능한 상태의 수가 빠르게 증가한다.
Object Models
객체 모델은 시스템 데이터와 프로세스 모두를 표현하는 데 사용될 수 있습니다.
(이러한 관점에서, 이들은 데이터 흐름 모델과 의미론적 데이터 모델의 일부 사용을 결합합니다). 객체 모델은 시스템이 조작하는 실세계 엔티티를 자연스럽게 반영하는 방식입니다.
-> 요구 사항 분석 중에 객체 모델을 개발하면 대개 객체 지향 설계 및 프로그래밍으로의 전환이 간단해집니다.
요구사항은 시스템이 제공하는 서비스와 운영상의 제약에 대한 설명이다. 요구사항 엔지니어링은 이러한 서비스와 제약조건을 파악, 분석, 문서화 및 확인하는 프로세스임.
댓글