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 characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.






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






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






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






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






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






8. A classification of requirements that describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state but that will not be needed once that transition is complet






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






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






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






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






14. A representation and simplification of reality developed to convey information to a specific audience to support analysis communication and understanding.






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






16. Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.






17. A means to elicit requirements by conducting an assessment of the stakeholder's work environment.






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






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






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






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






22. A system trigger that is initiated by humans.






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






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






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






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






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






28. An error in requirements caused by incorrect incomplete missing or conflicting requirements.






29. A link between two elements or objects in a diagram.






30. A stakeholder responsible for assessing the quality of and identifying defects in a software application.






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






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






33. A diagramming technique used in root cause analysis to identify underlying causes of an observed problem and the relationships that exist between those causes.






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






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






36. A requirements document issued when an organization is seeking a formal proposal from vendors. Typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation m






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






38. A type of diagram defined by UML that captures all actors and use cases involved with a system or product.






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






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






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






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






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






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






45. A type of high-level business requirement that is a statement of a business objective or an impact the solution should have on its environment.






46. A collection of interrelated elements that interact to achieve an objective. Elements can include hardware software and people.






47. A group of related information to be stored by the system. Can be people roles places things organizations occurrences in time concepts or documents.






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






49. Software developed and sold for a particular market.






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