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 human and nonhuman roles that interact with the system.






2. An organizational unit organization or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.






3. A shared boundary between any two persons and/or systems through which information is communicated.






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






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






6. An assessment that describes whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively.






7. A brief statement or paragraph that describes the why what and who of the desired software product from a business point of view.






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






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






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






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






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






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






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






15. A prototype used to quickly uncover and clarify interface requirements using simple tools sometimes just paper and pencil. Usually discarded when the final system has been developed.






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






17. The number of occurrences of one entity in a data model that are linked to a second entity. Is shown on a data model with a special notation number (e.g. 1) or letter (e.g. M for many).






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






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






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






21. Activities performed to ensure that a process will deliver products that meet an appropriate level of quality.






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






23. The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the desig






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






25. Determine when something is or is not true or when things fall into a certain category. They describe categorizations that may change over time.






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






27. A description of the requirements management process.






28. An organized peer review of a deliverable with the objective of finding errors and omissions. It is considered a form of quality assurance.






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






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






31. Software developed and sold for a particular market.






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






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






34. A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.






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






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






37. The ability to identify and document the lineage of each requirement including its derivation (backward traceability) its allocation (forward traceability) and its relationship to other requirements.






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






39. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.






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






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






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






43. Describes any limitations imposed on the solution that do not support the business or stakeholder needs.






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






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






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






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






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






49. A prototype that is continuously modified and updated in response to feedback from users.






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