Hvordan skriver man en god kravspecifikation? DAu konference den 28. august om projektstyring

Transcription

1 Hvordan skriver man en god kravspecifikation? DAu konference den 28. august om projektstyring Anders Vidstrup, Senior IT Quality SME, Quality & Security

2 Kort fortalt NNIT er en af Danmarks fire største leverandører af it-services Fokusområder: It-rådgivning, udvikling, implementering og drift til life sciences, finanssektoren, det offentlige og andre industrier Over medarbejdere Omsætning i 2011: DKK 1,8 mia. Hovedkontor i Søborg - kontorer i seks lande: Schweiz, Tjekkiet, Kina, Filippinerne og USA Kunder i det meste af Europa Datterselskab af Novo Nordisk A/S

3 Agenda Requirement specification Life-cycle approach Risk Assessment Design Review Link to test approach Slide 3

4 Requirement Specification The purpose of the requirement analysis is to gather sufficient information on what the customer wants the IT system to do, and to detail this into unique and specific requirements. Requirements MUST be: Uniquely identified Understandable Objectively verifiable IT system requirement analysis must take into consideration any relevant design or construction constraints, design and construction guidelines, standard components etc. Requirements to external and internal interfaces to the computer system should be identified. Equipment, other computer systems, interfaces between components of the computer system are all examples of such interfaces. Slide 4

5 Requirement Specification The IT system requirements should be reviewed to verify that the requirement fully covers the expressed customer needs and to assess whether the requirements are sufficiently unique, understandable, testable and objectively verifiable. Correctness Unambiguously Completeness Consistency Verifiability Slide 5

6 Life-cycle approach the GAMP concept In general the risk approach is based on: GAMP 5, appendix M3 GAMP Good Practise Guide: IT Infrastructure Control and Compliance Slide 6

7 Risk Assessment The purpose of this risk assessment is to estimate the regulatory risks in connection with implementing the system and to propose mitigations of these risks. In development gives input to: Design Test strategy Analyze of errors during test In operation Analyze of impact related to changes Analyze of errors, and consequences Slide 7

8 Risk Assessment - example Slide 8

9 Learnings when performing risk analysis An experienced facilitator is needed The dream team shall include development, operation, maintenance and QA Book at least 2 meetings (4-6 hours) Start the meeting with a small presentation of the approach All shall see what the facilitator writes in the risk analysis form (use a projector) Slide 9

10 Design phase The purpose of the design phase is to create a design for an IT system solution that ensures compliance with all relevant requirements and ensuring a well structured and operational design build on applicable standards. The process should: ensure adequate design of a solution which fulfils relevant requirements and follows applicable standards ensure design documentation that properly defines the selected solution and that can be approved by the customer. E.g. TDS, FDS or SS provide system developers with a better understanding of the structure to code provide system developers with a better understanding of the system requirements ensure a design that is implemental, operational and is of proper quality Slide 10

11 Design Review The IT system design must be reviewed to verify that the resulting design as described in the specification is suitable for fulfilling the requirements and for compliance with applicable standards and guidelines. The review can be conducted as a review workshop. The design review shall contain at least the following information: When review took place Participants in review Purpose of review Documents reviewed Findings of review Conclusion and a statement of whether the system design needs a further review The design-review shall take into account a traceability matrix between requirements in URS and SS / FDS / TDS. The design review shall be documented in an independent design review report or in an appendix to the system specification (FDS/TDS). Slide 11

12 TM Slide 12

13 Risk Assessment the usage The mitigation factors should be tested as a part of the qualification to verify, that they are implemented and the basis for the conclusion in the risk assessment is acceptable Slide 13 The risk assessment is made when the URS is nearly finish The mitigation factors should be controlled for implementation in design as a part of the design review P&Q VMP/ VPL URS FRS DS DER DDS Coding IQ PQ OQ V-Environment Integration Test Module/Unit Test Code Review D-Environment VMR/ VPR CR P-Environment, Use

14 The question. Kan kravsspecifikation overhovedet skrives færdig før designreview er gennemført? Svar: Der kan skrives en pre-liminær specifikation, der under design review gøres til en version 1, sammenholdt med risikoanalysen samt designmaterialet. Slide 14