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






2. Tests written without regard to how the software is implemented. These tests show only what the expected input and outputs will be.






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






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






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






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






7. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.






8. A formal type of peer review that utilizes a predefined and documented process specific participant roles and the capture of defect and process metrics. See also structured walkthrough.






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






10. Work carried out or on behalf of others.






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






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






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






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






15. A graphical representation of the entities relevant to a chosen problem domain the relationships between them and their attributes.






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






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






18. A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution's performance.






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






20. A system trigger that is initiated by time.






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






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






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






24. The process of examining new business opportunities to improve organizational performance.






25. Software developed and sold for a particular market.






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






27. A small group of stakeholders who will make decisions regarding the disposition and treatment of changing requirements.






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






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






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






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






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






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






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






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






36. A specific actionable testable directive that is under the control of the business and supports a business policy.






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






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






39. A set of user stories requirements or features that have been identified as candidates for potential implementation prioritized and estimated.






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






41. Interfaces with other systems (hardware software and human) that a proposed system will interact with.






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






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






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






45. A business model that shows a business process in terms of the steps and input and output flows across multiple functions organizations or job roles.






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






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






48. A partial or preliminary version of the system.






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






50. The quality attributes design and implementation constraints and external interfaces that the product must have.