Requirement Engineering
- 1. Requirement Engineering by Ayo Apampa MSc Engr. And Economics Business Analysis Professional Diploma | Member IIBA Certified Scrum Master | Certified Scrum Product Owner GDPR Certified | Member International Association of Privacy Policy Microsoft Technical Associate | Certified in Server 2012, Network Fundamentals and Office 365 Affiliate International Compliance Association
- 3. Elicitation and Collaboration Elicitation is the gathering / receiving of information from stakeholders or other sources. It is the main path to discovering requirements and design information, and might involve talking with stakeholders directly, researching topics, experimenting, or simply being handed information. Collaboration is the act of two or more people working together towards a common goal.
- 4. Elicitation and collaboration can be planned, unplanned, or both. Planned activities such as one-on-one workshops, experiments, and/or surveys can be structured and organised in advance. Unplanned activities happen in the moment without notice, such as last-minute or 'just in time' collaboration or conversations.
- 5. The Elicitation and Collaboration consists of the following tasks • Prepare for Elicitation • Conduct Elicitation • Confirm/Validate Elicitation Results • Communicate Business Analysis Information • Manage Stakeholder Collaboration
- 6. This is ensuring that the stakeholders have adequate information they need to provide and that they understand the nature of the activities they are going to perform. It also sets a shared set of expectations regarding the outcomes of the activity. Preparation may also involve identifying research sources or preparing to conduct an experiment to see if a process change actually results in an improvement. Prepare for Elicitation
- 7. This is the work performed to understand stakeholder needs and identify potential solutions that may meet those needs. This may involve direct interaction with stakeholders, doing research, or running experiments. Conduct Elicitation
- 8. This involves ensuring that stakeholders have a shared understanding of the outcomes of elicitation, that elicited information is recorded appropriately, and that the business analyst has the information sought from an elicitation activity. This task also involves comparing the information received with other information to look for inconsistencies or gaps. Confirm Elicitation Results or Validation
- 9. This is when a business analyst provides stakeholders with the information they need, at the time they need it. The information is presented in a useful form, using the right terminology and concepts. Communicate Business Analysis Information
- 10. This describes the working with stakeholders to engage them in the overall business analysis process and to ensure that the business analyst can deliver the outcomes needed. Manage Stakeholder Collaboration
- 11. Why Elicitation and Collaboration • Change: the act of transformation in response to a need. • Need: a problem or opportunity to be addressed. • Solution: a specific way of satisfying one or more needs in a context. • Stakeholder: a group or individual with a relationship to the change, the need, or the solution. • Value: the worth, importance, or usefulness of something to a stakeholder within a context. • Context: the circumstances that influence, are influenced by, and provide understanding of the change.
- 12. Change: is the act of transformation in response to a need. The BA uses a different types of requirement gathering techniques to identify all the stakeholders needs about the change. The situation surrounding the change will determine the type of elicitation and collaboration technique to adopt. Need: is a problem or opportunity to be addressed. The BA will gather requirements, validate requirements with stakeholders and communicate needs and supporting business analysis information. As requirements gathering is iterative and incremental, the understanding of needs will continue to evolve over time.
- 13. Solution: a specific way of satisfying one or more needs in a context. The BA gathers requirements, validate, and communicate the proposed solutions. Stakeholder: Individual or group of people that have interest in the change, the need, or the solution. The BA will analyse and manage the collaboration with the stakeholders who participate in delivering the change. All stakeholders may participate in different roles and at different times during a change process.
- 14. Value: The value/change to be delivered to a stakeholder in response to the need within context The BA must collaborate with stakeholders to assess the relative value of information provided through requirement gathering, and apply a variety of techniques to confirm and communicate that value. Context: the circumstances that influence, are influenced by, and provide understanding of the change. The BA can apply a variety of requirement gathering techniques to identify all the requirements gathered about the context that may affect the change.
- 16. Definition The Requirements Life Cycle Management describes the tasks that the business analysts performs in order to manage and maintain requirements and design information from inception to retirement. These tasks involves establishing meaningful relationships between related requirements and designs, assessing changes to requirements and designs when changes are proposed, and analysing and validating all changes.
- 17. Purpose The purpose of requirements life cycle management is to ensure that business, stakeholder, and solution requirements and designs are aligned to one another and that the solution implements them. It involves a level of control over requirements and over how requirements will be implemented in the actual solution to be developed and delivered. It also helps to ensure that requirements are available for future use.
- 18. Requirements life cycle phases Refers to the existence of various phases or stages that requirements pass through as part of the change. Requirements may be in multiple stages at any one time. • begins with the representation of a business need as a requirement • continues through the development of a solution • ends when a solution and the requirements that represent it are retired. The management of requirements does not end once a solution is implemented. Throughout the life of a solution, requirements continue to provide value when they are managed appropriately.
- 20. • Assess Requirements Changes: The BA evaluates new and changing stakeholder requirements to determine if they need to be acted on within the scope of a change. • Validate Requirements: The BA works with stakeholders involved in the governance process to reach approval and agreement on requirements and designs.
- 21. Validate Requirements Techniques • Workshops • Item tracking • Decision analysis • Acceptance and evaluation criteria • Reviews
- 22. Trace Requirements: The BA analyses and maintain the relationships between requirements, designs, solution components, and other work products for impact analysis, coverage, and allocation. Maintain Requirements: The BA ensures that requirements and designs are accurate and current throughout the life cycle and facilitates reuse where appropriate.
- 23. Prioritise Requirements: The BA assesses the value, urgency, and risks associated with particular requirements and designs to ensure that analysis and/or delivery work is done on the most important ones at any given time. Prioritisation is continuous throughout the life cycle.
- 24. Basis for Prioritisation • Benefits • Penalty • Cost • Risk • Dependencies • Time sensitivity • Stability • Regulatory compliance
- 25. The Core Concept Model in Requirements Life Cycle Management
- 26. • Change – The BA manages how proposed changes to requirements and designs are evaluated in a project . • Need – The BA traces, prioritise and maintain requirements to ensure that the need is met. • Solution – The BA trace requirements and designs to solution components to ensure that the solution meets the stakeholder’s need.
- 27. • Stakeholder – The BA works closely with key stakeholders to maintain understanding, agreement, and validation of requirements and designs. • Value – The BA maintains requirements for reuse to extend value beyond the current project. • Context – The BA analyse the context to support tracing and prioritisation activities.
- 28. Requirement Analysis and Design Describes the tasks that is performed by the business analysts to structure and organise requirements that were gathered during requirements gathering activities, specify and model requirements and designs, validate and verify requirements, identify solution options that adds value to business needs, and estimate the potential value that could be realised for each solution option.
- 29. Analyse Requirements • What Must change to meet the business need • What Should change to meet the business need • What Could change • What Won’t change MoSCoW Matrix
- 30. Analysis Techniques • Functional decomposition • Non-functional decomposition • Data flow diagrams • Data modelling • Process modelling • Root Cause Analysis • Interface analysis • User stories
- 31. Requirement Relationship Requirements may be related to each other in several ways when defining the requirements architecture. Business analysts examine and analyse the requirements to define the relationships between them. The representation of these relationships is provided by tracing requirements
- 32. Business analysts must examine each relationship to ensure that the relationships satisfy the following quality criteria: • Defined / Specific: there is a relationship and the type of the relationship is described. • Necessary / Measurable: the relationship is necessary for understanding the requirements holistically. • Correct / Actionable / Acceptable: the elements do have the relationship described. • Unambiguous / Relevant: there are no relationships that link elements in two different and conflicting ways. • Consistent / Time-bound : relationships are described in the same way, using the same set of standard descriptions as defined in the viewpoints. Requirement must be SMART
- 33. Requirements Analysis and Documentation
- 34. Requirement Analysis This is the task for a business analyst to ensure that the solution conforms to client needs and understands the users’ expectations from the solution, categorising those expectations into different type of requirement categories, analysing the requirements elicited to understand what system functionalities are required to meet users’ expectations.
- 35. Requirement Documentation This is the task involved in documenting the verified and validated requirements into functional and non-functional requirements, different organisations have their own forms of documenting requirements using various tools such as Jira, Trello, Spreadsheet etc.
- 36. Requirement Types • Functional requirements • Non-Functional requirements • Interface requirements • Business Requirements • Regulatory/Compliance Requirements • Security Requirements • Transition Requirements
- 37. Gap Analysis Requirement gap analysis is a process of analysing the current state of the process, users’ expectations of the future state and finding the missing elements to fulfill that gap. A thorough understanding of the current and future state of the system is very important because if we do not know where we are currently, we can not figure out how to reach the destination and what it will take to reach there.
- 38. To Be As Is Gaps/Action Provide estimate of wait time to caller once they have been on hold for 15 seconds Callers have no idea how long they will be waiting. Software that will provide estimate of wait time to callers, research vendors and pricing, get approval Respond to simple, common email questions within 2 business days. Emails are answered in the order they are received irrespective of volume of contents. 1. Develop a FAQ page on the website to reduce email volume 2. Filter out common questions to be answered first Respond to inquiries that arrive by mail and give an estimate of response time within 15 business days We do not track response time 1. Work with Executive Secretariat 2. Consider purchasing tracking software Reduce wait time at walk in centers to 15 minutes or less Many customers wait more than 15 minutes. 1. Increase staff 2. Make more transactions accessible online, so customer does not have to appear in person Example of GAP Analysis for a Call Centre
- 40. What is a User Story? These are short and simple descriptions of a feature of the solution told from the perspective of the user or customer of the system. How to write a User Story As a < type of user >, I want < some goal > so that < some reason >.
- 41. In Agile project management a story-writing workshop is usually held close to the start of the project. Every member of the team participates in creating the product backlog that fully describes the functionality to be added over the course of the project or in a 2 to 4 iteration (sprint) period. Some of these user stories may be epics, which will later be decomposed into smaller stories that fits more readily into a single iteration. Also, new stories can be written and added to the product backlog at any time and by anyone as the project progress. When are user stories written?
- 42. INVEST is a checklist to assess the quality of a User Story. If the story does not meet one of these criteria, the team will physically tear the old story card to write a new one. A good user story should be: Independent (of all others) Negotiable (not a specific contract for features) Valuable (should add value to business objective) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn't a test for it yet)
- 44. Typical Example of a User Story As an authorised user, I want to access my profile so that I can select courses to read. As a registered student, I want my profile page to include additional details about my registration so that my friends can know when I’m logged in. As a site visitor, I want to read FAQs, so that I can get quick help.
- 45. Test Criteria Writing a Test criteria using GHERKIN syntax: Feature: Logout from application Scenario: Given I am logged in When I click “log out” button Then I am informed about successful logout And I am redirected to login page
- 46. Guidance for User Story Documentation Each user story must be adequately documented containing the following: • User Story ID • User Story Name • User Story History Created By • Date Created • Last Updated By • Date Last Updated • Priority (MoSCoW) • Business Rules • Notes and Issues
- 47. Question
- 49. Reference IIBA IREB Mountain Goat Software Agile Alliance