Requirement Engineering Seminar PPT RML Book

1. AN INTRODUCTION
TO VISUAL MODELS
FOR SOFTWARE REQUIREMENTS

2. Index
1. Introduction to Requirements Modeling Language (RML).
1.1. Prelude.
1.2. Challenges with Traditional Software Requirements Practices.
1.3. What are Requirements Modeling Languages?
1.4. What are Requirements Models?
2. Model Categorization.
2.1. Introduction.
2.2. Objectives Model.
2.3. People Model.
2.4. System Model.
2.5. Data Model.

3. 1. INTRODUCTION TO
REQUIREMENTS MODELING LANGUAGE
(RML)

4. 1.1. PRELUDE

5. Prelude
Missed
requirements
Incomplete
requirements
Unclear
requirements
Failed
project
Poor requirements are at the root of many project failure, but the
success of software requirements industry has not dramatically improved
over the last 20 years.

6. Prelude
Although academia has been steadily identifying approaches for
improving requirements techniques and engineering methods, commercial
practices have remained largely the same.
Software requirements are often still developed by using long lists of
“shall” statements maintained in spreadsheet.

7. 1.2. CHALLENGES WITH
TRADITIONAL SOFTWARE REQUIREMENTS
PRACTICES

8. Challenges with Traditional
Software Requirements Practices
It is nearly impossible to read the thousands of requirements
and emerge confident that the requirements are complete
Difficult to determine which requirements should be cut without
some way to link those requirements to values that can be
compared across the solution

9. Challenges with Traditional
Software Requirements Practices
Limitations of the Human brain
Traditional practices use long lists of text requirements in the form
of shall statements, use cases, user stories and product backlogs.
The challenge of working with long lists of items results from a
fundamental limitation of human recognition.
A list of
999+ items
Multiple
organizational
lists

10. Challenges with Traditional
Software Requirements Practices
Pictures are easy, words are hard
A picture worth a thousand words
Models are visual representations (pictures) of information related to
the processes, data, and interactions within and surrounding the
solution being developed
Step 1: walk pass the bar
Step 2: turn right and straight
to the fountain
Step 3:
Step 4:
Step 5: Straight until you see
elevator on the right
How to get to the elevator ?
Or

11. 1.3. WHAT ARE
REQUIREMENTS MODELING LANGUAGES?

12. RML Defined
What it is?
A language designed specifically
to visually model requirements
What it is not?
A theoretical modeling language
What it stand for?
Requirements Modeling Language
What its purpose?
For easy consumption by
executive, business, and
technical stakeholders How is it created?
Modified existing models for
ease of use and created new
models to address gap
Does it reach its purpose?
Yes

13. RML Defined
Requirements Modeling Languages (RMLs) are formal or semi-formal
notations that help software engineers capture, analyse, and
communicate the business rules, the functional and non-functional
requirements of a software system.
RMLs can range from textual to graphical, from abstract to concrete,
and from general to domain-specific.

14. 1.4. WHAT ARE
REQUIREMENTS MODELS?

15. Requirements Models
Scenario: Building a Digital Marketing System

16. The Stakeholders

17. REQ001. The digital marketing system shall provide the capability to
create and manage marketing campaigns.
REQ002. It shall allow users to define target audiences and customer
segments for each campaign.
REQ003. The system shall support multiple digital marketing channels,
including email, social media, search engine marketing (SEM), content
marketing, and display advertising.
REQ004. It shall enable the scheduling and automation of marketing
campaigns to run at specified times.
REQ005. The system shall facilitate the creation of landing pages and
customizable website content for marketing campaigns.
REQ006. It shall provide tools for A/B testing and multivariate testing
to optimize marketing content and strategies.
REQ007. The system shall include customer relationship management (CRM)
features to manage customer data, leads, and contacts.
REQ008. It shall support personalization and segmentation of marketing
content based on customer behaviors and preferences.
The “System Shall” List

18. REQ009. The system shall enable the tracking of customer interactions
across various digital channels.
REQ110. It shall integrate with third-party analytics tools to provide
in-depth campaign performance data.
REQ111. The system shall support email marketing campaigns, including
newsletter creation, list management, and tracking.
REQ112. It shall allow for the creation and scheduling of social media
posts and advertisements.
REQ113. The system shall provide keyword research and optimization
tools for search engine marketing.
REQ114. It shall support the creation and publication of blog posts,
articles, and other content.
REQ115. The system shall integrate with advertising networks for
display advertising campaigns.
REQ116. It shall include a content calendar for planning and scheduling
marketing content.
The “System Shall” List

19. => No clear overview of the project’s scope; Misinterpretation,
misunderstandings; Difficulty identifying dependencies etc.!
It is difficult to read, interpret, and identify gaps in a requirements
document of thousands of “system shall” statements, but models can
help!
The “System Shall” List

22. Requirements Models
Requirements models help organize and present large quantities of
information, identify missing information, and give context to details,
provide visual groupings that enable ability to quickly analyse large
amounts of disparate information by using limited short-term memory.

23. Requirements Models
The key to finding missing requirements is to take advantage of the
fact that each requirement is related to other requirements in some
way. It is extraordinarily difficult to ensure completeness with a
given long list of “system shall“ statements, but adding structure to
the requirements takes advantage of their relationship and greatly
simplifies the task by allowing to analyse smaller groups of
information at one time.

24. Uh, Why Not Just Using UML
It lacks models that tie requirements to business value and models that
present the system from an end user’s point of view.
Its technical roots make it simply too much complex for business
stakeholders to adopt because its models are geared towards modelling
the structure of the software architecture.
UML is intended to be used to describe the technical design and
architecture of a system and is at best retrofitted to model
requirements, which are focused on business benefit, user actions, and
business rules.

25. Requirements Models Are Not the End Game
Requirements models not eliminate the need to write requirement
statements. The models provide context and create an overall picture of
the requirements, but not represent the final detailed requirements
that will be used by the system developers and testers.
=> Derive requirements from the models is necessary!
The value of models is in helping organize the requirements in a way
that makes it easy to see when requirements are missing, extraneous, or
incorrect, but only the combination of textual and visual requirements
can paint a full picture of the solution to be built.

26. Using RML on Projects
RML models as a toolbox of models and templates for use on software
projects. Multiple models should generally be used together, and there
are common approaches that define when to use specific models in the
overall development life cycle.

27. Model Categorization
CHAPTER 2

28. Overview
System Model
Objectives Model
People Model
Data Model
Introduction
01
02
03
04
05

29. 01
Introduction
Data -> Program -> Process Data
-> Exit

30. Initially
01
In the early stages of software development,
models mainly focus on describing the system
structure and design process - from the
constructor/designer perspective.

31. Problem
01
• Not understanding real needs and business
context
• Ignoring some important requirements
related to users/business processes
• Maintenance and upgrade costs are higher
due to the lack of clear constraints from
the beginning

32. OPSD
01
• OPSD (objectives models, people models, systems models, and data models)

34. 01
What do you see
from that?

35. 01
Benefit from looking from multiple directions

36. 01
Bounding Model

37. Sumary Of benefit
01
Ensure the completeness of obtaining
requirements
Distill the best models for
each category
Easy tracking
Benefit 1 Benefit 3
Benefit 2

38. Objectives Model
02

39. Definition
02
Objectives models describe the business value of the system
01
02
03 Specific goals regarding functionality, performance, quality... need
to be achieved.
Mission/necessity for the system's existence.

40. Value of Objectives Model
02
Ensure the final system
developed meets the
original requirements.
Helps clearly define
the scope, limits and
priorities of the
project.
It is the basis for
building the remaining
models and ensuring the
connection between
them.

41. 2.3. PEOPLE MODEL

42. People models

43. People models
01
• Describe the stakeholders of the system,
business processes, and their goals
02
• Org Chart, Process Flow, Use Case, Roles
and Permissions Matrix
03
• The Org Chart is the bounding model for
the RML people models category

44. The Org Chart

45. 2.4. SYSTEM MODEL

46. Systems models
• Identify all of the major applications that participate in a multisystem
environment
• Describe specific aspects of the system

47. Systems models
• Ecosystem Map
• System Flow
• User Interface (UI) Flow
• Display Action Response Model
• Decision Tree
• Decision Table
• System Interface Table​

48. Ecosystem Map

49. 2.5. DATA MODEL

50. Data models
• Business Data Diagram (BDD)
• Data Flow Diagram (DFD)
• Data Dictionary
• State Diagram
• State Table
• State Diagram
• Report Table

51. Business Data Diagram (BDD)