workshop on requirements and modeling at hae 2015

RequirementsModeling in IT Projects

Modeling & Requirements in IT ProjectsHow to better understand and be understood?

By

July 6th 2015, Hellenic American Union

IT Projects RequirementsModeling

IT System

Organisation

Description

Realisation

Realisation

DescriptionRoadmap

A bit of background

1997 1999BachelorIndustrial &

Telecommunication Computing

Rational Software

2003IBM

2005Empulsys

Developer

Tools SpecialistRUP Consultant

Trainer

http://disciplinedagileconsortium.org/

Agile/UP Mentor

2015

Modeling -‐ What is it? What for?

Communication and understandingover documentation and standards

(UML, BPMN,…)

HoldCold

Richness of the communication channel

Effectiveness of the communication

Modeling options

Documentation options

Understand and be understoodFace-‐to-‐face (whiteboard)

Face-‐to-‐face (conversation)

Video conversation

Phone conversationEmail

conversation

Video recording

Audio recording

Paper

http://www.agilem

odeling.com/

Modeling – Many techniques

http://www.agilem

odeling.com/

Modeling artefacts

Activity diagram

Business Rule

definitionChange 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

Organisationchart

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.

Customer End-user

Supplier

PM

P

SCM BM

Development

Test

Acceptance

Production

Process Engineering

(Methodology)

Implementation(Coding)

TestingChange Request

Management

ProjectManagement

DeploymentManagement

Software Configuration Management

PPM

PortfolioManagement

AD

I

TDM

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 RequirementsDefinition and Management

Business Reprenetative

Modeling – Many opportunities

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.

RequirementsWhat the system must do

How the system will do itSolution

Problem space vs Solution space

Customer End-user

SupplierRDM

http://www.empulsys.com/en/free-‐resources/94-‐frombusiness2systems

Information Families Modeling Concepts

AInformation describing “What” an organization does and ”Why” the

organization needs to do so à Business Use Case Model

BInformation describing “How” an

organization is (or should be) supported by an IT environment and humansà Business Object Model

CInformation 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

DInformation regarding “How” an application is structured to offer a solution aligned on

user needsà System Analysis/Design Model, Software Architecture Document

EAll 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 WorkerOperation <<

candidate>>

<<candidate>>

Business Rule Business Entity

System ActorSystem Use Case

<<implements>>

<<implem

ents>>

EntityControllerBoundary

1

*

<<real

izes>>

<<realizes>>

State Machine

<<implem

ents>>

<<details>>

<<candidate>>

Scenario

OKXTest CaseTask

<<verifies>>

<<covers>>

Progress

Scope & Business Values

Business Case

Processes & Objectives

PPM

BM

RDM

ADT

BMDM SCMP

Requirements – Are central

Part 1: Modeling and System Requirements

Hands-‐on – Understanding System Requirements

from to

How ?

REFINE

D

Understanding System Requirements (1/8)

I initiate a deal

Other person has an account?

Single payment scheme?

Accept deal conditions?

YES

NOYES

YESNO

NO

from to

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.

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 Story Driven Modeling

Product Owner Team Members

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

SHORTMESSAGESYSTEMInterfaces to systems, devices, users are boundaries

Understanding System Requirements (3/8)Step #2: Filter nouns from the scenario description

1. The system retrieves the information about thedeal 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.

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

Understanding System Requirements (5/8)Step #4: Prepare your Class-‐Responsibilities-‐Collaboration cards

DEALPARTICIPANTINFO

A4

SHORTMESSAGE

DEAL

EMAILNOTIFICATION

DEALINITIATIORINFO

PRODUCT

PAYMENT


SHORTMESSAGESYSTEM


EMAILNOTIFICATIONSYSTEM

Understanding System Requirements (6/8)Step #5: Identify required interactions

DEALPARTICIPANTINFO

DEAL

DEALINITIATIORINFO

PRODUCT

MEMBERLIST



Deal Initiator

2. Ask Email Other Member3. Check Existence Other Member11. Present Other Member Details13. Ask Role And Deal Details14. Set Deal Settings25. Ask Payment Scheme26. Set Payment Scheme

1. Get Deal Initiator Info4. Get Other Member ID5. Find Other Member Email12. Get Product Specifications24. Get Payment Scheme

16. Get Member ID

15. Set Seller17. Set Buyer19. Set Product Description21. Set Product Reference23. Set Amount and Currency…

6. Find Member by Email7. Get Member Details

8. Get Member ID9. Get First Name10. Get Last Name18. Get Member ID

DEALINITIATIORINFODEALINITIATIONINTERFACEMEMBERLIST

DEALINITIATIONCONTROLLERDEALINITIATIONCONTROLLER-----

DEALINITIATORINFODEALPARTICIPANTINFOPRODUCTPRODUCT-

20. Set Description22. Set Reference -

---

--

-DEALPARTCIPANTINFO

Product Owner Team Members

New

Class-‐Collaboration-‐Responsibility cardsmodeling artefact

Understanding System Requirements (7/8)Step #6: Identify required classes, operations and attributes


AskEmailOtherMember()CheckMemberExistence()PresentMemberDetails()AskRole()AskDealDetails()RecordDealSettings()AskPaymentScheme()SetPaymentScheme()

DEAL

SetSeller(Member)SetBuyer(Member)SetProductDetails(description, reference)SetDealAmountAndCurrency()

amountcurrency

PRODUCT

SetDescription()SetReference()

descriptionreference

MEMBER

GetID()GetFirstName()GetLastName()GetEmail()

idLastnameFirstnameemail

MEMBERLIST

FindMemberByEmail(email)DEALINITIATIONCONTROLLER

GetDealInitiator(): MemberGetDealParticipant(): MemberGetDealDetails(): DealGetFinancialConditions()

1

11

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 diagrammodeling artefact

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

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

Part 2: Modeling and Business Requirements

Insight – Understanding business requirements

from to

How ?

REVISIT

ED

By the way…Modelingapplied toSystem Organisation (Business)

Business Use Cases describe whatthe business delivers from an external perspective

Following elements are used to describe how business processes are performed

Static:Business WorkersBusiness EntitiesBusiness Systems

Dynamic:Business Use Case Realizations

Static:Business ActorsBusiness Use Cases

Dynamic:Business Use Case Descriptions

System Use Cases describe what asystem will offer to people/system interacting with

Following elements are used to describe how system use cases are realised

Static:BoundariesEntitiesControllers

Dynamic:Use Case Realizations

Static:ActorsUse 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

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

*

*

1. Depicting the context

2. Claryfing involved units/people (stakeholders)

3. Drafting the situation (who, why)

Business Modeling – Concrete application

2h effort

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 itselfAddress root causes

behind the symptoms

Thank You!@olivierbeghain

workshop on requirements and modeling at hae 2015

Technology