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 non-proprietary modeling and specification language used to specify visualize and document deliverables for object-oriented software-intensive systems.






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






3. A comparison of the current state and desired future state of an organization in order to identify differences that need to be addressed.






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






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






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






7. Work carried out or on behalf of others.






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






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






10. A partial or preliminary version of the system.






11. A comparison of a process or system's cost time quality or other metrics to those of leading peer organizations to identify opportunities for improvement.






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






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






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






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






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






17. Roles and Responsibility DesignationA listing of the stakeholders affected by a business need or proposed solution and a description of their participation in a project or other initiative.






18. A stakeholder who uses products or services delivered by an organization.






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






20. A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.






21. A practitioner of business analysis.






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






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






24. The set of capabilities a solution must deliver in order to meet the business need.






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






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






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






28. A cohesive bundle of externally visible functionality that should align with business goals and objectives. Each is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.






29. A generic name for a role with the responsibilities of developing and managing requirements. Other names include business analyst business integrator requirements analyst requirements engineer and systems analyst.






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






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






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






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






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






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






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






37. Ability of systems to communicate by exchanging data or services.






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






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






40. The area covered by a particular activity or topic of interest.






41. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.






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






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






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






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






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






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






48. A means to elicit ideas and attitudes about a specific product service or opportunity in an interactive group environment. The participants share their impressions preferences and needs guided by a moderator.






49. An organizational unit organization or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.






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