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