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 analysis model that illustrates the architecture of the system's user interface.






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






3. A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.






4. The product capabilities or things the product must do for its users.






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






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






7. The process of examining new business opportunities to improve organizational performance.






8. A practitioner of business analysis.






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






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






11. Metadata related to a requirement used to assist with requirements development and management.






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






13. A person with specific expertise in an area or domain under investigation.






14. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.






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






16. A stakeholder who helps to keep the solution functioning either by providing support to end users (trainers help desk) or by keeping the solution operational on a day-to-day basis (network and other tech support).






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






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






19. Creating working software in multiple releases so the entire product is delivered in portions over time.






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






21. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract standard specification or other formally imposed documents.






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






23. A prototype that is continuously modified and updated in response to feedback from users.






24. A collection of interrelated elements that interact to achieve an objective. Elements can include hardware software and people.






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






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






27. A prototype developed to explore or verify requirements.






28. A graphical representation of the entities relevant to a chosen problem domain the relationships between them and their attributes.






29. An autonomous unit within an enterprise under the management of a single individual or board with a clearly defined boundary that works towards common goals and objectives. Operate on a continuous basis as opposed to an organizational unit or project






30. Formal approval of a set of requirements by a sponsor or other decision maker.






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






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






33. A list and definition of the business terms and concepts relevant to the solution being built or enhanced.






34. A process improvement technique used to learn about and improve on a process or project. Involves a special meeting in which the team explores what worked what didn't work what could be learned from the just-completed iteration and how to adapt proce






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






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






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






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






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






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






42. Software developed and sold for a particular market.






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






44. The work to identify the stakeholders who may be impacted by a proposed initiative and assess their interests and likely participation.






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






46. A description of the requirements management process.






47. A means to elicit requirements of an existing system by studying available documentation and identifying relevant information.






48. Work carried out or on behalf of others.






49. A non-actionable directive that supports a business goal.






50. A small group of stakeholders who will make decisions regarding the disposition and treatment of changing requirements.