Test your basic knowledge |

Instructions:
  • Answer 50 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. An assessment that describes whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively.






2. A use case composed of a common set of steps used by multiple use cases.






3. An analysis model that depicts the logical structure of data independent of the data design or data storage mechanisms.






4. A business model that shows a business process in terms of the steps and input and output flows across multiple functions organizations or job roles.






5. A descriptor for a set of system objects that share the same attributes operations relationships and behavior. Represents a concept in the system under design. When used as an analysis model a class will generally also correspond to a real-world enti






6. Software developed and sold for a particular market.






7. A solution or component of a solution that is the result of a project.






8. A model that illustrates the flow of processes and/or complex use cases by showing each activity along with information flows and concurrent activities. Steps can be superimposed onto horizontal swimlanes for the roles that perform the steps.






9. A stakeholder with legal or governance authority over the solution or the process used to develop it.






10. A requirements document issued to solicit vendor input on a proposed process or product. Is used when the issuing organization seeks to compare different alternatives or is uncertain regarding the available options






11. Software requirements that limit the options available to the system designer.






12. A type of high-level business requirement that is a statement of a business objective or an impact the solution should have on its environment.






13. A document or collection of notes or diagrams used by the business analyst during the requirements development process.






14. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.






15. A quality control technique. They may include a standard set of quality elements that reviewers use for requirements verification and requirements validation or be specifically developed to capture issues of concern to the project.






16. An analysis model that illustrates the architecture of the system's user interface.






17. An analysis model that provides a graphical alternative to decision tables by illustrating conditions and actions in sequence.






18. A description of the types of communication the business analyst will perform during business analysis the recipients of those communications and the form in which communication should occur.






19. A diagramming technique used in root cause analysis to identify underlying causes of an observed problem and the relationships that exist between those causes.






20. A system trigger that is initiated by time.






21. A structured examination of an identified problem to understand the underlying causes.






22. An informal solicitation of proposals from vendors.






23. A continuous process of collecting data to determine how well a solution is implemented compared to expected results. See also metric and indicator.






24. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.






25. An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.






26. An activity within requirements development that identifies sources for requirements and then uses elicitation techniques (e.g. interviews prototypes facilitated workshops documentation studies) to gather requirements from those sources.






27. A practitioner of business analysis.






28. A stakeholder who provides products or services to an organization.






29. The ability to identify and document the lineage of each requirement including its derivation (backward traceability) its allocation (forward traceability) and its relationship to other requirements.






30. A quantifiable level of an indicator that an organization wants to accomplish at a specific point in time.






31. The set of processes templates and activities that will be used to perform business analysis in a specific context.






32. A description of an organization's business processes IT software and hardware people operations and projects and the relationships between them.






33. An analysis model that describes a series of actions or tasks that respond to an event. Each is an instance of a use case.






34. Roles and Responsibility DesignationA listing of the stakeholders affected by a business need or proposed solution and a description of their participation in a project or other initiative.






35. The number of occurrences of one entity in a data model that are linked to a second entity. Is shown on a data model with a special notation number (e.g. 1) or letter (e.g. M for many).






36. An iteration that defines requirements for a subset of the solution scope. Would include identifying a part of the overall product scope to focus upon identifying requirements sources for that portion of the product analyzing stakeholders and plannin






37. A stakeholder who will be responsible for designing developing and implementing the change described in the requirements and have specialized knowledge regarding the construction of one or more solution components.






38. Limitations placed on the solution design by the organization that needs the solution. Describe limitations on available solutions or an aspect of the current state that cannot be changed by the deployment of the new solution. See also technical cons






39. A systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.






40. A type of peer review in which participants present discuss and step through a work product to find errors. Are used to verify the correctness of requirements.






41. A brief statement or paragraph that describes the problems in the current state and clarifies what a successful solution will look like.






42. A process in which a deliverable (or the solution overall) is progressively elaborated upon. Will result in a self-contained "mini-project" in which a set of activities are undertaken resulting in the development of a subset of project deliverables.






43. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.






44. An organized peer review of a deliverable with the objective of finding errors and omissions. It is considered a form of quality assurance.






45. Alter the way a business analysis task is performed or describe a specific form the output of a task may take.






46. A means to elicit ideas and attitudes about a specific product service or opportunity in an interactive group environment. The participants share their impressions preferences and needs guided by a moderator.






47. Ability of systems to communicate by exchanging data or services.






48. A group or person who has interests that may be affected by an initiative or influence over it.






49. Defining whether or not a relationship between entities in a data model is mandatory. Is shown on a data model with a special notation.






50. The work done to ensure that the stated requirements support and are aligned with the goals and objectives of the business.