Chapter 9 - Requirements Engineering

Question 1

Requirements engineering is a cyclical process involving four types of activities

Answer 1

elicitation, specification, validation/verification, and negotiation

Question 2

Define: requirement

Answer 2

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

Question 3

Define: requirements specification

Answer 3

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

Question 4

In the design phase

Answer 4

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

Question 5

Define: Requirements elicitation

Answer 5

understanding the problem

Question 6

Define: Requirements specification

Answer 6

describing the problem

Question 7

Define: Requirements validation/verification

Answer 7

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

Question 8

Define: explicit conceptual model

Answer 8

contains all relevant information from the universe of discourse

Question 9

Define: implicit conceptual model

Answer 9

shared background knowledge of people in the universe of discourse

Question 10

Define: requirements negotiation

Answer 10

agreeing upon the bounds of the problem

Question 11

Define: domain

Answer 11

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

Question 12

Define: domain expert

Answer 12

someone with deep knowledge of the domain

Question 13

Benefits of performing domain analysis?

Answer 13

faster development, better system, anticipation of extensions

Question 14

A problem can be expressed as

Answer 14

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

Question 15

Define: functional requirements

Answer 15

what the system should do

Question 16

Define: quality requirements

Answer 16

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

Question 17

Define: platform requirements

Answer 17

constraints on the environment and tech of the system

Question 18

Define: process requirements

Answer 18

constraints on the project plan and development methods

Question 19

Define: universe of discourse

Answer 19

part of reality we are interested in modeling

Question 20

Two types of problems faced in conceptual modeling

Answer 20

analysis problems - difficulties codifying negotiation problems - people counteracting process

Question 21

Define: paradigm

Answer 21

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

Question 22

Dimension of epistemological(how knowledge is learned) assumptions

Answer 22

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

Question 23

Dimension of ontological(how the world is) knowledge

Answer 23

order - order, stability, integration, and consensus

disorder - change, cnoflich, and disintegration

Question 24

What are the four archetypical approaches to requirements engineering?

Answer 24

functional

social-relativism

radical-structuralism

neohumanism

Question 25

Define: functional approach to requirements engineering

Answer 25

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

Question 26

Define: social-relativism approach to requirements engineering

Answer 26

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

Question 27

Define: radical-structuralism approach to requirements engineering

Answer 27

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

Question 28

Define: neohumanism approach to requirements engineering

Answer 28

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

Question 29

Elicitation techniques

Answer 29

Asking Observing others; - Business Process Redesign - prototyping - domain analysis

Question 30

You should generally vacuum a rug in

Answer 30

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

Question 31

Methods for 'asking' users to elicit requirements

Answer 31

Interviews - specific details Brainstorming -appoint moderator

Question 32

Forms of 'observing' for eliciting requirements

Answer 32

Task analysis Scenario-based analysis Form analysis

Question 33

Define: task analysis

Answer 33

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

Question 34

Define: scenario-based analysis

Answer 34

projects concrete description of activity, sufficiently detailed to infer/reason about more user-oriented view perspective on design and development of system

Question 35

Define: form analysis

Answer 35

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

Question 36

Define: use case analysis

Answer 36

Determine actors Determine tasks each actor will do in system

Question 37

Define: use case

Answer 37

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

Question 38

Define: use case model

Answer 38

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

Question 39

A use case should

Answer 39

- Cover full sequence of steps - Describe user's interaction - Be independent from UI - Only indicate actions between actor/computer

Question 40

Define: scenario

Answer 40

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

Question 41

Benefits of use cases

Answer 41

- define *scope* of system - *plan* dev process - develop/validate requirements - form basis for test cases

Question 42

Define: requirements definition

Answer 42

an informal outline of requirements in few paragraphs/simple diagrams

Question 43

Define: MoSCoW model

Answer 43

Must have - top priority Should haves - highly desirable Could haves - if time allows Won't haves - not today

Question 44

What is IEEE Standard 830

Answer 44

IEEE Recommended Practice for Software Requirements Specifications

Question 45

Define: requirements traceability