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. A stakeholder with legal or governance authority over the solution or the process used to develop it.






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






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






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






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






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






7. A classification of requirements that describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state but that will not be needed once that transition is complet






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






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






10. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.






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






12. An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one a






13. A practitioner of business analysis.






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






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






16. An analysis model showing the life cycle of a data entity or class.






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






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






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






20. An informal solicitation of proposals from vendors.






21. A system trigger that is initiated by humans.






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






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






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






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






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






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






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






29. The process of apportioning requirements to subsystems and components (i.e. people hardware and software).






30. Software requirements that limit the options available to the system designer.






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






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






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






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






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






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






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






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






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






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






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






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






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






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






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






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






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






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






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






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