Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key

image

Play button

image

Play button

image

Progress

1/28

Click to flip

28 Cards in this Set

  • Front
  • Back
  • 3rd side (hint)
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.
a. Include.
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.
Associations (interfaces) in a Use Case diagram are shown through:
a. Stick figures.
b. Ovals.
c. Arrows.
d. Lines.
d. Lines.
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.
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.
c. Business domain SME after translating the model into text.
They are responsible for verifying and validating the
requirements. BABOK 6.3.6.
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.
c. List of quality improvements required.
From the BABOK9.30.3.2.
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.
d. Data modeling and business process modeling.
Both of these techniques help discover exception handling and required edits.
BABOK 9.7.3 and 9.21.3.
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.
d. Text, Matrix, Diagrams, Models.
Formats for specifying requirements. Functional requirements can be expressed using these formats. BABOK 6.3.1, 6.4.3.1.
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.
a. Metrics, Prototyping, Structured Walkthroughs.
BABOK 6.6.5.
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.
b. Verifying the requirement.
BABOK 6.5.1.
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.
c. Use Case Description.
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.
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.
a. Document the related business rules in text form as supplemental documentation.
BABOK Section 9.7.2. Also, in describing business rules, Section 9.4.3, the BABOK refers to data modeling (9.7).
What are the Tasks in Analyzing Requirements?
Prioritize Requirements
Organize Requirements
Specify and Model Requirements
Define Assumptions and Constraints
Verify Quality of Requirements
Validate Requirements
POMA VV (POMA Apples and Valid and Verified)
What are the Quality Characteristics for requirements?
Cohesive
Complete
Consistent
Correct
Modifiable
Unambiguous
Feasible
Testable
CCCC MUFT (A good mnemonic is to chant)
What are the major types of requirements?
Business Requirements
Stakeholder Requirements
Functional Requirements
Non-functional requirements
Transition Requirements
BSFNT “Bake Some Fun New Treats”
What are the types of Functional requirements?
Text, Matrices, Diagrams, Models
TMDM (Too Many Diagrams Mister)
What are the types of Non-Functional requirements?
Performance Efficiency, Reliability, Maintainability, Compatibility, Operability, Security, Transferability
PERM COST “There is a PERManent COST to non-functional requirements.”
Modeling concepts for analysis.
Processes, User Classes/Profiles/ Roles, Rules, Entities and Relationships, Events
PUREE “Models PUREE your requirements “
What are the 11 analysis techniques in Requirements Analysis Knowledge Area
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
BUD3 PUNS3
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
a. User Stories
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.
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
d. Sequence Diagrams
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.
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
b. Scope Modeling
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.
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
c. Data Flow Diagrams
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.
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
b. State Diagrams
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.
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
a. Business Rules Analysis
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.
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
d. Non-Functional
Non-functional Requirements are environmental conditions or qualities under which the solution must remain effective. They complement the behavior or functionality of the solution.
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
b. Data Modeling
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.
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
b. Use Cases and Scenarios
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.
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
c. Data Dictionary and Glossary
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.
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
d. Process Models
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.