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. Analysis done to compare and quantify the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.






2. A function of an organization that enables it to achieve a business goal or objective.






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






4. The quality attributes design and implementation constraints and external interfaces that the product must have.






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






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






7. A brief statement or paragraph that describes the why what and who of the desired software product from a business point of view.






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






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






10. A state or condition the business must satisfy to reach its vision.






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






12. Meets a business need by resolving a problem or allowing an organization to take advantage of an opportunity.






13. A prototype developed to explore or verify requirements.






14. Any recognized association of people in the context of an organization or enterprise.






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






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






17. A shared boundary between any two persons and/or systems through which information is communicated.






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






19. The business benefits that will result from meeting the business need and the end state desired by stakeholders.






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






21. An organizational unit organization or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.






22. Strengths Weaknesses Opportunities and Threats. It is a model used to understand influencing factors and how they may affect an initiative.






23. The area covered by a particular activity or topic of interest.






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






25. The problem area undergoing analysis.






26. An informal solicitation of proposals from vendors.






27. A representation and simplification of reality developed to convey information to a specific audience to support analysis communication and understanding.






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






29. An evaluation of proposed alternatives to determine if they are technically possible within the constraints of the organization and whether they will deliver the desired benefits to the organization.






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






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






32. A business model that shows the organizational context in terms of the relationships that exist among the organization external customers and providers.






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






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






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






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






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






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






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






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






41. A non-proprietary modeling and specification language used to specify visualize and document deliverables for object-oriented software-intensive systems.






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






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






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






45. A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.






46. Work carried out or on behalf of others.






47. A link between two elements or objects in a diagram.






48. A requirements workshop is a structured meeting in which a carefully selected group of stakeholders collaborate to define and or refine requirements under the guidance of a skilled neutral facilitator.






49. A comparison of the current state and desired future state of an organization in order to identify differences that need to be addressed.






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