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 partial or preliminary version of the system.






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






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






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






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






6. A requirements workshop is a structured meeting in which a carefully selected group of stakeholders collaborate to define and or refine requirements under the guidance of a skilled neutral facilitator.






7. Formal approval of a set of requirements by a sponsor or other decision maker.






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






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






10. A process improvement technique used to learn about and improve on a process or project. Involves a special meeting in which the team explores what worked what didn't work what could be learned from the just-completed iteration and how to adapt proce






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






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






13. A brief statement or paragraph that describes the why what and who of the desired software product from a business point of view.






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






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






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






17. An analysis model showing the life cycle of a data entity or class.






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






19. An approach to decision-making that examines and models the possible consequences of different decisions. Assists in making an optimal decision under conditions of uncertainty.






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






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






22. A brief statement or paragraph that describes the problems in the current state and clarifies what a successful solution will look like.






23. A practitioner of business analysis.






24. A business model that shows a business process in terms of the steps and input and output flows across multiple functions organizations or job roles.






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






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






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






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






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






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






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






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






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






34. A stakeholder with specific expertise in an aspect of the problem domain or potential solution alternatives or components.






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






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






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






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






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






40. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract standard specification or other formally imposed documents.






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






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






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






44. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive complete consistent correct feasible modifiable unambiguous and testable.






45. A set of requirements grouped together in a document or presentation for communication to stakeholders.






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






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






48. Interfaces with other systems (hardware software and human) that a proposed system will interact with.






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






50. The features and functions that characterize a product service or result.