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 non-actionable directive that supports a business goal.






2. A defined association between concepts classes or entities. Usually named and include the cardinality of the association.






3. A practitioner of business analysis.






4. A measure of the profitability of a project or investment.






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






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






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






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






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






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






11. The subset of nonfunctional requirements that describes properties of the software's operation development and deployment (e.g. performance security usability portability and testability).






12. A generic name for a role with the responsibilities of developing and managing requirements. Other names include business analyst business integrator requirements analyst requirements engineer and systems analyst.






13. A requirement articulated by a stakeholder that has not been analyzed verified or validated. Frequently reflect the desires of a stakeholder rather than the actual need.






14. A specific actionable testable directive that is under the control of the business and supports a business policy.






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






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






17. Software developed and sold for a particular market.






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






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






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






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






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






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






24. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.






25. A prototype developed to explore or verify requirements.






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. The process of examining new business opportunities to improve organizational performance.






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






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






30. A description of the requirements management process.






31. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.






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






33. A matrix used to track requirements' relationships. Each column in the matrix provides requirements information and associated project or software development components.






34. An analysis model that specifies complex business rules or logic concisely in an easy-to-read tabular format specifying all of the possible conditions and actions that need to be accounted for in business rules.






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






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






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






38. A group of related tasks that support a key function of business analysis.






39. A point-in-time view of requirements that have been reviewed and agreed upon to serve as a basis for further development.






40. A deficiency in a product or service that reduces its quality or varies from a desired attribute state or functionality.






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






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






43. A structured process which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.






44. Something that occurs to which an organizational unit system or process must respond.






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






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






47. Any unique and verifiable work product or service that a party has agreed to deliver.






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






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






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