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 stakeholder with specific expertise in an aspect of the problem domain or potential solution alternatives or components.






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






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






5. Assesses the effects that a proposed change will have on a stakeholder or stakeholder group project or system.






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






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






8. A stakeholder who will be responsible for designing developing and implementing the change described in the requirements and have specialized knowledge regarding the construction of one or more solution components.






9. The work done to ensure that the stated requirements support and are aligned with the goals and objectives of the business.






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






11. Software developed and sold for a particular market.






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






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






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






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






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






17. A state or condition the business must satisfy to reach its vision.






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






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






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






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






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






23. Analysis of discrepancies between planned and actual performance to determine the magnitude of those discrepancies and recommend corrective and preventative action as required.






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






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






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






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






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






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






30. A use case composed of a common set of steps used by multiple use cases.






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






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






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






34. The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time and to identify ways to improve the solution to better meet objectives. See also metric indicator and monitoring.






35. An informal solicitation of proposals from vendors.






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






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






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






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






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






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






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






43. A stakeholder who helps to keep the solution functioning either by providing support to end users (trainers help desk) or by keeping the solution operational on a day-to-day basis (network and other tech support).






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






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






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






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






48. An iteration that defines requirements for a subset of the solution scope. Would include identifying a part of the overall product scope to focus upon identifying requirements sources for that portion of the product analyzing stakeholders and plannin






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






50. A software tool that stores requirements information in a database captures requirements attributes and associations and facilitates requirements reporting.