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. An analysis model that illustrates the architecture of the system's user interface.






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






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






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






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






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






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






8. A system trigger that is initiated by humans.






9. A requirement articulated by a stakeholder that has not been analyzed verified or validated. Frequently reflect the desires of a stakeholder rather than the actual need.






10. Software developed and sold for a particular market.






11. A type of data model that depicts information groups as classes.






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






13. The subset of nonfunctional requirements that describes properties of the software's operation development and deployment (e.g. performance security usability portability and testability).






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






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






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






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






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






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






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






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






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






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. A diagramming technique used in root cause analysis to identify underlying causes of an observed problem and the relationships that exist between those causes.






25. A stakeholder who uses products or services delivered by an organization.






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






27. An actor who participates in but does not initiate a use case.






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






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






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






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






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






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






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






35. A set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time.






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






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






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






39. A system trigger that is initiated by time.






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






41. A prototype developed to explore or verify requirements.






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






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






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






45. A point-in-time view of requirements that have been reviewed and agreed upon to serve as a basis for further development.






46. A type of high-level business requirement that is a statement of a business objective or an impact the solution should have on its environment.






47. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive complete consistent correct feasible modifiable unambiguous and testable.






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






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






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