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 degree to which a set of inherent characteristics fulfills requirements.






2. A stakeholder who provides products or services to an organization.






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






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






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






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






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






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






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






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






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






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






13. The business benefits that will result from meeting the business need and the end state desired by stakeholders.






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






15. A validation technique in which a small group of stakeholders evaluates a portion of a work product to find errors to improve its quality.






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






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






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






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






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






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






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






23. The number of employees a manger is directly (or indirectly) responsible for.






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






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






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






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






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






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






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






31. A person with specific expertise in an area or domain under investigation.






32. A requirements document written for a user audience describing user requirements and the impact of the anticipated changes on the users.






33. Requirements that have been demonstrated to deliver business value and to support the business goals and objectives.






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






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






36. A higher level business rationale that when addressed will permit the organization to increase revenue avoid costs improve service or meet regulatory requirements.






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






38. Analysis done to compare and quantify the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.






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






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






41. Influencing factors that are believed to be true but have not been confirmed to be accurate.






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






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






44. The problem area undergoing analysis.






45. A system of programming statements symbols and rules used to represent instructions to a computer.






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






47. A temporary endeavor undertaken to create a unique product service or result.






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






49. Meets a business need by resolving a problem or allowing an organization to take advantage of an opportunity.






50. An analysis model that depicts the logical structure of data independent of the data design or data storage mechanisms.