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






2. Identifies a specific numerical measurement that indicates progress toward achieving an impact output activity or input. See also metric.






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






4. The work that must be performed to deliver a product service or result with the specified features and functions.






5. A means to elicit requirements by conducting an assessment of the stakeholder's work environment.






6. An approach to decision-making that examines and models the possible consequences of different decisions. Assists in making an optimal decision under conditions of uncertainty.






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






8. Information that is used to understand the context and validity of information recorded in a system.






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






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






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






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






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






14. A type of diagram that shows objects participating in interactions and the messages exchanged between them.






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






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






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






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






19. A stakeholder who uses products or services delivered by an organization.






20. The set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure policies and operations of an organization and recommend solutions that enable the organization to achieve its goals.






21. An analysis model in table format that defines the events (i.e. the input stimuli that trigger the system to carry out some function) and their responses.






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






23. Interfaces with other systems (hardware software and human) that a proposed system will interact with.






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






25. Tests written without regard to how the software is implemented. These tests show only what the expected input and outputs will be.






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






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






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






29. The number of employees a manger is directly (or indirectly) responsible for.






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






31. A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.






32. A target or metric that a person or organization seeks to meet in order to progress towards a goal.






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






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






35. A stakeholder with specific expertise in an aspect of the problem domain or potential solution alternatives or components.






36. An actor who participates in but does not initiate a use case.






37. A set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time.






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






39. A representation of requirements using text and diagrams. Can also be called user requirements models or analysis models and can supplement textual requirements specifications.






40. The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the desig






41. Any effort undertaken with a defined goal or objective.






42. A system of programming statements symbols and rules used to represent instructions to a computer.






43. The business rules an organization chooses to enforce as a matter of policy. They are intended to guide the actions of people working within the business. They may oblige people to take certain actions prevent people from taking actions or prescribe






44. A formal type of peer review that utilizes a predefined and documented process specific participant roles and the capture of defect and process metrics. See also structured walkthrough.






45. An assessment of the costs and benefits associated with a proposed initiative.






46. A description of the planned activities that the business analyst will execute in order to perform the business analysis work involved in a specific initiative.






47. The analysis technique used to describe roles responsibilities and reporting structures that exist within an organization.






48. A data element with a specified data type that describes information associated with a concept or entity.






49. A requirements document written for a user audience describing user requirements and the impact of the anticipated changes on the users.






50. An assessment that describes whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively.