Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

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
What are the three types of Non-Functional Requirements?
Product Requirements Organizational Requirements External Requirements
26
What do Non-Functional Product Requirements specify?
Specify or constrain the runtime behavior of the software
27
What do Non-Functional Organizational Requirements specify?
Specify the broad system requirements derived from policies & procedures in the customer & developer's organizations
28
What do Non-Functional External Requirements specify?
Specifies all requirements that are derived from external factors
29
What is a common problem with Non-Functional Requirements?
Stakeholders often set them as general goals (e.g. ease of use, rapid user response, etc)
30
True or False: Whenever possible, you should write non-functional requirements quantitatively so that they can be objectively tested
True
31
True or False: Non-Functional Requirements can conflict & interact with other Functional or Non-Functional Requirements
True
32
What is difficult to separate in the Requirements Document?
Functional & Non-Functional Requirements
33
What are the 3 Requirements Engineering Activities?
Elicitation Analysis Specification Validation
34
What is Requirement Elicitation?
The discovery of requirements through: Interviews User Workshops Ethnography
35
Why is Requirements Elicitation Important?
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
Why is Requirements Elicitation difficult?
Stakeholders: - often don't know what they want - Express needs in an implicit manner - Political motivations - Dynamics of environment & economy
37
What are the 4 steps in Requirements Elicitation?
1. Discovery & Understanding 2. Classification & Organization 3. Prioritization & Negotiation 4. Documentation
38
Requirements Elicitation is what kind of process?
Iterative with continual feedback
39
What might stakeholders do if they feel their views aren't being considered?
Undermine the Requirements Engineering Process
40
What can Stakeholders with the same perspective be grouped together in?
A Product Viewpoint
41
What are the 3 Product Viewpoints?
``` Interactor Viewpoint (Primary Actors) Indirect Viewpoint (Supporting Actors) Domain Viewpoint (Environment) ```
42
What role does a Project Glossary serve?
Establish a Ubiquitous Language that both Domain Experts & Technical Experts understand & agree on
43
List 3 characteristics of Elicitation Interviews
- Effective without taking too much stakeholder time - closed Interviews have a set of predefined questions Open Interviews are exploratory & have general goals
44
List 3 characteristics of Elicitation Workshops
- Facilitated sessions with multiple, diverse stakeholders - Resource intensive with numerous participants - Must be well-planned
45
List 2 Characteristics of Elicitation Ethnography
- Time consuming (used for important high-risk tasks involving multiple users) - Silent or interactive
46
What is Requirements Analysis?
The process of deriving more precise requirements received from users & domain experts
47
What is involved in Requirements Analysis?
- 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
What is Requirements Specification?
The process of writing down the user & system Requirements in a Requirements Document
49
What should the Requirements Document not include?
Details of the system architecture or design
50
In Requirements Specification, what are User Requirements recorded as?
User Stories/Use-Cases
51
In Requirements Specification, what are Functional Requirements recorded as?
Use-Case Scenarios/Story Conversions | Acceptance Criteria
52
What are some good Requirements Specification Best Practices?
- 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
What is Requirements Validation?
The process of affirming the correctness of the requirements in order to build a suitable solution
54
What is involved in Requirements Validation?
- 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
What is a Use-Case Model?
A collection of written Use-Cases, Actors, & Use-Case Diagrams
56
What does a Use-Case identify?
the Actors involved in an interaction & the type of interaction
57
What are Actors?
Actors are Behavioural Entities that interact with the System under Discussion (SuD)
58
True of False: Use-Cases are diagrams
False, Use-Cases are Text Documents that describe related success & failure scenarios of system interaction
59
What is a Use-Case
A way of describing interactions between Users & a system using a graphical model & structured text
60
What are the 3 types of Actors?
Primary Actor Supporting Actor Offstage Actor
61
What is a Primary Actor?
A type of user of the system that uses the system in order to achieve a specific goal
62
What is a Supporting Actor?
A user that provides a service to the system, but by definition, are external to the system
63
What is an Offstage Actor?
A stakeholder that DOES NOT interact directly with the system, but has an interest in it (e.g. government entity)
64
What are the 4 fundamental parts of a Use-Case Diagram?
Actor Association Relationship Use-Case Supporting Actor (if applicable)
65
What are the 3 Relationship Types in Use-Case Diagrams
Association Dependency Generalization
66
What is an Association Relationship?
Shows the communication between actor & use-case
67
What is an Include Dependency?
Stereotype that shows one use-case using another
68
What is an Extend Dependency?
Stereotype showing alternative or exceptional scenarios
69
What is a IS-A Generalization Relationship?
A relationship with the same reusability semantics as in class diagrams
70
What are the 3 Use-Case Levels?
Summary User Goals Subfunctions
71
What is shown in the Summary Use-Case Level?
Context Life-Cycle Sequence Table of Contents for User-Goal Use-Cases
72
What is shown in the User Goals Use-Case Level?
Represents goals of primary actors & how they achieve their goals using the system (most Use-Cases are at this level)
73
What is shown in the Subfunctions Use-Case Level?
Portions of Use-Cases that are common to multiple User-Goal Use-Cases (Used when Use-Case are too long)
74
What are the 3 Use-Case Formats?
Brief Casual Fully Dressed
75
What is a Brief Format Use-Case?
Use-Case is informally written as a story
76
What is a Casual Format Use-Case?
Use-Case describes multiple related scenarios
77
What is a Fully Dressed Format Use-Case?
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.
© 2025 Bold Learning Solutions. Terms and Conditions