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 defined association between concepts classes or entities. Usually named and include the cardinality of the association.






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






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






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






5. The process of checking a product to ensure that it satisfies its intended use and conforms to its requirements. Ensures that you built the correct solution.






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






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






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






9. Alter the way a business analysis task is performed or describe a specific form the output of a task may take.






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






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






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






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






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






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






16. The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.






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






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






19. A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.






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






21. An informal solicitation of proposals from vendors.






22. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.






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






24. The process of determining the relative importance of a set of items in order to determine the order in which they will be addressed.






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






26. A prototype developed to explore or verify requirements.






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






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






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






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






31. An evaluation of proposed alternatives to determine if they are technically possible within the constraints of the organization and whether they will deliver the desired benefits to the organization.






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






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






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






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






36. A high-level informal short description of a solution capability that provides value to a stakeholder. Is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to impleme






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






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






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






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






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






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






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






44. A function of an organization that enables it to achieve a business goal or objective.






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






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






47. Creating working software in multiple releases so the entire product is delivered in portions over time.






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






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






50. A set of processes rules templates and working methods that prescribe how business analysis solution development and implementation is performed in a particular context.