Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > Chapter 9 - Requirements Engineering > Flashcards

Chapter 9 - Requirements Engineering Flashcards

1
Q

Requirements engineering is a cyclical process involving four types of activities

A

elicitation, specification, validation/verification, and negotiation

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

Define: requirement

A

a condition or capability needed by a user to solve a problem or achieve an objective

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

Define: requirements specification

A

the mutual understanding of the problem to be solved between the analyst and the client

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

In the design phase

A

the architecture of the system is devised in terms of system components and interfaces between those components

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

Define: Requirements elicitation

A

understanding the problem

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

Define: Requirements specification

A

describing the problem

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

Define: Requirements validation/verification

A

agreeing upon the nature of the problem: making sure the correct requirements are state(validation) and that those requirements are stated correctly(verification)

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

Define: explicit conceptual model

A

contains all relevant information from the universe of discourse

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

Define: implicit conceptual model

A

shared background knowledge of people in the universe of discourse

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

Define: requirements negotiation

A

agreeing upon the bounds of the problem

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

Define: domain

A

the general field of business/tech in which the clients will use the software

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

Define: domain expert

A

someone with deep knowledge of the domain

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

Benefits of performing domain analysis?

A

faster development, better system, anticipation of extensions

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

A problem can be expressed as

A

a difficulty customer/users are facing an opportunity that will result in benefit

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

Define: functional requirements

A

what the system should do

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

Define: quality requirements

A

(verifiable) constraints on the design to meet specified levels of quality

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

Define: platform requirements

A

constraints on the environment and tech of the system

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

Define: process requirements

A

constraints on the project plan and development methods

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

Define: universe of discourse

A

part of reality we are interested in modeling

20
Q

Two types of problems faced in conceptual modeling

A

analysis problems - difficulties codifying negotiation problems - people counteracting process

21
Q

Define: paradigm

A

set of assumptions about a topic, 2 types: -epistemological(how knowledge is learned) -ontological(how the world is)

22
Q

Dimension of epistemological(how knowledge is learned) assumptions

A

objective-science & models used to derive universal truth subjective-

23
Q

Dimension of ontological(how the world is) knowledge

A

order - order, stability, integration, and consensus

disorder - change, cnoflich, and disintegration

24
Q

What are the four archetypical approaches to requirements engineering?

A

functional

social-relativism

radical-structuralism

neohumanism

25
Q

Define: functional approach to requirements engineering

A

(epistemologically objective, ontologically order-oriented) the analyst is the expert who empirically seeks the truth

26
Q

Define: social-relativism approach to requirements engineering

A

(epistemologically subjective, ontologically order-oriented) the analyst is the change agent. requirements engineering is a learning process guided by the analyst

27
Q

Define: radical-structuralism approach to requirements engineering

A

(epistomologically objective, ontologically conflict-oriented) there is a struggle between classes; the analyst chooses for either party

28
Q

Define: neohumanism approach to requirements engineering

A

(epistomologically subjective, ontologically conflict-oriented) the analyst is a kind of social therapist, bringing parties together

29
Q

Elicitation techniques

A

Asking

Observing

others;

  • Business Process Redesign
  • prototyping
  • domain analysis
30
Q

You should generally vacuum a rug in

A

two directions rather than one; likewise, you should use multiple requirements elicitation techniques. (pg. 217)

31
Q

Methods for ‘asking’ users to elicit requirements

A

Interviews

  • specific details

Brainstorming

-appoint moderator

32
Q

Forms of ‘observing’ for eliciting requirements

A

Task analysis

Scenario-based analysis

Form analysis

33
Q

Define: task analysis

A

process of analyzing how people perform their jobs; the things they do, the things they act on, and the things they need to know

34
Q

Define: scenario-based analysis

A

projects concrete description of activity, sufficiently detailed to infer/reason about

more user-oriented view perspective on design and development of system

35
Q

Define: form analysis

A

analyzing forms used for info on data object, properties, and their interrelations

36
Q

Define: use case analysis

A

Determine actors

Determine tasks each actor will do in system

37
Q

Define: use case

A

a typical sequence of actions a user performs to complete a given task

38
Q

Define: use case model

A

A set of use cases and an optional description/diagram indicating how they are related

39
Q

A use case should

A
  • Cover full sequence of steps
  • Describe user’s interaction
  • Be independent from UI
  • Only indicate actions between actor/computer
40
Q

Define: scenario

A

a specific instance of a use case(specific actor, specific time, specific data)

41
Q

Benefits of use cases

A
  • define scope of system
  • plan dev process
  • develop/validate requirements
  • form basis for test cases
42
Q

Define: requirements definition

A

an informal outline of requirements in few paragraphs/simple diagrams

43
Q

Define: MoSCoW model

A

Must have - top priority

Should haves - highly desirable

Could haves - if time allows

Won’t haves - not today

44
Q

What is IEEE Standard 830

A

IEEE Recommended Practice for Software Requirements Specifications

45
Q

Define: requirements traceability

A

Software Engineering (6 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions