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






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






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






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






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






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






7. The product capabilities or things the product must do for its users.






8. The activities that control requirements development including requirements change control requirements attributes definition and requirements traceability.






9. A document or collection of notes or diagrams used by the business analyst during the requirements development process.






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






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






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






13. Software developed and sold for a particular market.






14. Limitations on the design of a solution that derive from the technology used in its implementation.






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






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






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






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






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






20. An autonomous unit within an enterprise under the management of a single individual or board with a clearly defined boundary that works towards common goals and objectives. Operate on a continuous basis as opposed to an organizational unit or project






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






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






23. A systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.






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






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






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






27. The human and nonhuman roles that interact with the system.






28. The analysis technique used to describe roles responsibilities and reporting structures that exist within an organization.






29. A model that defines the boundaries of a business domain or solution.






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






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






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






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






34. A requirements document written primarily for Implementation SMEs describing functional and nonfunctional requirements.






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






36. Requirements that have been demonstrated to deliver business value and to support the business goals and objectives.






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






38. A stakeholder who will be responsible for designing developing and implementing the change described in the requirements and have specialized knowledge regarding the construction of one or more solution components.






39. A system of programming statements symbols and rules used to represent instructions to a computer.






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






41. Any effort undertaken with a defined goal or objective.






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






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






44. An analysis model that shows user interface dialogs arranged as hierarchies.






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






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






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






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






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






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