Requirements Engineering Flashcards

1
Q

What is Requirements Engineering?

A
  • Identify Stakeholders
  • Understand Customer/User’s needs
  • Requirements gathering and identification
  • Clarify, Analyze, Define, Specify, Prioritize, Track, Validate Requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What happens without Requirements Engineering

A
  • Many varied consequences
  • System may fail or be useless
  • Difference between quality and luxury
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

V Model

A

Stakeholder Requirements -> Acceptance Test.

System Requirements -> System Test.

Subsystem Requirements -> Integration Test

Component Requirements -> Unit Test

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Coverage Analysis

A

Highest layer checks if lower layer requirements are satisfied

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Traceability Analysis

A
  • Impact Analysis: Change Management
  • Derivation Analysis: Cost-Benefit Analysis
  • Coverage Analysis: General Engineering Management Reporting
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Requirements & Modelling

A

Mutually supportive. Requirements Modelling doesn’t exist. Model system not requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Models of Requirements Engineering

A

Abstraction that focuses on some aspect of the system. Avoidance of irrelevant details.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Types of Requirements

A

Hardware Requirements:
- Performance Reqs
- Interface Reqs
- Speciality Engineering Reqs
- Environmental Reqs

Software Requirements:
- Functional Reqs
- Nonfunctional Reqs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Business Requirements

A

Essential, derived from business goals. Understand requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Stated Requirements vs Real Requirements

A

Stated Reqs proved by customer at start and Real Reqs are the verified needs for a system. RA differentiate between them

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

High Level Requirements

A

Capture vision of customer, define scope, allow estimation of cost

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Functional Requirements

A

Describe what solution must do. Operational requirements. Specify input and outputs and relationship between them.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Non Functional Requirements

A

System properties ex. safety or reliability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Derived Requirements

A

Refined from high level reqs. Distinguish between externally identified requirements and requirements derived under control of engineer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Design Requirements and Considerations

A

When upgrading the system, old system usually has constraints and will be present in new system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Performance Requirements

A

Defines how well functional requirements perform. Correspond to system level needs for availability, security and performance.

17
Q

Interface Requirements

A

Difficult to define. Physical and functional relationships amongst elements between environment.

18
Q

Verified Requirements

A

Real requirements that are met or satisfied in design solution. Checked before final system. Formal methods can be used.

19
Q

Validated Requirements

A

Requirements implemented into system. Validated and proven

20
Q

Qualified Requirements

A

Refers to validation or verification of item performance in applications and results from design and test data reviews and audits.

21
Q

Unknowable Requirements

A

Experience shows that some requirements are unknowable from the start. Only become apparent as system evolves.

22
Q

Developing Systems

A

Establish need for system. If purpose is unknown system will be unclear. Nature of explanation determines how rigorous the need is expressed.

23
Q

Levels of Requirements Engineering

A

Problem Domain: Statement of needs
Solution Domain: Stakeholder Requirements, System Reqs, System Component Reqs, Subsystem Component Reqs.

24
Q

Customer Acceptance

A

Agree input requirements with customer after defining risks. Generate requirements derived from input. Agree derived requirements with implementation team. Establish qualification strategy.

25
Q

System Modelling for Requirements Engineering

A

Supports analysis and design process by introducing formality. Use Pictures. Formalize representations with standard syntax and provide medium for understanding ideas.

26
Q

Benefits of Modelling

A
  • Encourages use of precisely defined vocabulary.
  • Allows system specifications and designs to be visualized in diagrams.
  • Allows considerations of multiple interacting aspects and views
  • Supports analysis of systems through a defined discipline
  • Allows validation of some aspects of the system design
  • Progressive refinement to detailed design
  • Encourages communication between orgs
27
Q

CORE

A

Designed to attempt defining problem itself. The central concept is the viewpoint and associated representation known as viewpoint heirarchy.

28
Q

SADT

A

Method of structured analysis. Graphical, heirarchical approach to problem. Set of blueprints refining problem until solution achieved.

29
Q

Basic elements of SADT

A

box, represents an activity or data. Joined by arrows representing data needed or provided by activity.