Software Requirements

Requirements in UP

• UP의 req는 반복적으로 분석된다.
• skillful하게 req를 도출
• 1) use case
• 2) requirements workshops
• 3) demo

 

Category of Requirements

• FURPS+ model ( F : Functional req   ,   URPS : Quality req  ,  + : Constraints
• Functional
• Usability
• Reliability
• Performance
• Supportability
• + Constraints

 

Requirements Organization in UP

requirements artifacts (  all optional  )

• Use-case model => 대부분 주요한 FR
• Supplementary Specification  => 대부분 주요한 NFR (use case로 표현하지 못하는 것들)
• Glossary  => 용어집
• Vision  => high level req의 summarizes
• Business Rules  ==> domain이나 business에서의 policy

 

Functional and Non-Functional Reqs.

• Functional Req : 어떤 기능 / 서비스를 제공할건지 
• Non-functional Req : 시스템 전반에 걸친 품질/요건, 초기에 잘 세우는 것이 중요(FR보다 중요하다)
• Quality attributes => 협의점 존재, Constraints => 반드시 충족

 

Non-Functional Requirements

• 전반적인 시스템 구조에 영향을 미침
• NFR을 만족시키기 위한 FR을 derive 하기도 함. ( ex. security req.)
• 기존 req를 제한하는 req를 만들어내기도 함.

 

NFR Classifications

• Product requirement => sw자체와 관련된 요구사항 (속도, 신뢰성 ..)
• Organizational requirement => 개발하는 조직에 관한 요구사항(process standard, 구현 req)
• External requirement => 외부 요구사항 (ex. 법과 관련된 정책..)

 

Verifiable Requirements

• req들을 객관적으로 검증을 할 수 있어야 함
• verify가 쉽지 않은 NFR은 쓸모가 없다. ( 검증 기준이 중요 )

 

Declarative Statements vs Use Cases

• Declarative => Req 간의 연결관계가 떨어짐( user가 잘 알지 못하면 특히)
• Use case 
• => interactive system에 잘 맞음
• => 모든 SRS를 나열 x , 오직 FR 파트만 그림
• 중요한 specification을 분석, 도출하는데 사용됨

 

Use Cases Basics

• system과 actors 사이의 interaction을 묘사
• actor => system 외부에 존재, interact를 통해 goal을 성취하고자 함.
• primary actor => main actor
• scenario => 구체적인 action을 묘사 
• main scenario : 일반적으로 goal이 성공했을 때
• alternate scenario : 뭔가 잘못돼서 goal을 성취할 수 없을 때
• Use case ==> a collection of many such scenarios

Software Requirement Specifiaction (SRS)

• a description of a software system to be developed

 

Desirable properties of requirements

 

 

Requirement review를 통해 잘못된 req를 잡아낼 수 있고... req 분석, 도출에 use case를 사용한다..(특히 FR)

 

Requirement Elicitation and Analysis

• How can we identify the purpose of a system?
• What is inside, what is outside the system? : 개발 바운더리 파악

• Requirement Elicitation  : customer의 관점에서 이해할 수 있도록 해야함
• Analysis : 개발자의 관점에서 이해할 수 있도록.