Requirements Engineering Flashcards

(28 cards)

1
Q

Requirements Engineering Process

A
  • analyzing the problem
  • documenting the resulting observations in a variety of representation formats
  • checking the accuracy of the understanding gained
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Requirements Engineering

A
  • common agreement among all parties
  • describes “what the product will do, but not how to do it”
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is a requirement?

A
  1. condition/capability needed by the user to solve a problem or achieve an objective
  2. condition/capability that must be met by system or system component to satisfy customer needs
  3. documented representation of condition/capability
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Types of Requirements

A
  1. User requirements
  2. System requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

User Requirement

A

Written for customers. Statements in natural language of system services and constraints. Overall system goal

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

System Requirements

A

Written for contract. Structured document with detailed descriptions of the system functions, services, and constraints. Specific system features

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

Functional Requirement

A
  • describe functionality or overall system services
  • high-level statements of what system should do
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Domain Requirements

A

Depends on where product is used. Constraints on system from domain of operation. (must be ferpa compliant)

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

Non-Functional Requirement

A

Gives rise to functional requirements.
- constraints on services or functions offered by the system.
- often apply to whole system instead on individual feature
- more critical then functional requirements, wo them system may be useless

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

Goal

A
  • general intention of the user (such as ease of use)
  • help to define non-functional requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Requirements Engineering Activities

A
  • elicitation
  • analysis
  • specification
  • verification
  • management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Requirements Elicitation

A

Process through which customers and developers discover, review, articulate, and understand the user needs and system constraints

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

Requirements Analysis

A

Process of analyzing user needs to arrive at definition of software requirements

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

Requirements Specification

A

Development of a document the clearly and precisely records each requirement

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

Requirements Verification

A

Process of ensuring the software requirements specification is in compliance with the system requirements

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

Requirements Management

A

Planning and controlling of the requirements elicitation specification, analysis, and verification activities

17
Q

Requirements Evaluation

A
  • validity
  • consistency
  • completeness
  • realism/feasibility
  • verifiability
  • unambiguous
  • traceable
18
Q

Requirements Evaluation - Unambiguity

A

Whether it has only one possible interpretation

19
Q

Requirements Evaluation - Completeness

A

Whether all required functions and design constraints are present and fully developed

20
Q

Requirements Evaluation - Consistency

A

Whether no other requirements are conflicting with it

21
Q

Requirements Evaluation - Testable

A

Whether requirement can be tested

22
Q

Requirements Evaluation - Traceable

A

Whether origin of requirement is clear

23
Q

Requirements Engineering Participants

A
  • customer
  • user
  • requirements engineer/analyst
  • developer
  • v&v agent
24
Q

Artifacts

A

Includes:
* Requirements Specification: what does the system do?, who identified the requirement, contextual information
* Validation/verification audit reports
* Output of requirements management tool

25
Requirements Change Management
Deciding if a requirement change should be accepted: * Problem analysis and change specification * Change analysis and costing * Change implementation
26
Natural Language Specification
* Requirements are written as natural language sentences * Supplemented by diagrams and tables * Can be understood by users/customers
27
Guidelines for Writing Requirements
* Invent standard format and use for all reqs * Use language in a consistent way across reqs * Use text highlighting to identify keys parts of reqs * Avoid use of computer jargon * Include explanation of req
28
Problems with Natural Language
* Lack of clarity * Improper classification * Requirements amalgamation (several reqs improperly combined together)