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 means to elicit ideas and attitudes about a specific product service or opportunity in an interactive group environment. The participants share their impressions preferences and needs guided by a moderator.






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






3. The process of determining the relative importance of a set of items in order to determine the order in which they will be addressed.






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






5. An assessment of the costs and benefits associated with a proposed initiative.






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






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






8. A descriptor for a set of system objects that share the same attributes operations relationships and behavior. Represents a concept in the system under design. When used as an analysis model a class will generally also correspond to a real-world enti






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






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






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






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






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






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






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






16. An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one a






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






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






19. A description of the requirements management process.






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






21. The set of processes templates and activities that will be used to perform business analysis in a specific context.






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






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






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






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






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. An error in requirements caused by incorrect incomplete missing or conflicting requirements.






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






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






30. Statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Serve as a bridge between business requirements and the various






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






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






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






34. An analysis model that specifies complex business rules or logic concisely in an easy-to-read tabular format specifying all of the possible conditions and actions that need to be accounted for in business rules.






35. Strengths Weaknesses Opportunities and Threats. It is a model used to understand influencing factors and how they may affect an initiative.






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






37. A defined association between concepts classes or entities. Usually named and include the cardinality of the association.






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






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






40. A system trigger that is initiated by humans.






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






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






43. The work that must be performed to deliver a product service or result with the specified features and functions.






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






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






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






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






48. A prototype developed to explore or verify requirements.






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






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