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 group of related information to be stored by the system. Can be people roles places things organizations occurrences in time concepts or documents.






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






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






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






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






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






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






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






9. A solution or component of a solution that is the result of a project.






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






11. A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.






12. A stakeholder person device or system that directly or indirectly accesses a system.






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






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






15. Work carried out or on behalf of others.






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






17. A system trigger that is initiated by time.






18. An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.






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






20. A description of the requirements management process.






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






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






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






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






25. An analysis model that describes a series of actions or tasks that respond to an event. Each is an instance of a use case.






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






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






28. The work done to ensure that the stated requirements support and are aligned with the goals and objectives of the business.






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






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






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






32. Influencing factors that are believed to be true but have not been confirmed to be accurate.






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






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






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






36. A type of data model that depicts information groups as classes.






37. The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the desig






38. A requirements document issued when an organization is seeking a formal proposal from vendors. Typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation m






39. Statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Serve as a bridge between business requirements and the various






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






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






42. A prototype developed to explore or verify requirements.






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






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






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






46. A description of the planned activities that the business analyst will execute in order to perform the business analysis work involved in a specific initiative.






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






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






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






50. An assessment of the costs and benefits associated with a proposed initiative.