Download - Workshop Borland - Caliber
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!