Test your basic knowledge |

  • 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. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.

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

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

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

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

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

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

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

9. A fixed period of time to accomplish a desired outcome.

10. A high-level informal short description of a solution capability that provides value to a stakeholder. Is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to impleme

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

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

13. Software developed and sold for a particular market.

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

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

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

17. A prototype developed to explore or verify requirements.

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

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

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

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

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

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

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

25. A higher level business rationale that when addressed will permit the organization to increase revenue avoid costs improve service or meet regulatory requirements.

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

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

28. A system trigger that is initiated by humans.

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

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

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

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

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

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

35. A model that defines the boundaries of a business domain or solution.

36. A cohesive bundle of externally visible functionality that should align with business goals and objectives. Each is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.

37. A subset of the enterprise architecture that defines an organization's current and future state including its strategy its goals and objectives the internal environment through a process or functional view the external environment in which the busine

38. An analysis model that illustrates processes that occur along with the flows of data to and from those processes.

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

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

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

42. A prototype used to quickly uncover and clarify interface requirements using simple tools sometimes just paper and pencil. Usually discarded when the final system has been developed.

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

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

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

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

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

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

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

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