Seminario Borland Caliber

V1.4 09/13

www.microfocus.it/risorse/#WebinarsBorland/

Connected DevelopmentEnvironment

Proactive change notification

Global teams collaborating

2

Connected DevelopmentEnvironment

Requirements management

Eliminates guessing

All teams on the same page

3

Functional & performance testing

Single point of truth

Analysis & management visibility

Connected DevelopmentEnvironment

4

Borland Solutions

5

Project Execution

Governance & Management

Services

Test Management

Func & Reg Testing

Perf &Load Testing

Dev. Testing

SilkCentral Test Manager

DevPartner Silk Test Silk Performer

Requirement Management

Requirement Definition Modeling

CALIBER AUTHOR

CALIBER VISUALIZE Together

Software Change & Configuration ManagementStarTeam

Data Masking & SubsettingData Express

Continuous Quality Assurance

Caliber: Requirements Engineering

7

Requirements Engineering Process

Functional Requirements

Business Requirements

Bu

sin

ess

UserRequirements

Quality Attributes

Use-Case Document

Business Rules

System Requirements

Functional Requirements

Software Requirements Specifications

External Interfaces

Constraints

Ser

vice

sD

evel

op

men

t

Vision and Scope Document

Design, Modeling and System Development

Qu

alit

y A

ssu

ran

ce Test Requirements

Test Plan

Test SpecificationSource Code

Standards

Req

uir

em

ents

En

gin

eeri

ng

Karl E. Wiegers – Software Requirements – Microsoft Press 2003

Non Functional Requirements

8

9

What is Requirements Management?

A continuous process of managing requirements from their inception to implementation and maintenance.Ensures a project meets end-user needs that are feasible and within approved project scope.

Establishes a common understanding of:• Business Requirements• User Requirements• Functional Requirements• Non Functional Requirements• Manages changes to those requirements

10

Traditional Requirements Approach

• Project focused - one time usage• Manage documents - requirements are contained

in documents that need to be managed• Document/Artifact creation - focus is more on

creating documents instead of defining the problem

• Limited change notification - manual and informal process

• Requirements are translated and interpreted many times

11

Problem: Traditional Requirements Approach

• Who owns or is responsible for this requirement?• What is its status, priority and feasibility

assessment?• Has this requirement changed? If so, who

changed it, when was it changed, what was changed and why was it changed? How were people notified?

• Where is the validation procedure for this requirement?

• Where does this requirement trace to and from? How does this enable quick and accurate requirements change management?

12

Solution: Requirements Management Approach

• Store requirements in a central repository where they can be communicated and collaborated on by the entire organization.

• Treat the requirements as a group of integrated, reusable artifacts or work products instead of a document.

• Capture requirements at their source instead of gathering and translating them from one source to another.

• Notify all stakeholders automatically any time a requirement changes.

13

Results of a Requirements Management Approach

• The Requirements Management Approach is an integrated process where all projects use the same process.

• Work products and artifacts are managed (not documents).• Requirements are reusable within and across projects.• Documents are the result of the process (instead of driving

the process).• Timely change notifications sent to all affected stakeholders.• Requirement capture and review cycles are minimized.• Effective and efficient impact analysis is available for

requirements changes.

Manage Requirements, Not Documents!Requirements Management Must Provide Lifecycle Traceability

14

Traceability is the key to compliance Initial requirements will be decomposed, which creates traceability relationships Other relationships can also be traced such as “consists of”, “verifies”, etc. Traceability must be enforced in order to ensure consistency and completeness

Traceability from customer requirements through product development to test and delivery enables organizations to: Know which requirements are implemented and tested vs. those which are not Manage and defend against scope creep

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements

1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Business Requirements

Users Requirements Test CasesFunctional

Requirements

Updated Technical InfrastructureNew Component Organization

New Authoring User Interface

New Visualization Capability Built-in

New Online Review Capability

New Agile Delivery Visibility

New Integration to Rally Agile

New MS TFS Work Item Integration

Newly Simplified Licensing Model

15

Well Formed Requirements

Author

VisualizeReview

Author: A rich full featured requirements authoring environment

Component Organization

Visualize: Visual business scenarios, storyboarding and interactive simulation via a browser interfaceReview: Web interface for

viewing Caliber requirements and visualizations, and providing collaborative feedback

16

Component Organization

17

Caliber AuthorRequirements Management

• A modern Windows authoring environment

• The new ribbon interface groups common user actions together in “context” for better usability

• Better integration between textual and visual requirements

18

Caliber VisualizeScenario Diagramming & Storyboarding

Caliber ReviewOnline Requirements Review/Discussion

• Enable all business stakeholders to be fully engaged and contributing

• Immediate visibility to discussions in requirement author and visualize clients

• Email-able links

• Tablet friendly

• Socializing requirements to create “well formed” requirements

• Web interface for viewing Caliber requirements and visualizations, and providing collaborative feedback

20

Caliber: Requirements Driven Software Testing

Requirements Driven Software Testing

It is possible to design tests based on requirements: it is the so called Requirements Based Software Testing.

We can obtain basically three categories of test based on requirements:

­ Functional Tests based on Functional Decomposition­ Test Scenarios based on Use Cases­ Non Functional Tests (performance, safety, etc.)

[1] Software Requirements, Second Edition (Karl E. Wiegers - Microsoft Press – ISBN 0735618798)

22

23

Functional Tests based of Functional Decomposition

24

Native/custom integrations

Test Scenarios based on Use Cases

25

Jim Heumann ‘Generating Test Cases from Use Cases

26

Test Scenarios based on Use Cases

27

Business IT Quality

Process Flow

28

Test Case Insight

Non Functional Tests: performance tests

29

30

Test non funzionali: test prestazionali

OPEN. AGILE. ENTERPRISE. SOFTWARE.

31

www.microfocus.it/risorse/#WebinarsBorland/

Case Study:Insurance Co.

http://demo.borland.com/InsuranceWebExtJS/

33

Case Study: Insurance Co.

Insurance Co. è una Compagnia di Assicurazioni Multinazionale con sede negli Stati Uniti che lavora prevalentemente attraverso Internet.

Il suo slogan è:“Our innovative approach as a leading insurance provider not only saves you time and money, it provides peace of mind. We have invested heavily in technology to bring you the very best in online services”.

 I servizi principali offerti da Insurance Co. sono: • Polizza Vita in ogni fase della vita dell’assicurato• Assicurazione Auto per l’intera famiglia• Assicurazione sulla Casa di proprietà • Assicurazione per gli Affittuari che copre ogni esigenza• Assicurazioni Speciali personalizzate

Un esempio del sito statunitense si può trovare all’indirizzo web:http://demo.borland.com/InsuranceWebExtJS/

34

Case Study: Insurance Co.Insurance Co. ha deciso di entrare nel mercato italiano delle polizze autofornendo un servizio via Internet.

Per fare questo ha aperto una serie di uffici in Italia e ha commissionato ad una società di outsourcing lo sviluppo del sito Internet www.insuranceco.it e dell’applicazione per fare la quotazione della propria polizza auto in piena autonomia.

Per la parte riguardante il “presentation layer” ha coinvolto dei web designer che hanno il compito di personalizzare il sito Internet secondo quelli che sono i template, i loghi, e le combinazioni di colori e gli standard della società americana che devono essere uguali a quelli del sito statunitense.

Per quanto riguarda l’applicazione ha commissionato alla nostra società lo sviluppo di due percorsi applicativi per la quotazione delle polizze auto.

Il primo percorso deve poter permettere una quotazione in tempi rapidissimi inserendo esclusivamente targa del veicolo e la data di nascita del proprietario.

Il secondo percorso prevede una compilazione più dettagliata dei dati da parte dell’utente che comprende dati relativi alla polizza, dati del veicolo, informazioni anagrafiche e dati del conducente per ottenere un preventivo.

35

Case Study: Insurance Co.Lo scopo del nostro Workshop è definire la struttura dei requisiti Business, User e Functional di tali percorsi oltre a definire una Simulazione dei due percorsi da mostrare al nostro committente per ottenere da lui la propria approvazione.

Partiremo dal primo percorso applicativo, per arrivare poi a sviluppare quanto possibile del secondo percorso applicativo.

L’obiettivo del workshop non è tanto ottenere un risultato concreto quanto stimolare una discussione di gruppo che porti al processo di definizione dei requisiti in questione.

Le figure in questione saranno degli analisti di business (Business Analysts) e degli analisti funzionali (Functional Analysts) nonché un coordinatore del gruppo (Requirements Manager) ed il cliente stesso (Customer).

Scopo del gruppo è anche sviluppare una serie di requisiti funzionali che dovranno essere passati da una parte al team di sviluppo e dall’altra al team di test (seconda edizione del nostro workshop) per mettere in pratica le indicazioni della disciplina del Requirements Driven Software Testing.

36

Buon lavoro!