SAMPLE PROCESS - TEMPLATE

Click here to load reader

  • date post

    27-Jan-2015
  • Category

    Business

  • view

    109
  • download

    0

Embed Size (px)

description

SAMPLE PROCESS - TEMPLATE

Transcript of SAMPLE PROCESS - TEMPLATE

  • 1. PRODUCT DEVELOPMENT METHDOLOGYSOFTWARE REQUIREMENTSPROCESS PD-SE-PR-002 Copyright, Techserv Consulting 1

2. CHANGE HISTORYSRSR DATE DATE AUTHORAUTHOR VERSION VERSION REMARKS REMARKSNONO1 1 01-01-10 01-01-10 TECHSERVTECHSERV 1.0 1.0 FIRST RELEASE FIRST RELEASE Copyright, Techserv Consulting2 3. INTRODUCTION PURPOSE: PURPOSE:OBJECTIVES: OBJECTIVES: The Purpose of this document is to describe the The Purpose of this document is to describe the The objective of the Software Requirements process is toThe objective of the Software Requirements process is to SOFTWARE REQUIREMENTS process. SOFTWARE REQUIREMENTS process.translate the software requirements into a clear, welltranslate the software requirements into a clear, well formulated, and complete Software Requirementsformulated, and complete Software Requirements Specification Document and controlled and met throughoutSpecification Document and controlled and met throughout It covers process:It covers process: the product lifecycle.the product lifecycle. Objectives Objectives Scope ScopeA SRS has to establish the scope of the software systemA SRS has to establish the scope of the software system and identify interfaces with external systems, from the and identify interfaces with external systems, from the Abbreviations used Abbreviations usedcustomer's point of view. customer's point of view. InputsInputs Outputs Outputs SCOPE: SCOPE: Tools usage Tools usage This process applies to new product development projects This process applies to new product development projects Process Measurements and Metrics Process Measurements and Metrics Activities involved Activities involved ABBREVIATIONS: ABBREVIATIONS: Responsibilities ResponsibilitiesST Steering Committee ST Steering Committee Process aids Process aidsPDP Product Development Process PDP Product Development Process Process compliance indicators Process compliance indicators SRS Software Requirements Specification SRS Software Requirements Specification The process definition is providing both high level and The process definition is providing both high level and detailed process flow. To supplement the process flow detailed process flow. To supplement the process flow process aids such as Guidelines // Templates // Checklists // process aids such as Guidelines Templates Checklists Standards have been provided to improve process Standards have been provided to improve process understanding and implementation effectiveness understanding and implementation effectiveness Copyright, Techserv Consulting 3 4. INTRODUCTION Contd.. Requirements document states what the software will do. It does not state how the software will do it. Requirements document states what the software will do. It does not state how the software will do it.What the software does is directly perceived by its users either human users or other software systems. When a userWhat the software does is directly perceived by its users either human users or other software systems. When a user performs some action, the software responds in a particular way; when an external system submits a request of a certain form, itperforms some action, the software responds in a particular way; when an external system submits a request of a certain form, it gets a particular response. Therefore you and the users must agree on actions they can perform and response they shouldgets a particular response. Therefore you and the users must agree on actions they can perform and response they should expect. This common understanding is captured in the requirements document. How the software responds to the agreed uponexpect. This common understanding is captured in the requirements document. How the software responds to the agreed upon request is not addressed in the requirements document. For example, the requirements document does not include screenrequest is not addressed in the requirements document. For example, the requirements document does not include screen layouts, database schemas, descriptions of communication layers in short, no statements of design of any sort. For example,layouts, database schemas, descriptions of communication layers in short, no statements of design of any sort. For example, it is a requirement for a payroll application to be able to compute and report employee earnings. It is a design issue whether toit is a requirement for a payroll application to be able to compute and report employee earnings. It is a design issue whether to build a system to send security enabled pay slip delivery system to employee. Again it is a design issue how the privacy of thebuild a system to send security enabled pay slip delivery system to employee. Again it is a design issue how the privacy of the data will be met in the systemdata will be met in the systemThis is not to say you wont seek users input on some of the design, most especially on user interface design, but it is veryThis is not to say you wont seek users input on some of the design, most especially on user interface design, but it is very important to recognize and Why Bother with a Requirements Document?important to recognize and Why Bother with a Requirements Document?Respect the boundary between the statement of requirements and how requirements are implemented. Design is the Respect the boundary between the statement of requirements and how requirements are implemented. Design is the responsibility of the development team they should be free to choose the most appropriate way to satisfy all aspects of the responsibility of the development team they should be free to choose the most appropriate way to satisfy all aspects of the requirements features, performance, usability, etc. Usually the most appropriate way is the most simple way but sometimes requirements features, performance, usability, etc. Usually the most appropriate way is the most simple way but sometimes other considerations may affect design decisions such as opportunities for design or code reuse. other considerations may affect design decisions such as opportunities for design or code reuse. Copyright, Techserv Consulting4 5. PROCESS ARTIFACTS ENTRY CRITERA ENTRY CRITERAEXIT CRITERAEXIT CRITERA APPROVED PRODUCT REQUIREMENTSAPPROVED PRODUCT REQUIREMENTS APPROVAL OF SOFTWARE REQUIREMENTS APPROVAL OF SOFTWARE REQUIREMENTS INPUTS:INPUTS: OUTPUTS:OUTPUTS: PRODUCT REQUIREMENTS DOCUMENTPRODUCT REQUIREMENTS DOCUMENT DIRECT ARTIFACTS:DIRECT ARTIFACTS: REQUIREMENTS TRACEABLITY DOCUMENTREQUIREMENTS TRACEABLITY DOCUMENT SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTSIN-DIRECT ARTIFACTS: IN-DIRECT ARTIFACTS: REFERENCE DOCUMENTS: REFERENCE DOCUMENTS: SOFTWARE REQUIREMENTS STUDY NOTES SOFTWARE REQUIREMENTS STUDY NOTES INTEGRATED PROJECT PLAN INTEGRATED PROJECT PLAN REVIEW RECORDS REVIEW RECORDS CONTRACTCONTRACT MEETING MINUTES MEETING MINUTES REQUIREMENTS WORKING PAPERSREQUIREMENTS WORKING PAPERS PRODUCT REQUIREMENTS TRACEABILITY PRODUCT REQUIREMENTS TRACEABILITY MINUTES OF MEETINGMINUTES OF MEETING REQUIREMENTS GUIDLINESREQUIREMENTS GUIDLINES Copyright, Techserv Consulting5 6. PROCESS ARTIFACTS PROCESS MEASUREMENT: PROCESS MEASUREMENT:TOOLS, TO BE USED: TOOLS, TO BE USED: MS WORDMS WORD NUMBER OF REQUIREMENTS CATEGORYWISENUMBER OF REQUIREMENTS CATEGORYWISE MS EXCELMS EXCELo FUNCTIONAL o FUNCTIONALo NON-FUNCTIONAL o NON-FUNCTIONALo COMPLIANCE o COMPLIANCEo INTELLUCTUAL PROPERTY o INTELLUCTUAL PROPERTY TIME EXPENDED ON SOFTWARE REQUIREMENTSTIME EXPENDED ON SOFTWARE REQUIREMENTS TIME EXPENDED FOR REVIEWSTIME EXPENDED FOR REVIEWS TIME EXPENDED FOR REWORKTIME EXPENDED FOR REWORK SCHEDULED DELIVERY DATESCHEDULED DELIVERY DATE ACTUAL DELIVERY DATEACTUAL DELIVERY DATE PROCESS METRICS: PROCESS METRICS: TOTAL EFFORT ON THIS PROCESSTOTAL EFFORT ON THIS PROCESS TOTAL EFFORT ON REVIEWSTOTAL EFFORT ON REVIEWS TOTAL EFFORT ON REWORKTOTAL EFFORT ON REWORK DELIVERY COMMITMENTSDELIVERY COMMITMENTS Copyright, Techserv Consulting 6 7. PROCESS CONTEXTPRECEDING PROCESSPRECEDING PROCESS CURRENT PROCESSCURRENT PROCESS SUCCEEDING PROCESSSUCCEEDING PROCESS PD-SE-PR-001PD-SE-PR-001PD-SE-PR-002PD-SE-PR-002 PD-SE-PR-003 PD-SE-PR-003 PRODUCTPRODUCTSOFTWARE SOFTWARE HIGH LEVELHIGH LEVEL REQUIREMENTS REQUIREMENTSREQUIREMENTS REQUIREMENTS DESIGNDESIGN Copyright, Techserv Consulting 7 8. PROCESS FLOW SOFTWARE REQUIREMENTS PROCESS - OVERVIEW MANAGERCONFIG.REQUIREMENT IDENTIFYIDENTIFY UNDERSTA UNDERSTA WRITE WRITE ANALYZEANALYZEVALIDATE VALIDATEANALYST ND DEFINE DEFINE DESCRIBE DESCRIBEPLAN SRSPLAN SRSREQUIRMEREQUIRME ND SOFTWARESOFTWARESOFTWARE SOFTWARE SOFTWARESOFTWARE CUSTOME AND STATE AND STATE VERIFICATIO VERIFICATIOPROCESSPROCESS NTSNTS CUSTOME REQUIRME REQUIRME REQUIRMENREQUIRMEN REQUIRME REQUIRMER NEEDSPROBLEMS PROBLEMSN PROCESSN PROCESS (1)(1) SOURCES SOURCESR NEEDSNTSNTS TS TSNTSNTS(4) (4)(9) (9) (2)(2) (3) (3)(5) (5)(7) (7)(8) (8) COMMITTEESTEERINGRequirementsAs a The systemIt is imperativeThe This is theThe purpose A criticalAnalyst issignificant requirementsthat the Requirementsprocess of ofelement of the responsibleactivityRequirement Analyst mustunderstandingRequirementsrequirements must begin interact with thedevelopmentfor identifying Requirementswith a Analyst help and prioritizing Validation and customer to process is OVERVIEWa suitableAnalyst tothe customer requirements Review iscompletewrite the S/W describing the approach for identify to develop arequirements. and requirements tests, analysisgathering the sources ofunderstandinproblem determining athat areHe must involveor data that willrequirementsrequirements g of thestatement that the customer in technicalconsistent,be used to from the andcustomer's is completelythe process ofapproach for complete,provecustomer. techniques toneeds.independentdefining,testingrealistic, andcompliance of be used forof solutions clarifying, andrequirements.unambiguous.the final systemrequirements and specificprioritizing thewith its requir