The document outlines an approach to requirement assessment that includes gathering inputs from business needs, organizational processes, and expert judgment. It involves conducting a requirement workshop, brainstorming sessions, and document analysis to develop outputs like user stories, functional requirements, and non-functional requirements. The approach aims to clearly define what is needed from a potential solution by engaging stakeholders and analyzing existing materials.

1. Requirement Assessment
Technique Approach
Prepared by: Deny Prasetia
Copyright 2015

2. • Framework:
Inputs
Requirement Workshop
Document Analysis
Brainstorming
Tasks Outputs
User Story
Functional
Requirement
Non Functional
Requirement
Business Needs
Organizational Process
Assets
Expert Judgment

3. o Inputs:
• Business Needs:
The approaches will be shaped by the pain or opportunity faced by the organization. It is generally necessary to consider the
gain associated with it, the timeframe in which the need must be addressed, and how well the need is understood.
Anyway, BSI already have business need sheet (that raised by DSF), so BSI can used it as material for the requirement
workshop. This will help determine whether a plan-driven or change-driven approach is appropriate.
• Organizational Process Assets:
Organizational process assets that may be useful in defining the clear requirement. BSI can ask to DSF management to push
the key user to provide the some meta data’s, reports, memos, guidelines, procedures, files, etc. Through the document
analysis BSI can get the details perspective from the current situations. Hopefully dedicated person from NBD can support
this activities.
• Expert Judgment:
Expertise may be provided from a wide range of sources including stakeholders in the initiative based on the great
experience and/ or best practice. Prior experiences of person and/ or other stakeholders should be considered when
selecting or modifying an approach. As I know DSF NBD have people who as assigned as advisor for Operating Lease
Business. Hopefully, he can keep always support to help us to clarify the requirement in high level.

4. o Tasks:
• Requirement Workshop:
Requirement workshop is structured way to capture requirement. Before the workshop BSI can ask DSF to clarify stakeholder
needs, critical stakeholders, and introduce the goals and agenda for the meeting. Within workshop technique we can
capture user story then determine to the scope, out of scope, obtain consensus on conflicting views, and prioritize on
requirements for the target system.
• Brainstorming:
Brainstorming is an excellent way to foster creative thinking about a problem. The aim of brainstorming is to produce
numerous new ideas, and to derive from them themes for further analysis. BSI can walkthrough to the NBD people as key
users to focus on a topic or problem, and then coming up with many possible solutions to it. Usually flexible meeting (i.e
coffee time, smoking time, or small talk) is best approach to conduct this way.
• Document Analysis:
Document analysis is a means to elicit requirements by studying available documentation (or organizational process assets)
on existing and comparable solutions and identifying relevant information. Through this technique BSI can obtain answers to
follow-up questions to DSF people as key users, and then BSI can organize information (from documents) into requirements
format.

5. o Outputs:
• User Story:
User stories are a authentic brief description of functionality that users need from a solution to meet a business objective.
On the user story BSI can build customer ownership of features and prioritizations in an incremental, iterative development
environment. They may eliminate the need to provide Functional Requirements and Non Functional Requirement in some
environments. User stories also require that the value delivered by the story be clearly articulated. Review and Approval
from DSF is must have/ required.
• Functional Requirement:
Describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are
frequently divided into sub-categories, particularly when the requirements describe a software solution. They 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—specific information technology application actions or responses. BSI can developed and
defined this through analyze the user story. Review and Approval from DSF is must have/ required.
• Non-Functional Requirement:
The purpose of non-functional requirements is to describe the required qualities of a system, such as its usability and
performance characteristics. These supplement the documentation of functional requirements, which describe the behavior
of the system. Originally BSI already have the non functional requirement from the Phase-1, but in the Phase-2 there is
possibilities to linked to another system. So, BSI still needs to capture the this aspect as must. Review and Approval from DSF
is must have/ required.