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 conceptual view of all or part of an enterprise focusing on products deliverables and events that are important to the mission of the organization. Is useful to validate the solution scope with the business and technical stakeholders. See also mode






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






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






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






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






6. An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way.






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






8. Software developed and sold for a particular market.






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






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. Something that occurs to which an organizational unit system or process must respond.






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






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






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






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






16. A process in which a deliverable (or the solution overall) is progressively elaborated upon. Will result in a self-contained "mini-project" in which a set of activities are undertaken resulting in the development of a subset of project deliverables.






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






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






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






20. Work carried out or on behalf of others.






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






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






23. The degree to which a set of inherent characteristics fulfills requirements.






24. An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.






25. A prototype that shows a shallow and possibly wide view of the system's functionality but which does not generally support any actual use or interaction.






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






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






28. A unit of work performed as part of an initiative or process.






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






30. An analysis model showing the life cycle of a data entity or class.






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






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






33. An approach to decision-making that examines and models the possible consequences of different decisions. Assists in making an optimal decision under conditions of uncertainty.






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






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






36. Defining whether or not a relationship between entities in a data model is mandatory. Is shown on a data model with a special notation.






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






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






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






41. A real or virtual facility where all information on a specific topic is stored and is available for retrieval.






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






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






44. An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.






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






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






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






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






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






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