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. The set of capabilities a solution must deliver in order to meet the business need.






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






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






4. Statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Serve as a bridge between business requirements and the various






5. A list and definition of the business terms and concepts relevant to the solution being built or enhanced.






6. A system trigger that is initiated by humans.






7. A non-proprietary modeling and specification language used to specify visualize and document deliverables for object-oriented software-intensive systems.






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






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






10. A data element with a specified data type that describes information associated with a concept or entity.






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






12. A practitioner of business analysis.






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






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






15. A prototype developed to explore or verify requirements.






16. A group or person who has interests that may be affected by an initiative or influence over it.






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






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






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






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






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






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






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






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






25. An uncertain event or condition that if it occurs will affect the goals or objectives of a proposed change.






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






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






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






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






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






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






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






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






34. A model that defines the boundaries of a business domain or solution.






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






36. A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization. Are triggered by events and may have multiple possible outcomes. A successful outcome of a process will deliver value to one or more s






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






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






39. The process of apportioning requirements to subsystems and components (i.e. people hardware and software).






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






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






42. A stakeholder with legal or governance authority over the solution or the process used to develop it.






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






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






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






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






47. Software developed and sold for a particular market.






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






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






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