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. An analysis model that shows user interface dialogs arranged as hierarchies.






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






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






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






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






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






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






8. Describes any limitations imposed on the solution that do not support the business or stakeholder needs.






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






10. A system trigger that is initiated by time.






11. A person with specific expertise in an area or domain under investigation.






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






13. Defining whether or not a relationship between entities in a data model is mandatory. Is shown on a data model with a special notation.






14. An uncertain event or condition that if it occurs will affect the goals or objectives of a proposed change.






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






16. An analysis model describing the data structures and attributes needed by the system.






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






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






19. A prototype developed to explore or verify requirements.






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






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






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






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






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






25. Software developed and sold for a particular market.






26. A type of diagram defined by UML that captures all actors and use cases involved with a system or product.






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






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






29. A system trigger that is initiated by humans.






30. A type of diagram that shows objects participating in interactions and the messages exchanged between them.






31. A set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time.






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






33. A representation and simplification of reality developed to convey information to a specific audience to support analysis communication and understanding.






34. A set of user stories requirements or features that have been identified as candidates for potential implementation prioritized and estimated.






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






36. All materials used by groups within an organization to define tailor implement and maintain their processes.






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






38. The number of occurrences of one entity in a data model that are linked to a second entity. Is shown on a data model with a special notation number (e.g. 1) or letter (e.g. M for many).






39. A diagramming technique used in root cause analysis to identify underlying causes of an observed problem and the relationships that exist between those causes.






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






41. The process of checking that a deliverable produced at a given stage of development satisfies the conditions or specifications of the previous stage. Ensures that you built the solution correctly.






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






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






44. Are responsible for the construction of software applications. Areas of expertise include development languages development practices and application components.






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






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






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






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






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






50. Identifies a specific numerical measurement that indicates progress toward achieving an impact output activity or input. See also metric.