[Software Engineering] 6주차 (1)

Requirements Engineering

 

The process of establishing the service that a customer requires from a system and the constraints under which it operates and is developed.

특성 공학이란 시스템이 동작하고 개발되는 환경 아래에서의 제약들과 소비자의 요구들을 결정하고 만들어가는 과정을 말합니다. 이때 constraints는 coding style이나 information security등 software quality를 제외하는 NFR (* Non-functional Requirements)를 말합니다.

 

Requirements have range from a high-level abstract statements of a service or of system constraints to a detailed mathematical functional specification.

요구 사항들은 높은 수준의 서비스의 추상화 단계부터 시작해서 디테일한 기능적, 수학적 명세까지 존재합니다.

• Statements of services → Functional Requirements (FR)
• System constraint → Non-functional Requirements (NFR)
  • Constraints (e.g., 사장님 지시사항)
  • Software Quality Attributes (e.g., realiablity, security,etc,)
• User Requirements
• System Requirements

 

Types of Requirements

 

• User Requirements
  • Statements in natural language and diagrams of the services the system provides and its operational constraints → 기능적 제약들과 시스템이 제공하는 서비스에 대한 자연어나 다이어그램, 자연어로 되어있어, 표현력이 뛰어나지만 모호성이 높습니다.
  • Elicited/Discovered from stakeholders
  • Defined for customers
• System Requirements
  • A structed document setting out detailed descriptions of the system's functions, services and operational constraints → 구조적 제약이나 시스템의 동작, 서비스등에 대한 디테일한 표현이 들어있는 구조적인 문서, User Requirement를 기반으로 문서로 만드는 과정이 어려울 수 있다. 이 과정에서 Requirement analysis methods를 사용한다.
  • Defines what should be inplemented
  • Specified for developers

 

User and System Requirement Examples

 

System Stakeholders

 

Any person or organization who is affected by the system in some way and so who has a legitimate interest

만들어지는 시스템에 의해 어떤 이유로든지 영향을 받는 조직이나 사람을 시스템 이해관계자라고 합니다. 일반적으로 Stakeholder들을 찾는 것부터 requirement analysis가 시작됩니다.

 

아래는 이해관계자의 종류입니다:

typical stakeholders

 

Agile Methods and Requirements

 

Many agile methods argue that "producing detailed system requirements is a waste of time as requirements change so quickly". So, The requirements document is therefore always out of date.

 

Agile methods usually use incremental requirements engineering and may express requirements as user stories

• This is practical for business systems
• This is often problematic for systems that require pre-delivery analysis (e.g., critical systems) or systems developed by several teams → security나 dependability가 중요한 시스템 (e.g., critical system) 이나 여러 팀들에 의해 만들어지는 시스템의 경우에는 문제가 될 수 있습니다.

 

+ 다시 한 번 말하지만 Agile이라고 requirement analysis를 하지 않는것은 아닙니다. 단지 일정한 규정에 따라 documentation을 하지 않을 뿐입니다.

 

Functional and Non-functional Requirements

 

• Functional requirements
  • Statements of services the system should provide
    • How the system should react to particular inputs
    • How the system should behave in particular situations
  • May state what the system should not do
  • SRS와 비교해서 FR을 만족하는지 확인할 수 있습니다. Agile에 경우에는 team에 같이 있는 customer가 그냥 확인합니다 (애초에 test case를 같이 만듭니다).
• Non-functional requirements
  • Constraints on the services or functional offered by the system such as timing constraintsm, constraints on the development process, standards, coding style, etc.
  • Often apply to the system as a whole rather than individual features or services
  • 어떤 test를 만족한다고 해서 NFR을 만족하는지를 확인할 수 없다. Quality의 경우는 정말 test가 불가능하고, Constraints의 경우는 그냥 확인이 됩니다 (coding style을 지키고 있는지, 개발 프로세스를 지키고 있는지는 그냥 확인하면 되니까)
  • 이런 요구사항들은 emergent properties로 각각의 컴포넌트들이 NFR을 만족한다고 해서 합쳤을 때, NFR을 만족한다고 보장할 수 없습니다. 따라서 the system as a whole개념이 등장합니다.
• Domain requirements
  • Constraints on the system from the domain of operation
  • 이는 NFR혹은 FR모두 속할 수 있는 requirements로 일종의 그 특정 도메인만의 노하우입니다.

 

Functional Requiremetns

 

Describing functionality or system services depends on the type of software, expected users and the type of system where the software is uesd

기능 요구 사항은 그 소프트웨어를 사용하는 시스템이나 사용자, 소프트웨어의 종류에 따른 시스템 서비스의 기능들을 적어놓은 것입니다.

• Functional User Requirements; it may be high-level statements of what the system should do.
• Functional System Requirements; it should describe the system services (user requiremets) in detail

 

Problems arise when functional requirements are not precisely stated.

문제는 그 기능 요구 사항들이 정확하게 기술되지 않았을 때 발생합니다. 일반적으로 Functional User Requirements는 자연어로 기술되기 때문에 표현력은 높지만, 모호성도 높습니다. 따라서 Functional User Requirements를 Functional System Requirements로 옮기는 과정은 굉장히 신중하게 해야합니다.

 

이를 위해서 요구 사항들은 complete and consistent (C&C)를 지켜야합니다.

• Complete; they should include descriptions of all facilities required → document의 완성도
• Consistent; there should be no conflict or contradictions in the descriptions of the system facilities → document들의 충돌 방지

 

Non-Functional Requirements

 

Define system properties and constraints

• Properties: reliablity, reponse time and storage requirements, I/O device capability, etc. (Quality Attributes Requirements)
• Constraints: mandating a particular IDE, programming languages or development methods, standards compliance, ect.

 

Non-functional requirements may be more critical than functional requirements

비기능적 요구사항은 기능적 요구사항보다 더 중요할 수 있습니다.

 

Non-functional requirements may affect the overall architecture of a system. it generates a number of related functional requirements that define system services that are required.

비기능적 요구사항은 시스템의 전체적인 구조에 영향을 미칩니다. 비기능적 요구사항들은 많은 연관된 기능적 요구사항들을 만들어냅니다.