Across
- 5. The number of employees a manager is directly (or indirectly) responsible for.
- 6. The work to identify the stakeholders who may be impacted by a proposed initiative and assess their interests and likely participation
- 9. 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 categories of solution requirements
- 11. Meets a business need by resolving a problem or allowing an organization to take advantage of an opportunity
- 12. A high-level, informal, short description of a solutions capability that provides value to a stakeholder. Typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it.
- 17. 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.
- 19. A classification of requirements that describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete
- 22. A system trigger that is initiated by time
- 24. An organized peer review of a deliverable with the objective of finding errors and omissions. It is considered a form of quality assurance
- 28. A requirements document written for a user audience, describing user requirements and the impact of the anticipated changes on the users
- 32. The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role
- 33. A model that defines the boundaries of a business domain or solution
- 36. A document or collection of notes or diagrams used by the business analyst during the requirements development process.
- 38. A requirements document written primarily for Implementation SMEs describing functional and nonfunctional requirements
- 39. A stakeholder who provides products or services to an organization
- 40. A stakeholder, person, device, or system that directly or indirectly accesses a system
- 41. The set of capabilities a solution must deliver in order to meet the business need
- 42. Analysis of discrepancies between planned and actual performance, to determine the magnitude of those discrepancies and recommend corrective and preventative action as required.
- 43. Acronym for Strengths, Weaknesses, Opportunities, and Threats. It is a model used to understand influencing factors and how they may affect an initiative
- 45. Requirements that have been shown to demonstrate the characteristics of requirements quality and such are cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable
- 46. 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.
- 47. A brief statement or paragraph that describes the why, what, and who of the desired software product from a business point of view
Down
- 1. 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.
- 2. An analysis model that describes a series of actions or tasks that respond to an event. Each is an instance of a use case
- 3. A prototype that dives into the details of the interface, functionality, or both
- 4. A non-proprietary modeling and specification language used to specify, visualize, and document deliverables for object-oriented software-intensive systems
- 5. A listing of stakeholders affected by a business need or proposed solution and a description of their participation in a project or other initiative
- 6. Characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.
- 7. Administers a set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time
- 8. Alter the way a business analysis task is performed or describe a specific form the output of a task may take
- 10. A collection of interrelated elements that interact to achieve an objective. Elements can include hardware, software, and people. One can be a sub-element of another
- 13. An analysis model that describes the tasks that the system will perform actors and the goals that the system achieves for those actors along the way
- 14. An analysis model showing the life cycle of a data entity or class
- 15. A group or person who has interests that may be affected by an initiative or influence over it
- 16. The process of checking a product to ensure that it satisfies its intended use and conforms to its requirements. Ensures that you built the correct solution.
- 18. A type of peer reviews in which participants present, discuss, and step through a work product to find errors. Walkthroughs of requirements documentation are used to verify the correctness of requirements.
- 20. A stakeholder responsible for assessing the quality of, and identifying defects in, a software application
- 21. Requirements that have been demonstrated to deliver business value and to support the business goals and objectives
- 23. Determine when something is or is not true when things fall into a certain category. They describe categorizations that may change over time.
- 25. 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
- 26. A stakeholder with specific expertise in an aspect of the problem domain or potential solution alternatives or components
- 27. The area covered by a particular activity or topic of interest.
- 29. An actor who participates in but does not initiate a use case
- 30. A fixed period of time to accomplish a desired outcome
- 31. 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.
- 34. Limitations on the design of a solution that derive from the technology used in its implementation
- 35. A type of diagram defined by UML that captures all actors and use cases involved with a system or product
- 37. Type of diagram that shows objects participating in interactions and the messages exchanged between them
- 43. Work carried out on or behalf of others
- 44. A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project