Babok Chapter 6 Requirements Analysis

Front 1

What type of use case relationship does the following scenario best describe: For a case law
system for attorneys, many use cases need to search for legal cases. Instead of putting
redundant search functionality into each use case, the search requirements were written in one
use case and then referred to by any use case that needed it. ,
a. Include.
b. Extend.
c. Expanded.
d. Generalization.

Back 1

a. Include.

Hint 1

DEF: allows for the base use case to make use of
functionality present in another use case. "Redundant
information is the key. BABOK 9.26.3.6.

Front 2

Associations (interfaces) in a Use Case diagram are shown through:
a. Stick figures.
b. Ovals.
c. Arrows.
d. Lines.

Back 2

d. Lines.

Hint 2

Relationships between actors and use cases are called
associations. Associations do not represent input,
output, time or dependency. An association line only
indicates that an actor has access (of some kind) to the
functionality represented by the use case. Fig 9-11;
BABOK 9.26.3.6.

Front 3

You have produced your first attempt at modeling entity relationships after eliciting
requirements from business area experts. You are seeking a further review in order to validate
the required data. Who would you seek for such a review?
a. Quality assurance analyst after translating the model into text.
b. Project Manager.
c. Business domain SME after translating the model into text.
d. Database analyst.

Back 3

c. Business domain SME after translating the model into text.

Hint 3

They are responsible for verifying and validating the
requirements. BABOK 6.3.6.

Front 4

Deliverables from the structured walkthrough will likely include which of the following lists:
a. List of documents analyzed, list of models developed, list of features, list of tables.
b. List of preventive actions required to make the document acceptable for approval.
c. List of quality improvements required.
d. List of current business processes, list of fmancial metrics, list of constraints and
assumptions, list of other issues.

Back 4

c. List of quality improvements required.

Hint 4

From the BABOK9.30.3.2.

Front 5

In the first weeks following launch of a new web-based application, a critical report failed due
to an unhandled exception. Investigation demonstrated that a worker in the system had used a
financial field as a comment field and input the words 'Not available'. Even after extensive
testing, there was no on-line screen edit for a numeric-only value in this field. Which
technique might have prevented the problem?
a. Prototyping and document analysis.
b. Use cases and business process modeling.
c. Use cases and prototyping.
d. Data modeling and business process modeling.

Back 5

d. Data modeling and business process modeling.

Hint 5

Both of these techniques help discover exception handling and required edits.
BABOK 9.7.3 and 9.21.3.

Front 6

Functional requirements may be specified using a variety of formats. Which of the following
correctly lists the types of functional requirements:
a. Logical, Physical, Formal, Informal.
b. Static, Dynamic, Data, Process.
c. Formal, Informal, Diagrams, Models.
d. Text, Matrix, Diagrams, Models.

Back 6

d. Text, Matrix, Diagrams, Models.

Hint 6

Formats for specifying requirements. Functional requirements can be expressed using these formats. BABOK 6.3.1, 6.4.3.1.

Front 7

Which techniques are used to validate requirements?
a. Metrics, Prototyping, Structured Walkthroughs.
b. Metrics, Structured Walkthroughs, Variance Analysis.
c. Risk Analysis, Structured Walkthroughs, Stakeholder Analysis.
d. Metrics, Acceptance Criteria, Variance Analysis.

Back 7

a. Metrics, Prototyping, Structured Walkthroughs.

Hint 7

BABOK 6.6.5.

Front 8

On a project a BA makes sure that a certain requirement is specified in enough detail to be
implemented. This is an example of which of the following activities:
a. Validating the requirement.
b. Verifying the requirement.
c. Documenting a transition requirement.
d. Specifying and modeling the requirement.

Back 8

b. Verifying the requirement.

Hint 8

BABOK 6.5.1.

Front 9

Documenting a requirement that describes a customer's interaction with a proposed system to
accomplish a goal is best associated with which of these techniques:
a. Goal Decomposition.
b. Activity Diagram.
c. Use Case Description.
d. User Story.

Back 9

c. Use Case Description.

Hint 9

Definition of a Use Case. The interaction element of the question is key. "Use case analysis can start with goals or events.". BABOK 6.2.4.2.

Front 10

When documenting data requirements using a data model, what is the preferred way to handle
related business rules that affect the data?
a. Document the related business rules in text form as supplemental documentation.
b. Document all related business rules in a process model.
c. Business rules are unrelated to data requirements, so there is nothing special to do.
d. Document the related business rules with metadata defmitions.

Back 10

a. Document the related business rules in text form as supplemental documentation.

Hint 10

BABOK Section 9.7.2. Also, in describing business rules, Section 9.4.3, the BABOK refers to data modeling (9.7).

Front 11

What are the Tasks in Analyzing Requirements?

Back 11

Prioritize Requirements
Organize Requirements
Specify and Model Requirements
Define Assumptions and Constraints
Verify Quality of Requirements
Validate Requirements

Hint 11

POMA VV (POMA Apples and Valid and Verified)

Front 12

What are the Quality Characteristics for requirements?

Back 12

Cohesive
Complete
Consistent
Correct
Modifiable
Unambiguous
Feasible
Testable

Hint 12

CCCC MUFT (A good mnemonic is to chant)

Front 13

What are the major types of requirements?

Back 13

Business Requirements
Stakeholder Requirements
Functional Requirements
Non-functional requirements
Transition Requirements

Hint 13

BSFNT “Bake Some Fun New Treats”

Front 14

What are the types of Functional requirements?

Back 14

Text, Matrices, Diagrams, Models

Hint 14

TMDM (Too Many Diagrams Mister)

Front 15

What are the types of Non-Functional requirements?

Back 15

Performance Efficiency, Reliability, Maintainability, Compatibility, Operability, Security, Transferability

Hint 15

PERM COST “There is a PERManent COST to non-functional requirements.”

Front 16

Modeling concepts for analysis.

Back 16

Processes, User Classes/Profiles/ Roles, Rules, Entities and Relationships, Events

Hint 16

PUREE “Models PUREE your requirements “

Front 17

What are the 11 analysis techniques in Requirements Analysis Knowledge Area

Back 17

Business Rules Analysis
User Stories
Data Flow Diagrams
Data Dictionary and Glossary
Data Modeling
Process Modeling
Scenarios and Use Cases
Non-functional Requirements Analysis
Scope Modeling
Sequence Diagrams
State Diagrams

Hint 17

BUD3 PUNS3

Front 18

Text documentation written by clients that describes process requirements for systems at a high, narrative level.
a. User Stories
b. Use Cases and Scenarios
c. Process Models
d. Sequence Diagrams

Back 18

a. User Stories

Hint 18

User Stories are brief text statements that describe functional requirements at a high, narrative level. They focus on behavior requirements, as opposed to data or interface requirements. Their hallmark is that they are written by users to establish ownership over requirements, to facilitate communication, and to encourage participation.

Front 19

UML diagrams showing the interactions and messages exchanged between objects in a system.
a. User Stories
b. Use Cases and Scenarios
c. Process Models
d. Sequence Diagrams

Back 19

d. Sequence Diagrams

Hint 19

Sequence diagrams are UML (Unified Modeling Language) diagrams that show the interactions between objects in a system. An object is a specific instance of a class. The diagram name derives from the sequence of logic and message flow (i.e., interaction) that occurs to carry out a scenario. They don't show how the objects structurally relate to each other, which is done through Class Diagrams, Along with Activity Diagrams, they are useful to visually model use cases and scenarios.

Front 20

Visually depicting the boundaries or functionality included in a system, using context diagrams, use case diagrams, etc.
a. Business Rules Analysis
b. Scope Modeling
c. Data Flow Diagrams
d. Data Modeling

Back 20

b. Scope Modeling

Hint 20

Scope modeling is a technique to visually depict a solution's scope. It typically shows a system, some high-level functionality, and the stakeholders (people, other systems, or events) who interact with it. Scope models can help early on in a project to help graphically show the scope of a solution and/or project work. They clearly show the boundaries of the scope and are good at engaging multiple audiences.

Front 21

Processes are shown in context of the data that moves into, out of, and is stored by the system.
a. Business Rules Analysis
b. Scope Modeling
c. Data Flow Diagrams
d. Data Modeling

Back 21

c. Data Flow Diagrams

Hint 21

Data Flow Diagrams (DFDs for short) are described in the BABOK as "data centric" although they have a heavy process component, also. The processes are shown in context of the data that flows into, out of, and is stored: by the system. Like process maps and data models, these diagrams were created to show what the business does with its processes and data, and to document requirements for a system.

Front 22

Depicts the various phases which an entity flows through during its lifetime. It also shows the transitions to move an entity between phases.
a. Data Flow Diagrams
b. State Diagrams
c. Process Models
d. Sequence Diagrams

Back 22

b. State Diagrams

Hint 22

State Diagrams depict the various states which an entity or class flows through during its lifetime (i.e., from creation to deletion). It also shows the events or triggers that prompt from one state to another, and formally labels the transitions. This type of analysis applies to complex entities with multiple states or "life cycles." They can help discover missing data attributes and processes involved in the various transitions.

Front 23

Operating principles or self-imposed constraints that apply across all projects and systems, documented with text, tables, or decision trees.
a. Business Rules Analysis
b. Scope Modeling
c. Data Flow Diagrams
d. Data Modeling

Back 23

a. Business Rules Analysis

Hint 23

Business rules are oper~ting principles or self-imposed constraints that apply across all projects and systems. They constrain, define, or enable the organization to function. They are specific, actionable, and testable (vs. policies, which support goals, but are non-actionable). Business rules are also atomic (i.e., can't be broken down further) and are independent of anyone process. They should be uniquely identified and documented independently of their enforcement. They are maintained to allow change and adaptation as the business changes.

Front 24

Determining enviromnental qualities or conditions under which the solution must operate.
a. Business Rules Analysis
b. Process Models
c. Data Flow Diagrams
d. Non-Functional

Back 24

d. Non-Functional

Hint 24

Non-functional Requirements are environmental conditions or qualities under which the solution must remain effective. They complement the behavior or functionality of the solution.

Front 25

Visually documents data requirements and business rules through a combination of structures, associations, and attributes.
a. Data Flow Diagrams
b. Data Modeling
c. Process Models
d. Sequence Diagrams

Back 25

b. Data Modeling

Hint 25

Data Models are a combination of diagram and text that describes the data requirements for a solution. The chief diagrams are Entity Relationship Diagrams (ERDs) and class diagrams.

Front 26

Written descriptions that detail the interactions between actors and a system.
a. User Stories
b. Use Cases and Scenarios
c. Process Models
d. Sequence Diagrams

Back 26

b. Use Cases and Scenarios

Hint 26

Use Case Model is a model that combines 1) a graphical system overview showing actors, use cases, and their interfaces, and 2) written narratives that detail the interactions between actors and the system.

Front 27

Shows high-level data and defmitions used by a business, to foster communication between the business and project teams.
a. Data Flow Diagrams
b. Data Modeling
c. Data Dictionary and Glossary
d. Business Rules Analysis

Back 27

c. Data Dictionary and Glossary

Hint 27

Data Dictionaries are a basic type of requirements documentation, showing high-level data needed for a business. They may be recorded using simple tools like word processors, or more elaborate modeling tools. In general, they are used to foster communication between the business and project team. Also used for supplemental data documentation, data dictionaries are typically refilled into more detailed data models.

Front 28

Visual representation of workflow, including who does it, how they collaborate, and what decisions are made.
a. Use Cases and Scenarios
b. Sequence Diagrams
c. Data Flow Diagrams
d. Process Models

Back 28

d. Process Models

Hint 28

Process Modeling is a technique for visually documenting work performed in an organization, including who does it and how they collaborate. Useful for many aspects of analysis.