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 uncertain event or condition that if it occurs will affect the goals or objectives of a proposed change.






2. A requirement articulated by a stakeholder that has not been analyzed verified or validated. Frequently reflect the desires of a stakeholder rather than the actual need.






3. A unit of work performed as part of an initiative or process.






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






5. A system trigger that is initiated by time.






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






7. A prototype developed to explore or verify requirements.






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






9. An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way.






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






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






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






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






14. An iteration that defines requirements for a subset of the solution scope. Would include identifying a part of the overall product scope to focus upon identifying requirements sources for that portion of the product analyzing stakeholders and plannin






15. A descriptor for a set of system objects that share the same attributes operations relationships and behavior. Represents a concept in the system under design. When used as an analysis model a class will generally also correspond to a real-world enti






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






17. The subset of nonfunctional requirements that describes properties of the software's operation development and deployment (e.g. performance security usability portability and testability).






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






19. The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time and to identify ways to improve the solution to better meet objectives. See also metric indicator and monitoring.






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






21. A quantifiable level of an indicator that an organization wants to accomplish at a specific point in time.






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






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






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






25. A prototype that shows a shallow and possibly wide view of the system's functionality but which does not generally support any actual use or interaction.






26. A use case composed of a common set of steps used by multiple use cases.






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






28. A point-in-time view of requirements that have been reviewed and agreed upon to serve as a basis for further development.






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






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






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






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






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






34. A partial or preliminary version of the system.






35. A practitioner of business analysis.






36. A type of peer review in which participants present discuss and step through a work product to find errors. Are used to verify the correctness of requirements.






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






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






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






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






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






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






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






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






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






46. An analysis model that illustrates the architecture of the system's user interface.






47. Strengths Weaknesses Opportunities and Threats. It is a model used to understand influencing factors and how they may affect an initiative.






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






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






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