#StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
Workshop on requirements and modeling at HAE 2015
1. RequirementsModeling in IT Projects
Modeling & Requirements in IT Projects
How to better understand and be understood?
By
July 6th 2015, Hellenic American Union
2. IT Projects RequirementsModeling
IT System
Organisation
Description
Realisation
Realisation
DescriptionRoadmap
3. A bit of background
1997 1999
Bachelor
Industrial &
Telecommunication
Computing
Rational
Software
2003
IBM
2005
Empulsys
Developer
Tools Specialist
RUP Consultant
Trainer
http://disciplinedagileconsortium.org/
Agile/UP Mentor
2015
4. Modeling -‐ What is it? What for?
Communication and understanding
over documentation and standards
(UML, BPMN,…)
HoldCold
Richness of the
communication
channel
Effectiveness of the
communication
Modeling
options
Documentation
options
Understand and be understood
Face-‐to-‐face
(whiteboard)
Face-‐to-‐face
(conversation)
Video
conversation
Phone
conversationEmail
conversation
Video
recording
Audio
recording
Paper
http://www.agilemodeling.com/
5. Modeling – Many techniques
http://www.agilemodeling.com/
Modeling
artefacts
Activity
diagram
Business
Rule
definition
Change
Case
Class
diagram
Class-‐Collaboration-‐
Responsibility cards
Data diagram
Component
diagram
Constraint
definition
Collaboration
diagrams
Deployment
diagram
Data flow
diagram
System User
Interfaces
(mockups)
External
Interface
Specification
Use Case
diagram
Essentials User
Interfaces
Feature
Flowchart
Organisation
chart
Robustness
diagram
Statechart
Sequence
diagram
Used to explore
use cases and
identify
controllers,
boundaries and
entities.
Used to explore the
conceptual model
Appropriate for OO
designs.
UML and BPMN are not
the only valid modeling
notations
Used to express the
design of systems
using Object-‐
Oriented concepts.
6. Customer End-user
Supplier
PM
P
SCM BM
Development
Test
Acceptance
Production
Process
Engineering
(Methodology)
Implementation
(Coding)
Testing
Change Request
Management
Project
Management
Deployment
Management
Software
Configuration
Management
PPM
Portfolio
Management
AD
I
T
DM
CRM
RDM
Build
Management
Product Owner
Analyst
Developer
BM
Business
Modeling
Tester
SCRUM Master
Project Manager
Requirements Specifier
Architect Owner
Software Architect
User Representative
System
Analysis and
Design
We have €€€.
You build
VALUE
We have
PROBLEMS.You
build SOLUTIONS
Team Members Requirements
Definition and
Management
Business Reprenetative
Modeling – Many opportunities
7. Requirements -‐ Refresh
• Requirements
• A condition or a capability a system must
conform to.
• A capacity required by a user to reach an
objective or solve a problem.
• Requirements (Definition and)
Management
• To come to an agreement with the customer and
the user on what the system should do.
• To give the development team better
understanding of the system requirements.
• Ensure that our customer interests are satisfied.
Requirements
What the system must do
How the system will do it
Solution
Problem space vs Solution space
Customer End-user
Supplier
RDM
8. http://www.empulsys.com/en/free-‐resources/94-‐frombusiness2systems
Information Families Modeling Concepts
A
Information describing “What” an
organization does and ”Why” the
organization needs to do so
à Business Use Case Model
B
Information describing “How” an
organization is (or should be) supported by an
IT environment and humans
à Business Object Model
C
Information describing “What” are the user
(human) needs in regard to an application
and ”Why” these user needs are important
à System Use Case Model, Use Case
Specifications, Supplementary
Specifications, Glossary, Vision
D
Information regarding “How” an application
is structured to offer a solution aligned on
user needs
à System Analysis/Design Model,
Software Architecture Document
E
All other information used/produced to
organize a project, monitor progress and
verify the quality of project outcome
à Project Plan, Test Plans, Tasks,
Test Cases,…
Problems & Contexts
Priorities
Planning
Software
Requirements
Software
Requirements
Progress
Impact
Inter-‐dependencies
between disciplines
<<candidate>>
<<candidate>>
Business Actor Business Use Case
Business Worker
Operation
<<candidate>>
<<candidate>>
Business Rule Business Entity
System Actor
System Use Case
<<implements>>
<<implements>>
EntityControllerBoundary
1
*
<<realizes>>
<<realizes>>
State Machine
<<implements>>
<<details>>
<<candidate>>
Scenario
OK
X
Test CaseTask
<<verifies>>
<<covers>>
Progress
Scope &
Business Values
Business
Case
Processes &
Objectives
PPM
BM
RDM
AD
T
BMDM SCM
P
Requirements – Are central
11. Understanding System Requirements (1/8)
I initiate
a deal
Other person
has an account?
Single payment
scheme?
Accept deal
conditions?
YES
NO
YES
YES
NO
NO
from to
As a trainer, I want to record
a new deal in the systemso
that the company which
requested the training accepts
my payment conditions.
1. The system retrieves the information about the deal
initiator (DI).
2. The system requests to provide the email address of
another member of the system.
3. The DI submits the email address of the other member.
4. The system verifies if the email address is known.
5. The system informs the DI that other member is known.
6. The system asks the DI to specify his/her role in the deal.
7. The system requests the DI to specify the product/service
subject of the deal, a reference (optional), a currency and
amount, a reckonable price date and a reckonable
amount date.
8. The DI enters the requested information.
9. …
End-User
Analyst
Specification
?
Example StoryDriven Modeling
Product Owner Team Members
12. Understanding System Requirements (2/8)
Controller. It represents something that
coordinates the behavior of the system
for a particular scenario.
Boundary. It represents something that
intermediates between the system and
the outside
Step #1: identify the controllers and boundaries
DEALINITIATIONCONTROLER
DEALINITIATIONINTERFACE
EMAILNOTIFCATIONSYSTEM
SHORTMESSAGESYSTEM
Interfaces to systems, devices, users are boundaries
13. Understanding System Requirements (3/8)
Step #2: Filter nouns from the scenario description
1. The system retrieves the information about the
deal initiator (DI).
deal initiator Information
2. The system requests to provide the email
address of another member of the system.
email address, (another) member
3. The DI submits the email address of the other
member.
email address, (other) member
4. The system verifies if the email address is known. email address
5. The system informs the DI that other member is
known.
(other) member
6. The system asks the DI to specify his/her role in
the deal.
role, deal
7. The system requests the DI to specify the
product/service subject of the deal, a reference
(optional), a currency and amount, a reckonable
price date and a reckonable amount date.
product/service, deal subject,
reference, currency, amount,
(reckonable) price date, (reckonable)
amount date
8. The DI enters the requested information. (requested) information
9. The system asks for the number of payments. number, payments
Be caution with references to actors (will
be addressed through boundaries)
Ignore operations (e.g. “the processing”,
particularity of english).
Ignore synonyms, duplicates.
14. Understanding System Requirements (4/8)
Step #3: Create list of candidate entities
Entity. It represents a key abstraction of
the system.
SHORTMESSAGEEMAILNOTIFICATION
DEALINITIATIORINFO
-‐ role
DEALPARTICIPANTINFO
-‐ email address
-‐ role
DEAL
-‐ buyer
-‐ seller
-‐ currency
-‐ amount
-‐ reckonable price date
-‐ reckonable amount date
-‐ official amount
-‐ unique deal number
-‐ status
PRODUCT
-‐ description
-‐ reference
-‐ status
PAYMENT
-‐ scheme
16. Understanding System Requirements (6/8)
Step #5: Identify required interactions
DEALPARTICIPANTINFO
DEAL
DEALINITIATIORINFO
PRODUCT
MEMBERLIST
DEALINITIATIONCONTROLER
DEALINITIATIONINTERFACE
Deal
Initiator
2. Ask Email Other Member
3. Check Existence Other Member
11. Present Other Member Details
13. Ask Role And Deal Details
14. Set Deal Settings
25. Ask Payment Scheme
26. Set Payment Scheme
1. Get Deal Initiator Info
4. Get Other Member ID
5. Find Other Member Email
12. Get Product Specifications
24. Get Payment Scheme
16. Get Member ID
15. Set Seller
17. Set Buyer
19. Set Product Description
21. Set Product Reference
23. Set Amount and Currency
…
6. Find Member by Email
7. Get Member Details
8. Get Member ID
9. Get First Name
10. Get Last Name
18. Get Member ID
DEALINITIATIORINFO
DEALINITIATIONINTERFACE
MEMBERLIST
DEALINITIATIONCONTROLLER
DEALINITIATIONCONTROLLER
-
-
-
-
-
DEALINITIATORINFO
DEALPARTICIPANTINFO
PRODUCT
PRODUCT
-
20. Set Description
22. Set Reference
-
-
-
-
-
-
-
DEALPARTCIPANTINFO
Product Owner Team Members
New
Class-‐Collaboration-‐Responsibility cards modeling artefact
17. Understanding System Requirements(7/8)
Step #6: Identify required classes, operations and attributes
DEALINITIATIONINTERFACE
AskEmailOtherMember()
CheckMemberExistence()
PresentMemberDetails()
AskRole()
AskDealDetails()
RecordDealSettings()
AskPaymentScheme()
SetPaymentScheme()
DEAL
SetSeller(Member)
SetBuyer(Member)
SetProductDetails(description, reference)
SetDealAmountAndCurrency()
amount
currency
PRODUCT
SetDescription()
SetReference()
description
reference
MEMBER
GetID()
GetFirstName()
GetLastName()
GetEmail()
id
Lastname
Firstname
email
MEMBERLIST
FindMemberByEmail(email)
DEALINITIATIONCONTROLLER
GetDealInitiator(): Member
GetDealParticipant(): Member
GetDealDetails(): Deal
GetFinancialConditions()
1
1
1
1
1
0..*
0..*
Team Members
Can we have members
in the system not
involved in any deal?
Can members be
involved in several
deals? If so, any limits?
Product Owner
0..*
1
Class diagram modeling artefact
18. Understanding System Requirements(8/8)
Step #7: Identify candidate development activities
As a trainer, I want to record a new deal in the system so
that the company which requested the training accepts
my payment conditions.
We need to build a user interface that will allow a
member:
-‐ to find and see details of another user
-‐ to get the role of the member (cfr. ”trainer” -‐>
“seller”)
-‐ to get the details of the deal (product, etc)
-‐ to get the financial conditions
We need to build some logic that will:
-‐ Create deals and products
-‐ Associate members to deals
We need to build “services” that will:
-‐ Handle the members
-‐ Find members
-‐ Handle deals and products
Team MembersDeveloper
19. Hands-‐on – Your turn!!
Inputs
• Scenario for the initiation of a deal
• Scenario for the management of sell
• Scenario for the management of a purchase
Outputs
• List of entities, boundaries, controllers
• CRC sessions
• Overall class diagram
• Summary of activities
Steps
#1: identify the controllers and boundaries
#2: Filter nouns from the scenario description
#3: Create list of candidate entities
#4: Prepare your Class-‐Responsibilities-‐Collaboration cards
#5: Identify required interactions
#6: Identify required classes, operations and attributes
#7: Identify candidate development activities
22. By the way…
Modeling
applied toSystem Organisation (Business)
Business Use Cases describe what
the business delivers from an
external perspective
Following elements are used to
describe how business processes
are performed
Static:
Business Workers
Business Entities
Business Systems
Dynamic:
Business Use Case Realizations
Static:
Business Actors
Business Use Cases
Dynamic:
Business Use Case Descriptions
System Use Cases describe what a
system will offer to people/system
interacting with
Following elements are used to
describe how system use cases
are realised
Static:
Boundaries
Entities
Controllers
Dynamic:
Use Case Realizations
Static:
Actors
Use Cases
Dynamic:
Use Case Descriptions
Modeling an Information System-‐ Describing it from the
outside (screens, interactions, capabilities, deployment) and
from the inside (data, logic, structure)
Modeling an Organisation–Describing it from the
outside (partners/providers, services, qualities) and from
the inside (people, information, systems)
Class-‐Collaboration-‐
Responsibility cards
Class
diagram
Class
diagram
Activity diagrams
23. Business Modeling – Some key concepts
Business Worker. It represents a role within the
business/organisation. It can be a human or a
system inside the organisation. Interacts with
other business workers and with business entities
Business Entity. It represents a piece of
information manipulated by business
workers. Has relationships with other
business entities
Business System. It represents an independent
capability within an organisation. Is used to
structure the organisation in manageable chunks
and understand it. It binds and contain roles and
resources
1
1
*
*
24. 1. Depicting
the context
2. Claryfing involved
units/people (stakeholders)
3. Drafting the
situation (who, why)
Business Modeling – Concrete application
2h effort
25. Business Modeling – Importance of Doing It
Conflicting requirements from users.
The broader context of the system is not well
understood.
Difficulty baselining the requirements.
No understanding of the relationship between the
scope of work and the business’ goals.
Customers/Users continuously change
their mind.
No clear idea of the problem they are trying to solve
in relation to the business’ objectives.
Solve the wrong problem.
No understanding of the relationship between the scope of
work, the business’ goals, and impact to business processes
Users get what they asked for but it turns out
it is not what they needed.
No understanding of the relationship between the scope of
work, the business’ goals and impact to business processes
Solutions deliver little or no value.
No understanding of the relationship between the scope of
work, the business’ goals, and the obstacles to those goals.
Difficulty deploying solution into business
process.
The broader context of the system is not well understood.
No system is an island into itself
Address root causes
behind the symptoms
