More Related Content
What's hot
What's hot (20)
Similar to Requirement Elicitation Techniques
Similar to Requirement Elicitation Techniques (20)
More from Shwetha-BA
More from Shwetha-BA (12)
Recently uploaded
Recently uploaded (20)
Requirement Elicitation Techniques
- 2. Page 2Classification: Restricted Agenda • Requirements Engineering • Project Scope • Landscape of Requirements • Properties of Requirements • Types of Requirements • Stakeholder • Requirements Elicitation • Techniques
- 3. Page 3Classification: Restricted Project Scope Defining the proposed project scope includes: • Describing business objectives • Determining expected deliverables at a high level in terms of products, services or other outcomes • Documenting business assumptions and constraints • Building a statement of the anticipated work effort
- 5. Page 5Classification: Restricted Project Scope Vs Product Scope • Project Scope • Product Scope • Solution Scope
- 7. Page 7Classification: Restricted Landscape of Requirements A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by the system or system component to satisfy a contract, standard, specification or other formally imposed documents . A documented representation of a condition or capability as in (1) or (2). What is a Requirement?
- 8. Page 8Classification: Restricted Properties of Requirements Functionality – What the system can do. Constraints – What the system cannot do. Contents – What must be present in the system. Condition - A state that must exist at a particular time. Process - How a system provides a capability.
- 9. Page 9Classification: Restricted Types of Requirements Business Requirements are higher level requirements of the goals, objectives or needs of the enterprise. They describe such things as the reasons why a project is initiated, what the project will achieve, and the metrics which will be used to measure its success. Business Requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis. User Requirements are 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. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements. They are developed and defined through requirements analysis.
- 10. Page 10Classification: Restricted Types of Requirements Solution Requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirements analysis. They are frequently divided into sub- categories: Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations. Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.
- 11. Page 11Classification: Restricted Types of Requirements Transition Requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation. Assumptions and Constraints identify aspects of the problem domain that are not functional requirements of a solution and will limit or impact the design of a solution.
- 12. Page 12Classification: Restricted Requirements Engineering • Requirements Engineering, also called as Requirements analysis, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications
- 13. Page 13Classification: Restricted Business Requirements Initiation • Stakeholder Analysis • Apply Requirement Elicitation Techniques • Sort the Requirements • Prioritize Requirements • Validate Requirements
- 14. Page 14Classification: Restricted Stakeholder Analysis • Identify Stakeholders • Stakeholders Listing Document • Stakeholders Summary • RASCI Matrix-Responsible, Accountable, Supporting, Consulted, Informed
- 15. Page 15Classification: Restricted Who is Stakeholder? • A stakeholder is any person or organization that is actively involved in a project, or whose interests may be affected positively or negatively by execution of a project. 15
- 17. Page 17Classification: Restricted Stakeholders • Customers • Users • Management • Competitors • Regulators
- 18. Page 18Classification: Restricted Stakeholder Analysis – RACI Matrix
- 25. Page 25Classification: Restricted Cont’d… Focus Groups • It is a technique where prequalified stakeholders and SMEs are brought together to elicit their attitudes/ideas about a product, service or result • It is guided by a moderator who help the group focused and produces the report • Focus group can gather in a same room or online over network • It can be utilized during any life-cycle state: exploratory, under development, ready to launch, or in production • It is typically more structured unlike brainstorming where goal is to actively seek broad, creative, even exaggerated ideas
- 28. Page 28Classification: Restricted Cont’d…Interviews • It is a common/easy technique used in requirement gathering • It is a formal or informal direct talking approach to gather information • Performed by either prepared or spontaneous questions and recording responses • It may be one to one or one to multiple or multiple to multiple • This technique helps in obtaining highly focused business process knowledge from stake holder • This approach needs less planning and less stakeholder commitment for small groups
- 30. Page 30Classification: Restricted Cont’d…Observations • It is a direct way of viewing individuals in their work environment to see how a task, job or a process is carried out • This method is used when user has difficulty allotting time or articulating requirement • It is also called as Job Shadowing or Following people around • It is also used to study the detailed process and to uncover hidden requirements • This technique is appropriate when documenting details about current processes or if the project is intended to enhance or change the current process • Types of Observation: • Passive/Invisible • Active/Visible
- 33. Page 33Classification: Restricted Cont’d…Prototyping • It is providing a working model of a expected product • It gives better clarity in visual form rather than just oral or written representation of requirements • Prototypes can be created by various mock-ups and it helps users in experimenting, providing feedback and revision • When sufficient revisions are done to prototype, then the requirements gathered are moved to next phase of the project • Types of Prototype: • Horizontal – Eg: Just UI with no backend logic gives overview • Vertical – Eg: Both UI and logic gives deep understanding
- 35. Page 35Classification: Restricted Cont’d…Facilitated Work Shops • It is a most effective & structured way to gather and deliver high quality cross-functional requirements quickly • It is a highly productive focused event attended by carefully selected key stakeholders and subject matter experts for a short, intensive period • It is guided and moderated by a facilitator who has strong subject knowledge/experience • This technique helps in identifying issues and get resolved quickly than individual sessions • It is also called as JAD session where it brings users and development team together • It can promote trust, mutual understanding, and strong communications among the project stakeholders and project team
- 37. Page 37Classification: Restricted Cont’d…Questionnaires and Surveys • It is set of written questions to gather requirement from wide range of people in very short period of time • These questions/surveys are sent to stakeholders and SMEs • This technique is used when statistical analysis is required among the ideas • Types of Questions: • Closed – Questions with predefined list of responses/answers • Open ended – Questions which are open to answer anything • Normally Closed questions are used in Surveys as it helps analyzing the responses faster
- 38. Page 38Classification: Restricted Topic to be covered in next session •Introduction to OOA and UML •Stated vs Un-stated •Software Analysis and Design •Modeling •UML •Why UML •Overview •Types •Use Case Diagram •Types of Actor •Class Diagram •What is Class Diagram •Class Representation •Types of Class •Sequence Diagram •Interaction Diagram