Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > Requirements Engineering (Chapter 4) > Flashcards

Requirements Engineering (Chapter 4) Flashcards

1
Q

What is Requirements Engineering?

A

The process of finding out, analyzing, documenting, & checking the services and constraints for Requirements

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

True or False: The term Requirement is unanimous and consistent across the Software Industry

A

False, the term is not used consistently

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

Describe why a Requirement might have different definitions across the software industry

A

A requirement can be a high-level, abstract statement of a service/constraint

A requirement can be a detailed, formal definition of a system function

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

Where do some of the problems in Requirements Engineering originate from?

A

Failing to make a clear separation between the different levels of description

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

Why do we often get Requirements wrong?

A

Because Requirements Engineering is hard

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

What percentage of defects are introduced during Requirements Activities?

A

40-50%

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

What are two ways to differentiate Requirements?

A

User Requirements

System Requirements

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

What is a User Requirement?

A

A high-level abstract requirement of what services the system is expected to provide the user

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

What is a System Requirement?

A

A detailed description of the system’s functions, services, & operational constraints

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

Why do Requirements need to be written in different ways?

A

Because different readers use them in different ways

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

List some reasons for why it’s hard to define Requirements

A 
Informal requirements gathering
Not able to articulate what's needed
Implied requirements (detailed implied from domain specific knowledge)
Miscommunicated Assumptions
Poorly Specified Requirements
Casual Change Process
Diversity of Interest in Stakeholders
Inevitable Economic & Business Change
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Who said, “To proclaim that you “have the requirements”
is delusional if all you really have is a pile of
email and voice mail messages, sticky notes,
meeting minutes, and vaguely recollected
hallway conversations”?

A

Wiegers

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

What are the 2 Types of Requirements?

A

Functional

Non-Functional (Technical)

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

What are Functional Requirements?

A

Services the system should provide
How the system should react to particular inputs
How the system should behave in particular situations

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

What are Non-Functional Requirements?

A

Constraints on the services or functions offered by the system

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

What constraints can Non-Functional Requirements include?

A

Timing Constraints
Development Process constraints
Standards Constraints

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

True or False: Requirements are independent

A

False, requirements are not independent and one requirement often generates/constrains other requirements

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

What are the two types of Functional Requirements?

A

Business Requirements

User Requirements

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

What are Business Requirements?

A

Describe WHY the organization is implementing the system

Identify high-level business objectives of the customer

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

What are User Requirements?

A

Describe WHAT the system does at a high-level

User goals & the high-level tasks performed by users

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

What can User Requirements sometimes be grouped into?

A

Features

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

What should the Functional Requirements of a System ideally be?

A

Complete & Consistent

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

True or False: Individual Functional Requirements are often more important than Non-Functional Requirements

A

False, Non-Functional Requirements are often more critical

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

How can Non-Functional Requirements arise?

A 
Through user needs due to budget constraints
organizational policies
software/hardware interoperability
External Factors (e.g. safety regulations)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

What are the three types of Non-Functional Requirements?

A

Product Requirements
Organizational Requirements
External Requirements

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

What do Non-Functional Product Requirements specify?

A

Specify or constrain the runtime behavior of the software

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

What do Non-Functional Organizational Requirements specify?

A

Specify the broad system requirements derived from policies & procedures in the customer & developer’s organizations

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

What do Non-Functional External Requirements specify?

A

Specifies all requirements that are derived from external factors

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

What is a common problem with Non-Functional Requirements?

A

Stakeholders often set them as general goals (e.g. ease of use, rapid user response, etc)

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

True or False: Whenever possible, you should write non-functional requirements quantitatively so that they can be objectively tested

A

True

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

True or False: Non-Functional Requirements can conflict & interact with other Functional or Non-Functional Requirements

A

True

32
Q

What is difficult to separate in the Requirements Document?

A

Functional & Non-Functional Requirements

33
Q

What are the 3 Requirements Engineering Activities?

A

Elicitation
Analysis
Specification
Validation

34
Q

What is Requirement Elicitation?

A

The discovery of requirements through:
Interviews
User Workshops
Ethnography

35
Q

Why is Requirements Elicitation Important?

A

Identifies product’s category of users & stakeholders
Determine Business Objectives for product
Understand User Goals
Understand the Environment in which the system will operate

36
Q

Why is Requirements Elicitation difficult?

A

Stakeholders:

  • often don’t know what they want
  • Express needs in an implicit manner
  • Political motivations
  • Dynamics of environment & economy
37
Q

What are the 4 steps in Requirements Elicitation?

A
  1. Discovery & Understanding
  2. Classification & Organization
  3. Prioritization & Negotiation
  4. Documentation
38
Q

Requirements Elicitation is what kind of process?

A

Iterative with continual feedback

39
Q

What might stakeholders do if they feel their views aren’t being considered?

A

Undermine the Requirements Engineering Process

40
Q

What can Stakeholders with the same perspective be grouped together in?

A

A Product Viewpoint

41
Q

What are the 3 Product Viewpoints?

A 
Interactor Viewpoint (Primary Actors)
Indirect Viewpoint (Supporting Actors)
Domain Viewpoint (Environment)
42
Q

What role does a Project Glossary serve?

A

Establish a Ubiquitous Language that both Domain Experts & Technical Experts understand & agree on

43
Q

List 3 characteristics of Elicitation Interviews

A
  • Effective without taking too much stakeholder time
  • closed Interviews have a set of predefined questions
    Open Interviews are exploratory & have general goals
44
Q

List 3 characteristics of Elicitation Workshops

A
  • Facilitated sessions with multiple, diverse stakeholders
  • Resource intensive with numerous participants
  • Must be well-planned
45
Q

List 2 Characteristics of Elicitation Ethnography

A
  • Time consuming (used for important high-risk tasks involving multiple users)
  • Silent or interactive
46
Q

What is Requirements Analysis?

A

The process of deriving more precise requirements received from users & domain experts

47
Q

What is involved in Requirements Analysis?

A
  • Decomposing high-level requirements into lower-level requirements/attributes
  • Derive precise Functional Requirements
  • Model the application environment
  • Create Prototypes to validate requirements
  • Prioritize requirements & analyze feasibility
48
Q

What is Requirements Specification?

A

The process of writing down the user & system Requirements in a Requirements Document

49
Q

What should the Requirements Document not include?

A

Details of the system architecture or design

50
Q

In Requirements Specification, what are User Requirements recorded as?

A

User Stories/Use-Cases

51
Q

In Requirements Specification, what are Functional Requirements recorded as?

A

Use-Case Scenarios/Story Conversions

Acceptance Criteria

52
Q

What are some good Requirements Specification Best Practices?

A
  • Develop & use a standardized template for recording requirements
  • Uniquely identify each requirement to allow effective management
  • Identify & maintain the origin of all requirements for traceability
  • Record Business Rules & other Domain Requirements
  • Record Non-Functional Requirements to ensure the product satisfies expectations and constraints
53
Q

What is Requirements Validation?

A

The process of affirming the correctness of the requirements in order to build a suitable solution

54
Q

What is involved in Requirements Validation?

A
  • Review the recorded requirements as a group through Requirement Inspection
  • Develop System Tests from recorded requirements
  • Define the Acceptance Criteria used by users to determine the suitability of the resulting system (meets requirements)
55
Q

What is a Use-Case Model?

A

A collection of written Use-Cases, Actors, & Use-Case Diagrams

56
Q

What does a Use-Case identify?

A

the Actors involved in an interaction & the type of interaction

57
Q

What are Actors?

A

Actors are Behavioural Entities that interact with the System under Discussion (SuD)

58
Q

True of False: Use-Cases are diagrams

A

False, Use-Cases are Text Documents that describe related success & failure scenarios of system interaction

59
Q

What is a Use-Case

A

A way of describing interactions between Users & a system using a graphical model & structured text

60
Q

What are the 3 types of Actors?

A

Primary Actor
Supporting Actor
Offstage Actor

61
Q

What is a Primary Actor?

A

A type of user of the system that uses the system in order to achieve a specific goal

62
Q

What is a Supporting Actor?

A

A user that provides a service to the system, but by definition, are external to the system

63
Q

What is an Offstage Actor?

A

A stakeholder that DOES NOT interact directly with the system, but has an interest in it (e.g. government entity)

64
Q

What are the 4 fundamental parts of a Use-Case Diagram?

A

Actor
Association Relationship
Use-Case
Supporting Actor (if applicable)

65
Q

What are the 3 Relationship Types in Use-Case Diagrams

A

Association
Dependency
Generalization

66
Q

What is an Association Relationship?

A

Shows the communication between actor & use-case

67
Q

What is an Include Dependency?

A

Stereotype that shows one use-case using another

68
Q

What is an Extend Dependency?

A

Stereotype showing alternative or exceptional scenarios

69
Q

What is a IS-A Generalization Relationship?

A

A relationship with the same reusability semantics as in class diagrams

70
Q

What are the 3 Use-Case Levels?

A

Summary
User Goals
Subfunctions

71
Q

What is shown in the Summary Use-Case Level?

A

Context
Life-Cycle Sequence
Table of Contents for User-Goal Use-Cases

72
Q

What is shown in the User Goals Use-Case Level?

A

Represents goals of primary actors & how they achieve their goals using the system (most Use-Cases are at this level)

73
Q

What is shown in the Subfunctions Use-Case Level?

A

Portions of Use-Cases that are common to multiple User-Goal Use-Cases (Used when Use-Case are too long)

74
Q

What are the 3 Use-Case Formats?

A

Brief
Casual
Fully Dressed

75
Q

What is a Brief Format Use-Case?

A

Use-Case is informally written as a story

76
Q

What is a Casual Format Use-Case?

A

Use-Case describes multiple related scenarios

77
Q

What is a Fully Dressed Format Use-Case?

A

Use-Case is structured & shows more detail for more requirement completeness and reduced risk

Software Engineering (5 decks)

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