Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > Requirements Engineering > Flashcards

Requirements Engineering Flashcards

1
Q

What are introduced during requirements activities?

A

40% - 50% of defects

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

Why are requirements hard to define?

A

Informal requirements gathering
Not being able to articulate what is needed
Implied requirements, details implied from domain specific knowledge
Miscommunicated assumptions

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

Types of Requirements?

A

Functional Requirements

Non-Functional Requirements

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

Functional Requirements?

A

What the software is required to do
Exist at different level of abstractions, from high-level to detailed functional requirements
The features of the software systems

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

Non-Functional Requirements

Technical Requirements

A

How well is the software supposed to do what it is required to do
Constraints of different types on the software system
Quality requirements. The required-ilities the system must exhibit
External interfaces of other systems that the system under development must interact with

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

List Functional Requirements?

A

Business Requirements
User Requirements
Functional Requirements

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

Business Requirements?

A

Describe why the organization is implementing the system
Identify high-level business objectives of the customer
Typically documented in plain English in a vision and scope document

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

User Requirements?

A

Describe what the system does at a high-level
User goals and the high-level tasks performed by users
User requirements are sometimes grouped into features

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

Functional Requirements?(List)

A

Specify how the user-goals are accomplished, the detailed steps that users must carry out to accomplish their goals
Describe what developers must implement

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

Business requirements are defined by?

A

Business managers
and/or
Marketing departments

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

User requirements are derived from business requirements by?

A

The business/system analyst
or
Product manager

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

Functional requirements are defined by?

A

The analyst

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

Non-Functional Requirements Definition?

A

Define how well the software does its job.

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

Technical Requirements List

A

Product Requirements
Organizational Requirements
External Requirements

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

Constraints on the functional requirements of the system?

A

Timing, speed, memory, security, regulatory

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

Quality requirements?

A

Usability, maintainability, reliability, portability

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

External interfaces required for the system to interact with?

A

Existing infrastructure

External systems

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

Domain driven design aims at defining?

A

A ubiquitous language that is understood by both domain and software experts

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

Domain modelling helps define?

A

The ubiquitous language through a model and a glossary of terms

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

Requirements Development Activities?

A

Elicitation (Communicate)
Analysis (Think)
Specification (Write)
Validation (Verify)

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

Inception Iteration (Sprints)

A
  1. Define business requirements
  2. Identify user classes
  3. Identify user representatives
  4. Identify requirements decision makers
  5. Plan elicitation
  6. Identify user requirements
  7. Prioritize user requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Elaboration Iterations (Sprints)

A
  1. Flesh out user requirements
  2. Derive functional requirements
  3. Model the requirements
  4. Specify nonfunctional requirements
  5. Review requirements
  6. Develop prototypes
  7. Develop or evolve architecture
  8. Allocate requirements to components
  9. Develop tests from requirements
  10. Validate user requirements, functional requirements, nonfunctional requirements, analysis models, and prototypes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Requirements Elicitation?

A 
The discovery of requirements.
Identify product's categories of users and stakeholders
Determine the business objectives
Understand the user goals
Understand the environment
24
Q

Stakeholder viewpoints?

A

Interactor viewpoint of primary actors
Indirect viewpoint of supporting actors
Domain viewpoint of the environment

25
Q

Establish a ubiquitous language that?

A

Both domain experts and technical experts understand and agree on

26
Q

Elicitation Techniques?

A

Elicitation Interviews
Elicitation Workshops
Observation / Ethnography

27
Q

Elicitation Interviews?

A

Individual or in small groups

  • Effective without taking too much stakeholder time
  • Closed interviews have a set of predefined questions
  • Open interviews are exploratory and have general goals
28
Q

Elicitation Workshops?

A

In larger groups but not too large

  • Facilitated sessions with multiple stakeholders and diverse types of stakeholders not just customers like developers and testers
  • Resource intensive with numerous participants
  • Must be well-planned
29
Q

Observation / Ethnography?

A

To discover the state of practice

  • Time consuming, used for important high-risk tasks involving multiple types of users
  • Silent or interactive, might use video recordings if allowed / appropriate.
30
Q

Requirements Analysis?

A

Analyze Requirements
Decompose higher-level requirements to lower level requirements
Derive precise functional requirements from user-requirements
Model the application environment and the requirements of the project at different levels of abstraction
Create prototypes to validate requirements
Prioritize requirements and analyze feasibility

31
Q

Detailed requirements are recorded in a?

A

Structured format that is consistent, accessible, reviewable, easy to understand.

32
Q

Business requirements recorded in a?

A

Vision and scope document

33
Q

User requirements are recorded as?

A

Use-cases or stories

34
Q

Functional requirements are recorded as?

A

Use-case scenarios or story conversations and acceptance criteria

35
Q

The detailed functional and non-functional requirements are recorded in a?

A

Software Requirements Specification

36
Q

Requirements Specification Good Practices?

A

Develop and use a standardized template for recording requirements
Uniquely identify each requirement to allow effective requirements management
Identify and maintain the origin of all requirements to allow the traceability need to manage change
Record business rules and other domain requirements separately as they represent an enterprise-level asset
Record the non-functional requirements to ensure the product satisfies quality expectations and other constraints

37
Q

Requirements validation?

A

Confirms that we have correct requirements.
Review the recorded requirements through requirement inspection
Develop system tests from recorded requirements
Define the acceptance criteria used by users to determine that the resulting system is suitable and has met the requirements

38
Q

System tests from recorded requirements?

A

Ensures requirements are testable which eliminates ambiguities and vagueness and can also highlight conflicts
Tests can be easily derived from requirement when these are recorded.

39
Q

Building a requirements model?

A

Will define a model of the system from a requirements perspective.

40
Q

System Context Diagram?

A

Defines the scope of the system

41
Q

List requirements model components?

A

System Context Diagram
Business Requirements
Actors
Functional Areas

42
Q

Use-cases are?

A

Text documents, not diagrams, that describe related success and failure scenarios of iteration between actors and SuD.

43
Q

Use-Case Diagrams show?

A

Which actors interact with which use-cases and how use-cases related to each other

44
Q

Use-Case Model?

A

Is the collection of a written use-cases, actors, and use-case diagrams.

45
Q

Types of Actors?

A

Primary Actor
Supporting Actor
Offstage Actor

46
Q

Primary Actor?

A

A type of user of the system under discussion (SuD) that uses the system in order to achieve specific goal.

47
Q

Example of Primary Actor?

A

Cashier using a POS system

48
Q

Supporting Actor?

A

An actor that provides a service to the system under discussion

49
Q

Example of Supporting Actor?

A

Twitter as used in an e-commerce application or payment authorization system like PayPal

50
Q

Offstage Actor?

A

A stakeholder that does not interact directly with a system but has interest in.
To ensure all requirements have been identified

51
Q

Example of Offstage Actor?

A

Government Agency

52
Q

Relationships in Use-Case Diagrams?

A

Association
Dependency
Generalization

53
Q

Association?

A

Used between actor and use-case

Shows the communication of the actor with the system under discussion

54
Q

Dependency?

A

“Include” relationships are dependencies with the <> stereotype showing one-use using another
“Extend” relationship are dependencies with the <> stereotype showing alternative or exceptional scenarios

55
Q

Generalization?

A 
Is-A Relationship with the same reusability semantics as in class diagrams.
Used between two actors or two use-cases
56
Q

Fully Dressed?

A

Use-cases are structures and show more detail allowing for more complete requirements and less risk

Software Engineering (7 decks)

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