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. The set of capabilities a solution must deliver in order to meet the business need.






2. The process of determining the relative importance of a set of items in order to determine the order in which they will be addressed.






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






4. A real or virtual facility where all information on a specific topic is stored and is available for retrieval.






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. A business model that shows the organizational context in terms of the relationships that exist among the organization external customers and providers.






7. A practitioner of business analysis.






8. A requirements document written primarily for Implementation SMEs describing functional and nonfunctional requirements.






9. A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization. Are triggered by events and may have multiple possible outcomes. A successful outcome of a process will deliver value to one or more s






10. A validation technique in which a small group of stakeholders evaluates a portion of a work product to find errors to improve its quality.






11. Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results.






12. An analysis model that shows user interface dialogs arranged as hierarchies.






13. A measure of the profitability of a project or investment.






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






15. An error in requirements caused by incorrect incomplete missing or conflicting requirements.






16. All materials used by groups within an organization to define tailor implement and maintain their processes.






17. 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.






18. A type of data model that depicts information groups as classes.






19. A set of processes rules templates and working methods that prescribe how business analysis solution development and implementation is performed in a particular context.






20. A conceptual view of all or part of an enterprise focusing on products deliverables and events that are important to the mission of the organization. Is useful to validate the solution scope with the business and technical stakeholders. See also mode






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






22. 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.






23. A set of requirements grouped together in a document or presentation for communication to stakeholders.






24. Determine when something is or is not true or when things fall into a certain category. They describe categorizations that may change over time.






25. The human and nonhuman roles that interact with the system.






26. A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.






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






28. A requirements package that describes business requirements and stakeholder requirements (it documents requirements of interest to the business rather than documenting business requirements).






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






30. Activities performed to ensure that a process will deliver products that meet an appropriate level of quality.






31. Limitations on the design of a solution that derive from the technology used in its implementation.






32. A temporary endeavor undertaken to create a unique product service or result.






33. The activities that control requirements development including requirements change control requirements attributes definition and requirements traceability.






34. The process of checking a product to ensure that it satisfies its intended use and conforms to its requirements. Ensures that you built the correct solution.






35. The process of checking that a deliverable produced at a given stage of development satisfies the conditions or specifications of the previous stage. Ensures that you built the solution correctly.






36. An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way.






37. A deficiency in a product or service that reduces its quality or varies from a desired attribute state or functionality.






38. 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.






39. A person or system that directly interacts with the solution. Can be humans who interface with the system or systems that send or receive data files to or from the system.






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






41. A comparison of a process or system's cost time quality or other metrics to those of leading peer organizations to identify opportunities for improvement.






42. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive complete consistent correct feasible modifiable unambiguous and testable.






43. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.






44. The degree to which a set of inherent characteristics fulfills requirements.






45. A prototype that shows a shallow and possibly wide view of the system's functionality but which does not generally support any actual use or interaction.






46. Assesses the effects that a proposed change will have on a stakeholder or stakeholder group project or system.






47. A group of related information to be stored by the system. Can be people roles places things organizations occurrences in time concepts or documents.






48. An analysis model that specifies complex business rules or logic concisely in an easy-to-read tabular format specifying all of the possible conditions and actions that need to be accounted for in business rules.






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






50. A stakeholder responsible for assessing the quality of and identifying defects in a software application.