Requirements engineering

[Requirement]

• The descriptions of the services that a system should provide and the constraints on its operation.
  

[Requirement Engineering (RE)]

• The process of finding out, analyzing, documenting and checking these services and constraints.
  (The first stage(The very first stage는 feasibility study) of the software engineering process)

User and system requirements

[Example of user and system requirements]

• MentCare: A medical system that maintains information about patients suffering from mental health problems and __their treatments.
  

Types of requirements

[Why are these 2 requirements necessary?]

• Different types of readers use the requirements in different ways.
  

[System stakeholders for MentCare]

• Any person or organization who is affeacted by the system in some way and who has a legitimate interest
  • Patients: whose information is recorded in the system.
  • Doctors: who are responsible for assessing and treating patients.
  • Nurses: who coordinate the consultations with doctors.
  • Receptionists: who manage patients' appointments.
  • IT staff: who are responsible for installing the system.

Functional and non-functional requirements

[SW system requirements]

• Functional requirements
  • Statements of services the system should provide. (e.g., input/output)
  • Statements of what the system should not do.
• Non-functional requirements
  • Constraints on the services offered by the system. (e.g., timing constraint)
  • Constraints that apply to the entire system! rather than individual system features.

Functional requirements

[Functional requirements]

• Describing what the system should do.

• Varying from general requirements to very specific requirements.

• Imprecision(부정확함) in the requirements

  • Leading to disputes between customers and SW developers.
  • Delaying system delivery and increases costs.

[(Ideal) functional requirements]

• Completeness in requirements
  • All services required by the user should be defined.
• Consistency in requirements
  • Requirements should not be contradictory.

-> In practice, it is impossible to achieve requirements consistency and completeness for large systems.

Non-functional requirements

[Non-functional requirements]

• Constrain characteristics of the system as a whole
  • Response time, memory use, reliability, ...
• Non-functional requirements > individual functional requirements.
  • Failing to meet the requirement mean that the whole system is unusable.
• Non-functional requirements arise through user needs.
  • ex) budget constraints, organizational policies, safety regulations, privacy legislation.

[Types of non-functional requirements]

• Product requirements

  • Specifying the runtime behavior of the software.
  • ex) execution speed, memory usage, acceptable failure rate, ...

• Organizational requirements

  • Deriving from policies in the customer's and developer's organizations.
  • ex) programming language, process standards to be used, ...

• External requirements

  • Deriving from factors external to the system.
  • ex) nuclear safety authority, legislative requirements, ...

[Examples of non-functional requirements]

• Mentcare system
  

[Types of non-functional requirements]

• 

[Problems in non-functional requirements]

• Stakeholders propose requirements as general goals.
• ex) case of use, rapid user response, ...
  

[Solutions in non-functional requirements]

• Writing non-functional requirements quantitatively(양적으로) for testing.
• Translating the customer's goals into measurable(측정 가능하도록) requirements.

Requirements engineering processes

[3 Key activites in requirements engineering]

• Elicitation and analysis
  • Interacting with stakeholders.
• Specification
  • Converting these requirements into a standard form.
• Validation
  • Checking that the requirements define the system that customer wants.

In practice, RE is an iterative process in which the activities are interleaved.

[A spiral view of the requirements engineering process]

Start! -> Feasibility Study -> Requirement Engineering (Elicitation -> Specification -> Validation) -> ...

Requirements elicitation

[Goal]

• Understanding the work that stakeholders do and how they use a new system to help support that work.

[Problems]

• Stakeholders don't know what they really want from a SW system.
• Stakeholders express requirements in their own terms.
• Different stakeholders express their requirements in different ways.
• Political factors may influence the systme requirements.
• The requirements dynamically chagne during the analysis process.

[The requirements elicitation and analysis process]

• 

• Requirements discovery and understanding

  • Interacting with stakeholders to discover their requirements.

• Requirements classification and organization

  • Grouping related requirements and organizaing them into cohorent clusters.

• Requirements prioritization and negotiation

  • Prioritizing requirements and resolving requirements conflicts.

• Requirements documentation

  • Documenting requirements. (e.g., early draft of SW requirement, whiteboard, wikis)

Requirements elicitation techniques

[2 fundamental approaches to requirements elicitation]

• Interviewing (= Talking to people about whay they do).
  • Closed interviews, where the stakeholder answers predefined questions.
  • Open interviews, in which there is no predefined agenda.
• Observation or Ethnography(만족지학)
  • Watching people doing their job to see what artifacts they use, how the use them, and so on

[Eliciting domain knowledge throught intervies is difficult]

• Usage of domain specific terminologies.
• Difficulty for explaining some familiar domain knowledge.
• Omitting to mention fundamental knowledge to stakeholders.

Stories and scenarios

[Stories and scenarios]

• A description of how the system can be used for a particular task.
  • Stories: narrative text for a high-level description of system use. (간단)
  • Scenarios: specific information collected such as inputs and outputs. (더 구체적)

[The purpose of Stories]

• Facilitating(촉진) discussion of how the system might be used.
• Acting as a starting point for eliciting the requirements for that system.

[Scenarios]

• A structured form of the user stories.

• The common characteristics of a scenario.

  • A description of what the system expect when the scenario starts.
    시나리오 시작 시 시스템이 기대하는 동작 설명

  • A description of the normal flow of events in the scenario.
    시나리오의 정상적인 이벤트 흐름 설명

  • A description of what can go wrong.
    무엇이 잘못될 수 있는지에 대한 설명

  • Information about other activities that are going on at the same time.
    동시에 진행 중인 다른 활동에 대한 정보

  • A description of the system state when the scenario ends.
    시나리오 종료 시 시스템 상태에 대한 설명

  • 

  • 

Requirements specification

[Requirements specification]

• The process of writing down the user and system requirements.

• User requirements

  • They are usually written in natural language
  • They have to be understandable by end-users.

• System requirements

  • Expanded versions of the user requirements.
  • The part of the contract(계약) for the implementation of the system.

[Notations for writing system requirements]

• Natural language: 요구사항을 번호가 매겨진 자연어 문장으로 작성/ 각 문장은 하나의 요구사항을 나타냄

• Structured natural language: 자연어로 작성하지만, 요구사항을 표준 양식 또는 템플릿에 따라 작성/ 각 필드 또는 섹션은 요구사항의 특정 측면에 대한 정보를 제공함

• Graphical notations: 시스템의 기능 요구사항을 그래픽 모델과 함께 표현함/ 일반적으로 UML(Unified Modeling Language)의 사용 사례 및 순서 다이어그램과 같은 그래픽 요소와 텍스트 주석을 사용하여 요구사항을 정의

• Mathematical specifications: 수학적 개념을 기반으로 요구사항을 정의함/ 유한 상태 기계 또는 집합과 같은 수학적 원리를 사용하여 요구사항을 형식적으로 정의하며, 명확성을 높일 수 있지만 일반적인 고객들이 형식적 명세를 이해하기 어려울 수 있음

Natural language specification

[Natural language]

• The most widely used way of specifying SW requirements.
  • (+) expressive, intuitive, and universal
  • (-) vague, ambiguous

[Guildlines for writing natural language requirements]

• Use language consistently to distinguish between mandatory and desirable requirements. (e.g., shall vs should)
• Use text highlighting to identify key parts of the requirement.
• Do not assume that readers understand technical SE language.
• Associate(연관짓다) a rationale(이론적 해석) with each user requirement. (e.g., why? who?)

Structured specifications

[Structured specifications]

• A way of writing system requirements where requirements are written in a standard way rather than as free-form text.
  • A description of the function or entity being specified.
  • A description of its inputs and outputs.
  • The information needed for the computation.
  • A description of the action to be taken.
  • A precondition, post-condition.
  • A description of the side effects (if any) of the operation.

[The tabular specification]

• Useful when there are a number of possible alternative situation.
• Useful when complex computations are to be specified.

Use cases

[Use cases]

• A way of describing interactions between users and a system.
  사용자 시나리오 및 요구사항을 기술하는 방법 중 하나. Use cases는 시스템이 어떻게 사용될 것인지, 사용자가 시스템과 상호 작용하는 방식을 자세하게 설명함.
  • Actor (human or other systems), Each class of interaction
    

The software requirements document (SRS - Software Requirements Specification)

[The software requirements document]

• An official statement of what the system developers should implement. (The software requirements specification or SRS)

• Including both the user and system requirements.

• Having a diverse set of users.

  • customers, managers, engineers, test engineers, ...

[Users of a requirements document]

• Showing possible users of the document and how they use it.
• 
• 

[The structure of a requirements document (SRS)]

• Preface(서문)

  • 문서의 목적과 예상 독자층, 버전 히스토리, 새 버전을 작성하는 이유, 각 버전의 요약 변경 사항 등을 설명

• Introduction(소개)

  • 시스템의 필요성, 시스템 기능, 문서의 목적을 소개

• Glossary(용어집)

  • 문서에서 사용되는 기술 용어와 정의를 제공/ 독자의 전문지식을 가정하지 않고 용어를 설명

• User Requirements Definition(사용자 요구사항 정의)

  • 사용자를 위한 서비스 및 기능을 설명/ 기능 이외의 비기능적 시스템 요구사항을 기술

• System Architecture(시스템 아키텍처)

  • 시스템의 높은 수준 아키텍처 개요을 제공/ 다양한 구성 요소와 시스템 모듈의 분배를 설명

• System Requirements Specification(시스템 요구사항 명세)

  • 기능 및 비기능적 요구사항을 더 자세하게 기술하고 요구사항 간의 관계를 정의

• System Models(시스템 모델)

  • 시스템을 그래픽 모델을 사용하여 설명/ 시스템 구성 및 상호 작용을 시각적으로 나타냄

• System Evolution(시스템 진화)

  • 시스템의 기본 가정과 미래 변화에 대한 정보를 제공/ 시스템 디자이너가 미래 변경을 고려하도록 도와줌

• Appendices(부록)

• Index(색인)

Requirements validation

[Requirements validation]

• The process of checking whether requirements define the system that the customer really wants.
• Critical process in a requirements document.
  • The errors can lead to extensive rework costs when these problems are discovered after the system is in service.

[Requirements validation techniques]

• Requirements reviews
• Prototyping
• Test-case generation

[Different types of checks in requirements validation]

• Validity: The requirements reflect the real needs of system users.
• Consistency: Requirements in the document should not conflict.
• Completeness: Requirements define all functions and the constraints.
• Realism checks: Requirements can be implemented within the budget.
• Verifiability (testable): Requirements should always be written so that they are verifiable. (e.g., a set of test-cases)

Requirements change

[Requirements Change]

• The requirements for large software systems are always changing.
  • Interfacing the system with other systems.
  • New legislation and regulations may be introduced.
  • People who pay for a system and the users of that system are not same.
• 

[Issues for requirements management planning]

• Requirements identification (요구사항 식별)

  • Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.
    각 요구사항은 고유하게 식별되어야 함

• A change management process

  • This is the set of activities that assess the impact and cost of changes.
    요구사항 관리 작업은 변경의 영향과 비용을 평가하고, 변경이 승인되거나 거부되는 방법을 정의해야함

• Tool support

  • Requirements management involves the processing of large amounts of information about the requirements. (e.b., shared spreadsheets)
    요구사항 관리 작업이 요구사항에 대한 다양한 정보를 처리하고 관리해야 함

Summary