Secure Requirements Engineering

Question 1

Was gilt allgemein im Security Bereich?

Answer 1

Weakest Link will break

Question 2

100% Sicherheit gibt es?

Answer 2

100% Sicherheit gibt es NICHT

Question 3

Je früher Probleme adressiert werden, umso…

Answer 3

besser und kostengünstiger.

Question 4

Was umfasst Security?

Answer 4

• Projects and Products
• Documents
• People
• Secure Code

Question 5

SWA =

Answer 5

Software Assurance = Trustworthiness + Predictable Execution

Question 6

Definition von SWA (Software Assurance)

Answer 6

• level of confidence that software is free from vulnerabilities, either intentionally designed or accidentally inserted at any time during its lifecycle and
• that software functions in the intended manner

Question 7

Trustworthiness =

Answer 7

no weaknesses that can be exploited (maliciously or unintentionally)

Question 8

Predictable execution =

Answer 8

if you execute, its working as intended (correct function)

Question 9

Coder = Requirements Engineering?

Answer 9

Coder =/= Requirements Engineering
- Needs special know-how
- really hard for normal engineers to do
- overcome creator blindness
BUT coder can be a big help:
- know their code and how to change it
- and the consequences of their actions

Question 10

Business Analysis = Requirements Engineering?

Answer 10

Business Analysis =/= Requirements Engineering

Question 11

Business Analysis =

Answer 11

Solutions to business problems (often include software-systems development component but may also include improvement, organizational change or strategic planning and policy development)

Question 12

Requirements Engineering =

Answer 12

process of formulating, documenting and maintaining software requirements

Question 13

Requirement Engineer Role

Answer 13

• often at the center of attention
• direct contact with stakeholders
• ability and responsibility to become as familiar as possible with the domain and to understand it

Question 14

Purpose of Requirement Engineering during Requirement Analysis:

Answer 14

Clear requirements and complete specification allow:
- accurate effort estimation
- better planning (tasks, resources)
- faster implementation (less dev questions, less room for assumptions)
- better quality (fewer defects)
- less CRs/rework

Question 15

What is crucial for Requirement Engineering?

Answer 15

Internal Knowledge of business needs is crucial:
- Stakeholders are not always available
- Business stakeholders might not see the “big picture”
- “Single point of contact” for developers and for business

Question 16

Requirement Analysis (RA) project life-cycle

Answer 16

Question 17

Requirement Analysis (RA) project life-cycle:
REQUIREMENT ANALYSIS

Answer 17

• Analysis of stakeholders
• Analysis of documents
• Elicitation of requirements
• Workshops, interviews
• Analysis of business and user requirements
• listing of use cases

Question 18

Requirement Analysis (RA) project life-cycle: DESIGN

Answer 18

• Detailed specification of:
  ** Business processes
  ** Actors
  ** use cases
  ** Interfaces
• GUI / Interaction design
• Specification reviews
• Specification approval

Question 19

Requirement Analysis (RA) project life-cycle: IMPLEMENTATION

Answer 19

• Spec walkthrough with TPLs (Technical Project Leads), developers
• Developer support
• Clarification of new open points with business
• Change management

Question 20

Requirement Analysis (RA) project life-cycle: TESTING

Answer 20

• Test support
• Defect clarification
  Clarification of new open issues
• Change management

Question 21

Requirement Analysis (RA) project life-cycle: EVOLUTION

Answer 21

• Analysis of change-requests
• Customer support
• Cleaning up documentation

Question 22

Requirement Engineering =
Requirement Management =
Solution Design =

Answer 22

Requirement Engineering: create and document
Requirement Management: proof, synchronize and manage
Solution Design: search for solutions and document it

Question 23

Defining System and Context Boundaries

Answer 23

Question 24

Eliciting (elizitieren, herausschälen) Requirements:

Answer 24

• Stakeholder analysis
• Requirement sources
  ** Stakeholder
  ** Documents
  ** Systems
• Requirement tpye:
  ** Functional
  ** Quality / non-functional
  ** general regulations or conditions

Question 25

Important during Documetation

Answer 25

referencing and clear description

Question 26

Why to use Diagrams during documenting?

Answer 26

Standardization and overall the same degree of detail

Question 27

System component diagram:

Answer 27

- component - interface

Question 28

Use case diagram:

Answer 28

- actor - function

Question 29

Business Object model:

Answer 29

- Business object - relationships

Question 30

Screen flows:

Answer 30

- Screens - Navigation

Question 31

Screens:

Answer 31

- Screen - Description of content

Question 32

Purpose of Requirement Engineering?

Answer 32

Minimizing the risk of deliviering something the customer didn't want or need

Question 33

Requirement Engineering is a... approach to ...

Answer 33

systematic and disciplined approach to the specification and management of requirements.

Question 34

Part of Requirement Engineering is:

Answer 34

- Knowing the relevant requirements - achieving a consensus among the stakeholders about these requirements - documenting them according to givens tandards - managing them systematically - understanding and documenting the stakeholders desires and needs

Question 35

Requirement Engineering view and target

Answer 35

- Human-centric view - Target: statisified customer

Question 36

Important during Requirement Engineering

Answer 36

Know-how einbringen, customer may not be aware!

Question 37

Characteristics of a Requirement

Answer 37

- High-Level or Detailed - Basis for an upcoming contract that you bid for - Basis for a contract itself

Question 38

Continous work during the development process:

Answer 38

- elicit stakeholders requirements - document requirements suitable - validate and verify requirements - manage requirements during entire life cycle

Question 39

Key types of non-functional requirements

Answer 39

Question 40

4-core activites of Requirement Engineering

Answer 40

- Elicitation - Documentation - Validation and negotation - Management

Question 41

Cosntraints =

Answer 41

requirement that limits the solution space (e.g. temporal availiability of project members etc.)

Question 42

Static vs. Agile

Answer 42

static: RE espeically at the beginning, all requirements, aim to completely elicit all requirements Agile: "on the move", continous eliciting necessary requirements

Question 43

Representation of Requirements:

Answer 43

- Presentation ** Functionality: Function, data, behavior ** Attribute: performance, quality, surrouding conditions - Degree of freedom: **Choice of the instrument ** Structure ** Precision ** Deepness

Question 44

Necessary capabilities of a requirement engineer:

Answer 44

- Analytic thinking - Empathy - Quick thinking - Communication skills - Conflict resolution skills - Moderation skills - Self-confidence - PERSUASIVENESS - Thinking out of the box

Question 45

Types of Requirements

Answer 45

- Functional Requirements - Quality Requirement (non-functional)

Question 46

Functional Requirement =

Answer 46

what should people can do (often come from the user)

Question 47

Non-Functional Requirements =

Answer 47

How a product should do it (often from technician, software architect or analyst) --> Product Goals

Question 48

Function Requirements are divided into:

Answer 48

- Functional requirements - Behavioral requireemnts - Data requirements

Question 49

Documentation of functional requirements:

Answer 49

"user stories"

Question 50

Quality requirement are divided into:

Answer 50

- performance - availability - dependability - scalability - portability ...

Question 51

Documentation of non-fuctional requirements:

Answer 51

acceptance criteria

Question 52

Security = functional requirement?

Answer 52

Security = NON-functional requirement