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 business model that shows the organizational context in terms of the relationships that exist among the organization external customers and providers.






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






3. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.






4. A conceptual view of all or part of an enterprise focusing on products deliverables and events that are important to the mission of the organization. Is useful to validate the solution scope with the business and technical stakeholders. See also mode






5. The work that must be performed to deliver a product service or result with the specified features and functions.






6. An analysis model in table format that defines the events (i.e. the input stimuli that trigger the system to carry out some function) and their responses.






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






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






9. A type of high-level business requirement that is a statement of a business objective or an impact the solution should have on its environment.






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






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






12. A data element with a specified data type that describes information associated with a concept or entity.






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






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






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






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






17. A prototype that dives into the details of the interface functionality or both.






18. The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role.






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






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






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






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






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






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






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






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






27. A target or metric that a person or organization seeks to meet in order to progress towards a goal.






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






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






30. An informal solicitation of proposals from vendors.






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






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






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






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






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






36. A system trigger that is initiated by time.






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






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






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






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






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






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






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






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






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






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






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






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






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






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