elicitation and collaboration, requirement life cycle management, requirement analysis and design, requirement analysis and documentation

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

2. Elicitation and Collaboration

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.

15. Requirements Life Cycle
Management

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.

19. Assess
Approval/Validation
Manage
Trace
Maintain
Prioritise
Requirements life cycle Management

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

39. Writing User Story

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)

43. High Level Requirement
Epic
Story

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

48. Thank you
Admin@hostserviceuk.com

49. Reference
IIBA
IREB
Mountain Goat Software
Agile Alliance