61FIT3REQ – Software Requirements Analysis

Lecture 1

Introduction to Business Analysis

Faculty of Information Technology

Hanoi University
 Software Development Tasks
• Requirements Specification • Testing
• Data Modeling • Management
• UI Design • DevOps
• UI Implementation • Documenting
• Backend Implementation • Deployment

The two main concerns of software engineering:

Quality & Requirements
 Requirements Engineering (RE)
• Purpose: to develop explicit requirements
specification that is agreed on by all stakeholders.
• Characteristics of RE: iterative, systematic, efficient,
effective.
• Major phases:
– Elicitation
– Analysis
– Specification
– Validation & Verification
 WHY Requirements Engineering?
• It is essential
– Without an accurate description of the system under
development, no system can be developed.
– Even if you think you don’t do RE, you still handle
requirements somehow.
• Great benefits if done correctly
– If you handle them in a systematic way, you
understand the customer’s problem and can then
develop the best solution.
 Course Objectives
• The role/place of requirements engineering in
software engineering
• Business analysis techniques
• Developing clear, concise, and sufficiently formal
requirements
– Use-case modeling
– Data modeling
– UML and other types of diagrams
 This course helps you to...
• Write high-quality software requirements.
– Minimize rework, maximize productivity.
• Deliver high-quality information systems that
achieve their business objectives.
– Higher customer satisfaction.
• Manage scope creep and requirements changes.
– Put the project under control.
• Reduce maintenance, enhancement, and support
costs.
 Course Assessments

• Class performance: 10%

• Progress Test (Quiz): 15%
• Diagram Test: 15%
• Final Exam: 60%
 Learning approach
• Pictures Are Easy, Words Are Hard
– Focus on models & diagrams
• BUT, requirements models cannot replace
everything.
– A visual model provides a big picture (the context) but not
the specific details.
 Suggested Books
• Ian Sommerville – Software Engineering (2016)
• Karl Wiegers, Joy Beatty – Software Requirements,
Third Edition (2013)
• Joy Beatty, Anthony Chen – Visual Models for
Software Requirements (2012)
 What is Business Analysis?
Business analysis is the practice of enabling change in an
enterprise by defining needs and recommending
solutions that deliver value to stakeholders.
BABOK Guide v3 (2015)

• A solution is meant to provide values to organizations

• Business analysis can be used to understand the current
state, to define the future state, and to determine the
activities required to move from the current to the future
state for the enterprise/organization.
 Who are the stakeholders?
A stakeholder is a person, group, or organization
that is actively involved in a project, is affected by
its process or outcome, or can influence its
process or outcome.
K. Wiegers, J. Beatty (2013)
• Potential stakeholders:
– Outside the developer’s organization
• Sponsor
• Users
• General public
– From the developer’s organization
• Company owner
• Project team
• Sales & Marketing
 Who is a Business Analyst?
A person who performs business analysis tasks, which
include discovering, synthesizing, and analyzing
information from a variety of sources within an
enterprise, including tools, processes, documentation,
and stakeholders.
BABOK Guide v3 (2015)
• Activities
– Understanding enterprise problems and goals
– Analyzing needs and solutions
– Devising strategies
– Driving changes
– Facilitating stakeholder collaboration
• A Business Analyst is also known as Requirements
Engineer
 Responsibilities of a Business Analyst
• The one who knows the software product best
– Better than the customers themselves.

• Understand customer’s business

– And figure out the best solution for customer

• Turn customer’s ideas into documented

requirements.
– Most stakeholders will use the requirements documents,
namely: designer, tester, project manager…

• Provide support in review activities

 Essential Business Analyst Skills
• Listening skills
– Eliminating distractions
– Maintaining an attentive posture and eye contact
– Restating key points to confirm your understanding
• Interviewing and questioning skills
– Most requirements input comes through discussions
• Thinking on your feet
– Verify new information against existing information
– Detect contradictions, uncertainty, vagueness, and
assumptions…
 Essential Business Analyst Skills
• Analytical skills
• Systematic thinking
• Learning skills
• Observation skills
• Creativity
• Modeling skills
– Flowchart, data flow diagram, entity-relationship
diagram, UML
 The making of a Business Analyst
• The former user
– He understands the business, the existing systems and
he speaks the user’s language.
– He might know little about software engineering or
how to communicate with technical people.
• The former developer or tester
– Developers have little patience with users, preferring to
work with the code.
– A tester often has an analytical mindset that can lend
itself to being a good BA.
 The making of a Business Analyst
• The former (or concurrent) project manager
– He already has many necessary skills for BA, only a few
BA-specific skills to learn.
• The subject matter expert
– He might specify the system’s requirements to suit his
own preferences, rather than addressing the needs of
the various users.
• The rookie
– A new graduate will have much to learn about how to
execute the BA tasks
From Mastering the Requirements Process by S. Robertson & J. Robertson

FUNDAMENTAL TRUTHS
ABOUT REQUIREMENTS
 Truth #1
Requirements are not really about requirements.

• Requirements exist whether you discover them or not.

• Requirements engineering focuses on understanding a
business problem and providing a solution for it.
• Requirements are not about the written requirements,
but rather the uncovering of the real problem.
• The word “business” can refer to any activity we are
concerned with: commercial, scientific, government,
military, service, manufacture…
 Truth #2
If we must build software, then it must be
optimally valuable for its owner.

• The owner is the person or organization that pays for

the software (either development cost or software
purchase cost).
• On the other end, the owner gets a benefit from the
software.
– The software provides new capabilities.
– The software improves some business process to be faster or
cheaper or more convenient.
• The benefit must exceed the software development cost.
 Truth #3
If your software is meant to satisfy a need,
then you have to know what that need is
to build the right software.

• You must come to the correct understanding of the

requirements.
• Your client must agree with the requirements.
 Truth #4
There is an important difference between
building a piece of software and solving a
business problem. The former does not
necessarily accomplish the latter.
 Truth #5
The requirements do not have to be
written, but they have to become known
to the builders.
 Truth #6
Your customer won’t always give you the
right answer., and.

• Sometimes it is technically
impossible for the customer
to know what is right.
• Sometimes he just doesn’t
know what he needs.
 Truth #7
Requirements do not come about by
chance. There needs to be some kind of
orderly process for developing them.

• These processes are not lockstep procedures where

one mindlessly follows every instruction without
question.
• We must be able to see why different tasks within the
process are important, and which tasks carry the most
significance for the project.
 Truth #8
You can be as iterative as you want, but
you still need to understand what the
business needs.

• Iterative development (e.g. Agile) is the method of

splitting software development into short iterations.
Partially finished software products are presented to
the customer after each iteration to receive feedbacks
for starting the next one.
 Truth #9
All our methods and tools will not
compensate for poor thought and poor
workmanship.

• Tools must be seen as aids and not as substitutes for

good requirements practices.
• Following processes is good, but blindly following
processes without thinking isn’t.
 Truth #10
Requirements, if they are to be
implemented successfully, must be
measurable and testable.
 Truth #11
You, the business analyst, will change
the way the user thinks about his
problem, either now or later.

• Requirements stated by the user are usually bad.

• Users do not usually understand their requirements.
• Once they do, they are likely to improve their
requirements, thus help you discover the real problem.
From Software Requirements by K. Wiegers & J. Beatty

THE CUSTOMER’S PERSPECTIVE

ABOUT REQUIREMENTS
 Who are the customers?
A customer is an individual or organization that
derives either direct or indirect benefit from a
product.
K. Wiegers, J. Beatty (2013)

• Customers is a subset of stakeholders

• Customers:
– Sponsor, users,
• Non-customers:
– Legal staff, compliance auditors...
• A customer provides the business requirements
 The Expectation Gap

• The best way to minimize the expectation gap is to

arrange frequent customer meetings.
 Software Customers: 10 Rights
1. Expect BAs to speak your language.
2. Expect BAs to learn about your business and your objectives.
3. Expect BAs to record requirements in an appropriate form.
4. Receive explanations of requirements practices and
deliverables.
5. Change your requirements.
6. Expect an environment of mutual respect.
7. Hear ideas and alternatives for your requirements and for their
solution.
8. Describe characteristics that will make the product easy to use.
9. Hear about ways to adjust requirements to accelerate
development through reuse.
10. Receive a system that meets your functional needs and quality
expectations.
Software Customers: 10 Responsibilities
1. Educate BAs and developers about your business.
2. Dedicate the time that it takes to provide and clarify
requirements.
3. Be specific and precise when providing input about
requirements.
4. Make timely decisions about requirements when asked.
5. Respect a developer’s assessment of the cost and feasibility of
requirements.
6. Set realistic requirement priorities in collaboration with
developers.
7. Review requirements and evaluate prototypes.
8. Establish acceptance criteria.
9. Promptly communicate changes to the requirements.
10. Respect the requirements development process.