31269: Business Requirements Modelling

Requirements Process

Week 2 Lecture

UTS CRICOS 00099F

Agenda
• Understand “Requirements Process” within the system development
process.
• Understand the stages/phases of a Requirements Process and
activities and tasks within each stage/phase.
• Identify Stakeholders and understand who they are.

2
Requirements Engineering
• Software system development is driven by
• “Requirements Engineering”

• Requirements engineering (RE) refers to the process of defining,

documenting and maintaining requirements and to the subfields
of systems engineering and software engineering concerned with this
process.

Slide 3
31269 Business Requirements Modelling
 Waterfall System Development Process

Sommerville(2016)

The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. In principle, a
phase has to be complete before moving
31269 Business Requirements Modelling Slide 4
onto the next phase.
 Incremental System Development Process

The cost of accommodating

changing customer requirements is
reduced.

The amount of analysis and

documentation that has to be
redone is much less than is
required with the waterfall
model.

However the process is not visible.

Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-
effective to produce documents that reflect every version of the system.
 Agile System Development Process

Scrum – Iterative Process

Initial Requirements or Detail Requirements or

User Stories User Stories

Subset/portion
of requirements

Source: http://en.wikipedia.org/wiki/Scrum_(development)

Slide 6
Sequential (traditional approach) vs. overlapping
(agile) development

Requirements Design Code Test

Rather than doing all of one

thing (phase) at a time...
...development teams do
a little of everything all
the time

Source: “The New New Product Development Game” by Takeuchi

and Nonaka. Harvard Business Review, January 1986.
Slide 7
 Requirements Process
• To find the correct and complete requirements, we need some kind of orderly
process. And hence we need Requirements Process.
• Process is a set of steps (phases) that a software program goes through when
developed.
• It is a structure imposed on the development of a software product.
• Requirements process includes:
• stages/phases (e.g. Planning, Analysis, Elicitation, Specification, etc.)
• activities and tasks (within each stage/phase)
• techniques
• tools
for discovering the purpose of the “software”, and the needs of the users to support
their activities.
31269 Business Requirements Modelling Slide 8
Requirements Engineering/Development
Process
Requirements Process Stages:
Requirements Elicitation
• Process of seeking, uncovering, acquiring, and elaborating requirements
for computer-based systems.
• Requirements are elicited rather than just captured or collected. This
implies there are discovery, emergence, and development elements to the
elicitation process.
• A complex process involving many activities with a variety of available
techniques, approaches, and tools.
• We need to identify the various sources of requirements. Hence we need to
identify and analyse all the relevant stakeholders.
• Once identified – various elicitation techniques can apply: Brain Storming,
Interviews, Requirements Workshops, Document Analysis, Observation,
Prototyping, Survey questionnaires (next week)

31269 Business Requirements Modelling Slide 10

Requirements Process Stages:
Requirements Analysis & Modelling

• Requirements Analysis: determining whether the stated requirements

are clear, complete, consistent and unambiguous, and resolving any
apparent conflicts.
• Requirements Modelling: developing a set of diagrams known as
requirements models, each of which focuses on a different aspect of
the users' needs. e.g.
• Business Process Modelling with BPMN
• Data Modelling with ERD
• Object Oriented Modelling with UML

31269 Business Requirements Modelling Slide 11

 Requirements Process Stages:
Requirements Specification & Requirements Validation
• Requirements Specification: After analysing and modelling the
requirements, requirements are specified and documented in a
software requirements specification (SRS) document.

• Requirements Verification and Validation: checking that the

documented requirements and models are consistent and meet
stakeholder needs.

31269 Business Requirements Modelling Slide 12

Requirements Quality
• Requirements are SMART
• Specific, Simple
• Measureable, Manageable
• Attainable (Achievable, Actionable, Appropriate)
• Realistic (Rationale, Result Oriented, Realistic to deliver)
• Time-bound (Timely, Testable, Traceable)

More details in tutorial notes. Also, please refer notes section of this slide.

Go to this link and read the examples:

https://www.slideshare.net/HarmonyBrenner/smart-requirements-4590952

31269 Business Requirements Modelling Slide 13

Requirements Process Stages:
Requirements Management
• Requirements Management is the process of documenting, analyzing,
tracing, prioritizing and agreeing on requirements and then controlling
change and communicating to relevant stakeholders.
• It is a continuous process throughout a project.

• The purpose of requirements management is to ensure that an

organisation documents, verifies, and meets the needs and
expectations of its customers and internal or external stakeholders.

• Tools: Requirements Backlog, Burndown charts, Requirements

Register or Excel Spreadsheet, IBM JazzHub, JIRA

31269 Business Requirements Modelling Slide 14

Types of Requirements (BABOK V3.0)
• Business Requirements
• Stakeholders Requirements
• Solution Requirements
• Transition Requirements
Types of Solution Requirements
• Functional Requirements (things product must do)
• Examples:
• The software system must be able to produce a monthly sales report for a given month…
• The system must enable hotel guests to book a room online.
• Non-functional Requirements (qualities product must have)
• Examples:
• The software system should be able to produce a monthly sales report for a given month in
less than 5 seconds…
• The software system should be able to produce a monthly sales report for a given month in
less than 5 seconds and display it on iPad…
• The system should be able to process 100 payment transactions per second.

31269 Business Requirements Modelling Slide 16

Types of Solution Requirements
• Functional Requirements (things product/system must do)
• 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.
• Non-functional Requirements (qualities product/system must have)
• 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, safety, security, availability and the information
architecture and presentation of the user interface. Examples include software performance
requirements, external interface requirements, software design constraints and software
quality attributes.

31269 Business Requirements Modelling Slide 17

Requirements Activities/Tasks
• Requirements are
• Identified
• Captured
• Managed
• Communicated
• Prioritised
• Estimated
• Scoped
• De-scoped
• Signed Off

31269 Business Requirements Modelling Slide 18

Requirements Engineering/Development
Process
Requirements Elicitation: Stakeholders Analysis
Who are Stakeholders?
• Stakeholders
• An individual, team or organisation who have interest in, or can influence or be
affected by, or participate in the development of requirements and relative
software system projects
• Stakeholder have different roles based on their interest and responsibility in an
organisation
• Failure to discover all stakeholders can mean failure to discover all their needs.
• Find all parties who will be affected by the product, and find their
requirements/needs.

31269 Business Requirements Modelling Slide 20

Stakeholder Classes/Types/Roles
•Sponsor
•Owner
•Project Manager
•Business Analyst (BA) – our role
•Quality Analyst
•Customer
•Supplier
•End User
•Domain Subject Matter Expert (SME)
•Implementation Subject Matter Expert (SME)
•Support Professionals
•Regulator

31269 Business Requirements Modelling Slide 21

Stakeholder Classes: roles
• Users: Users have an interest in having a product that does their work
correctly. They are people who will ultimately be hands on operators of
your product.
• Sponsor: Sponsor is an owner representative and represents owner’s
interest. Pays for the development of the product. For e.g.,
Departmental Manager, Program Manager, etc.
• Subject Matter Experts: People who have specialised knowledge of
the business subject, individual with in-depth knowledge of a topic
relevant to the business need or solution scope

31269 Business Requirements Modelling Slide 22

 Stakeholder Classes: roles
• Customer: The customer buys the product once it is developed. A customer is a
stakeholder outside the boundary of a given organization or organizational unit.
Know this person well to understand what he/she finds valuable and what appeals
to them.
• Developers/Software Engineers: Developers are responsible for the construction
of software applications. Areas of expertise among developers or software
engineers include particular languages or application components.
• Project Manager: Project managers are responsible for managing the work
required to deliver a solution that meets a business need, and for ensuring that the
project’s objectives are met while balancing the project constraints, including
scope, budget, schedule, resources, quality, risk, and others.
Note: For more details see BABOK Guide Chapter2.

31269 Business Requirements Modelling Slide 23

Requirements Elicitation: Stakeholders Analysis
Identifying and understanding stakeholders
• Below are some questions to consider when identifying the stakholders and analysing the
impact of new changes.
• Who is the new change and business transformation going to affect (who all will be
impacted?)?
• Who has an interest in these new changes and this project?
• Who and how are you going to communicate these changes/requirements to the stakeholders?
What is the communications plan?
• Who are critical to this business transformation? Who can influence?
• Who is paying for the project?
• Who will be managing, reviewing and signing off?
Note: Please watch “Workshop Videos 1 and 2” available on uts online to identify and understand the
stakeholders.
• Stakeholders analysis/identification techniques:
• Technique1: stakeholders list/map/register and
• Technique2: empathy map

31269 Business Requirements Modelling Slide 24

 Stakeholders Analysis: Why do it?
• Stakeholder analysis involves identifying all the relevant stakeholders and eliciting
and understanding their needs (and any issues with current system).
• Stakeholder analysis is the review and consideration of the impact stakeholders
have on your business. Companies need to understand the interests of each
stakeholder.
• To understand the importance and influence of individual stakeholders on the
project.
• To utilise the vast amount of information and knowledge that stakeholders hold to
find workable, efficient and sustainable solutions.
• To Gain support from powerful stakeholders which can help you to win more
resources – this makes it more likely that your projects will have less obstacles and
conflicts and hence be successful.
31269 Business Requirements Modelling Slide 25
Stakeholders Analysis and Identification Technique 1:
Stakeholders Map/Register/Table
Position Project Role Contact Information Level of Level of Potential Management Strategies
Interest Influence

Mike is very outgoing and visionary. Great traits for a

project champion. He is concerned about financials
Project msundy@globalconstr and has an MBA. Keep him informed and ask for his
Mike Sundby VP of HR Champion uction.com High High advice as needed.

Lucy has a PhD in Education and knows training at this

company. She is very professional and easy to work
with, but she can stretch out conversations. Make sure
Lucy Training Project lcamerena@globalcon she reviews important work before showing it to other
Camerena Director Sponsor struction.com High High managers. Could be high,
medium or low

Ron led the phase I project and is upset that he was

not asked to lead this phase II project. He's been with
the company for over 20 years and can be a good
Senior HR resource but he can also sabotage the project. Ask
staff Led the Phase rryan@globalconstruct Lucy to talk to him to avoid problems. Perhaps give
Ron Ryan member I project ion.com Medium Medium him a small consulting role on the project.
Xxx Yyyy
Yyy Zzz

31269 Business Requirements Modelling Slide 26

Stakeholders Analysis and Identification Technique 2:
Empathy Map

31269 Business Requirements Modelling Slide 27

Example

31269 Business Requirements Modelling Slide 28

 What do we want from users?

• What?
• Understand their problems – what is limiting them?
• Understand the requirements of the current and future system
• Understand the scope
• Understand the requirements priority

31269 Business Requirements Modelling Slide 29

Conflicts and Challenges
• Why are there conflicts?
• Empires, power and fear
• Why are there differences between stakeholders?
• Different views, time-frames, granularity, experiences
• What influences these differences?
• Communication, Openness

31269 Business Requirements Modelling Slide 30

Understanding Conflicts
• Stakeholders may have conflicting requirements
• Not understanding stakeholder differences can lead to
• Poor communication
• Miscommunication
• Conflicts and failed software projects
• Unless there is an understanding of what causes the conflicts, it is very difficult to
determine appropriate trade-offs
• Facilitate communication between the stakeholders who are in conflict over the
requirement in order to resolve the issue.
• Conflicts may be resolved through formal meetings among affected stakeholders,
through research, resolution by a third party, or other methods as appropriate.
• Source: BABOK guide
31269 Business Requirements Modelling Slide 31
 Q&A

31269 Business Requirements Modelling Slide 32

NEXT WEEK
Requirements Elicitation

Slide 33
Thank you

UTS CRICOS 00099F