SAMPLE PROCESS - TEMPLATE

5,234 views

Published on

SAMPLE PROCESS - TEMPLATE

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,234
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
182
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SAMPLE PROCESS - TEMPLATE

  1. 1. PRODUCT DEVELOPMENT METHDOLOGY SOFTWARE REQUIREMENTS PROCESS PD-SE-PR-002 © Copyright, Techserv Consulting 1
  2. 2. CHANGE HISTORY SR SR DATE DATE AUTHOR AUTHOR VERSION VERSION REMARKS REMARKS NO NO 1 1 01-01-10 01-01-10 TECHSERV TECHSERV 1.0 1.0 FIRST RELEASE FIRST RELEASE © Copyright, Techserv Consulting 2
  3. 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 to The objective of the Software Requirements process is to “SOFTWARE REQUIREMENTS” process. “SOFTWARE REQUIREMENTS” process. translate the software requirements into a clear, well translate the software requirements into a clear, well formulated, and complete Software Requirements formulated, and complete Software Requirements Specification Document and controlled and met throughout Specification Document and controlled and met throughout It covers process: It covers process: the product lifecycle. the product lifecycle. •• Objectives Objectives •• Scope Scope A SRS has to establish the scope of the software system A 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 used customer's point of view. customer's point of view. •• Inputs Inputs •• 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 Responsibilities ST –Steering Committee ST –Steering Committee •• Process aids Process aids PDP – 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. 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 user What 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, it performs 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 should gets 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 upon expect. 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 screen request 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 to it 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 the build 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 system data will be met in the system This is not to say you won’t seek users’ input on some of the design, most especially on user interface design, but it is very This is not to say you won’t 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 Consulting 4
  5. 5. PROCESS ARTIFACTS ENTRY CRITERA ENTRY CRITERA EXIT CRITERA EXIT CRITERA •• APPROVED PRODUCT REQUIREMENTS APPROVED PRODUCT REQUIREMENTS •• APPROVAL OF SOFTWARE REQUIREMENTS APPROVAL OF SOFTWARE REQUIREMENTS INPUTS: INPUTS: OUTPUTS: OUTPUTS: •• PRODUCT REQUIREMENTS DOCUMENT PRODUCT REQUIREMENTS DOCUMENT DIRECT ARTIFACTS: DIRECT ARTIFACTS: •• REQUIREMENTS TRACEABLITY DOCUMENT REQUIREMENTS TRACEABLITY DOCUMENT •• SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS IN-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 •• CONTRACT CONTRACT •• MEETING MINUTES MEETING MINUTES •• REQUIREMENTS WORKING PAPERS REQUIREMENTS WORKING PAPERS •• PRODUCT REQUIREMENTS TRACEABILITY PRODUCT REQUIREMENTS TRACEABILITY •• MINUTES OF MEETING MINUTES OF MEETING •• REQUIREMENTS GUIDLINES REQUIREMENTS GUIDLINES © Copyright, Techserv Consulting 5
  6. 6. PROCESS ARTIFACTS PROCESS MEASUREMENT: PROCESS MEASUREMENT: TOOLS, TO BE USED: TOOLS, TO BE USED: •• MS – WORD MS – WORD •• NUMBER OF REQUIREMENTS CATEGORYWISE NUMBER OF REQUIREMENTS CATEGORYWISE •• MS – EXCEL MS – EXCEL o FUNCTIONAL o FUNCTIONAL o NON-FUNCTIONAL o NON-FUNCTIONAL o COMPLIANCE o COMPLIANCE o INTELLUCTUAL PROPERTY o INTELLUCTUAL PROPERTY •• TIME EXPENDED ON SOFTWARE REQUIREMENTS TIME EXPENDED ON SOFTWARE REQUIREMENTS •• TIME EXPENDED FOR REVIEWS TIME EXPENDED FOR REVIEWS •• TIME EXPENDED FOR REWORK TIME EXPENDED FOR REWORK •• SCHEDULED DELIVERY DATE SCHEDULED DELIVERY DATE •• ACTUAL DELIVERY DATE ACTUAL DELIVERY DATE PROCESS METRICS: PROCESS METRICS: •• TOTAL EFFORT ON THIS PROCESS TOTAL EFFORT ON THIS PROCESS •• TOTAL EFFORT ON REVIEWS TOTAL EFFORT ON REVIEWS •• TOTAL EFFORT ON REWORK TOTAL EFFORT ON REWORK •• DELIVERY COMMITMENTS DELIVERY COMMITMENTS © Copyright, Techserv Consulting 6
  7. 7. PROCESS CONTEXT PRECEDING PROCESS PRECEDING PROCESS CURRENT PROCESS CURRENT PROCESS SUCCEEDING PROCESS SUCCEEDING PROCESS PD-SE-PR-001 PD-SE-PR-001 PD-SE-PR-002 PD-SE-PR-002 PD-SE-PR-003 PD-SE-PR-003 PRODUCT PRODUCT SOFTWARE SOFTWARE HIGH LEVEL HIGH LEVEL REQUIREMENTS REQUIREMENTS REQUIREMENTS REQUIREMENTS DESIGN DESIGN © Copyright, Techserv Consulting 7
  8. 8. PROCESS FLOW SOFTWARE REQUIREMENTS PROCESS - OVERVIEW MANAGER CONFIG. REQUIREMENT IDENTIFY IDENTIFY UNDERSTA UNDERSTA WRITE WRITE ANALYZE ANALYZE VALIDATE VALIDATE ANALYST ND DEFINE DEFINE DESCRIBE DESCRIBE PLAN SRS PLAN SRS REQUIRME REQUIRME ND SOFTWARE SOFTWARE SOFTWARE SOFTWARE SOFTWARE SOFTWARE CUSTOME AND STATE AND STATE VERIFICATIO VERIFICATIO PROCESS PROCESS NTS NTS CUSTOME REQUIRME REQUIRME REQUIRMEN REQUIRMEN REQUIRME REQUIRME R NEEDS PROBLEMS PROBLEMS N PROCESS N PROCESS (1) (1) SOURCES SOURCES R NEEDS NTS NTS TS TS NTS NTS (4) (4) (9) (9) (2) (2) (3) (3) (5) (5) (7) (7) (8) (8) COMMITTEE STEERING Requirements As a The system It is imperative The This is the The purpose A critical Analyst is significant requirements that the Requirements process of of element of the responsible activity Requirement Analyst must understanding Requirements requirements must begin interact with the development for identifying Requirements with a Analyst help and prioritizing Validation and customer to process is OVERVIEW a suitable Analyst to the customer requirements Review is complete write the S/W describing the approach for identify to develop a requirements. and requirements tests, analysis gathering the sources of understandin problem determining a that are He must involve or data that will requirements requirements g of the statement that the customer in technical consistent, be used to from the and customer's is completely the process of approach for complete, prove customer. techniques to needs. independent defining, testing realistic, and compliance of be used for of solutions clarifying, and requirements. unambiguous. the final system requirements and specific prioritizing the with its requirements. requirements. gathering technologies. © Copyright, Techserv Consulting 8
  9. 9. PROCESS FLOW SOFTWARE REQUIREMENTS PROCESS - OVERVIEW MANAGER CONFIG. BASLINE BASLINE SRS SRS (11) (11) REQUIREMENT UPDATE UPDATE ANALYST CONDUCT CONDUCT TRACEABI TRACEABI FORMAL FORMAL LITY LITY REVIEW REVIEW MATRIX MATRIX (11) (11) (10) (10) CORE TEAM MEMBERS Traceability The reviews Configuratio matrix acts should be held n Manager to as a map, periodically to ensure that providing the ensure the approved adequacy and DETAILS links SRS completeness necessary of baselined for tracing requirements, and brought the by obtaining under formal requirements feedback change horizontally / about them management vertically from relevant process stakeholders. © Copyright, Techserv Consulting 9
  10. 10. DETAILED DESCRIPTION PLAN PLAN The Requirements Analyst in association with Team Members is responsible for identifying a suitable The Requirements Analyst in association with Team Members is responsible for identifying a suitable SOFTWARE approach for gathering the requirements from the customer. The project manger should also identify approach for gathering the requirements from the customer. The project manger should also identify SOFTWARE REQUIRMENTS suitable elicitation techniques that should be adopted for getting the needs. The supporting tools that suitable elicitation techniques that should be adopted for getting the needs. The supporting tools that REQUIRMENTS would be used like checklists, sample software demos etc., should be identified before commencing the would be used like checklists, sample software demos etc., should be identified before commencing the PROCESS PROCESS requirements study. The Requirements Analyst should identify, plan, estimate and schedule all the requirements study. The Requirements Analyst should identify, plan, estimate and schedule all the (1) (1) tasks associated with the Requirements engineering process and the work Products associated with the tasks associated with the Requirements engineering process and the work Products associated with the process. The Requirements Analyst should also plan for the resources required for this process. process. The Requirements Analyst should also plan for the resources required for this process. PROCESS FLOW © Copyright, Techserv Consulting 10
  11. 11. DETAILED DESCRIPTION As a first activity for requirements specification process is to identify various stakeholder and sources As a first activity for requirements specification process is to identify various stakeholder and sources IDENTIFY IDENTIFY of requirements: of requirements: SOURCES OF SOURCES OF REQUIRMENTS REQUIRMENTS Sources of Requirements could be: Sources of Requirements could be: (2) (2) •• User Needs Document User Needs Document •• Interview with Users Interview with Users •• Interviews with Management Interviews with Management •• Voluntary Standards Voluntary Standards •• Product classification Product classification •• Market and competitive analysis Market and competitive analysis •• Statutory, regulatory requirements and compliance strategies Statutory, regulatory requirements and compliance strategies •• Complaints/Failures and other historical data Complaints/Failures and other historical data •• Risk analysis Risk analysis •• Product documentation Product documentation •• Human factors studies Human factors studies As the project matures and requirements are derived, all activities or disciplines will receive As the project matures and requirements are derived, all activities or disciplines will receive requirements. To avoid requirements creep, criteria are established to designate appropriate channels, requirements. To avoid requirements creep, criteria are established to designate appropriate channels, or official sources, from which to receive requirements. The receiving activities conduct analyses of the or official sources, from which to receive requirements. The receiving activities conduct analyses of the requirements with the requirements provider to ensure that a compatible, shared understanding is requirements with the requirements provider to ensure that a compatible, shared understanding is reached on the meaning of the requirements. The result of this analysis and dialog is an agreed-to set of reached on the meaning of the requirements. The result of this analysis and dialog is an agreed-to set of requirements. requirements. The first step in developing requirements is to identify the customer. The term customer The first step in developing requirements is to identify the customer. The term customer includes anyone who has a right to impose requirements on the system. This includes end users, includes anyone who has a right to impose requirements on the system. This includes end users, operators, nurses, clinicians, regulatory agencies, accountants, sponsors, etc. All facets of the operators, nurses, clinicians, regulatory agencies, accountants, sponsors, etc. All facets of the customer must be kept in mind during software requirements process. customer must be kept in mind during software requirements process. PROCESS FLOW © Copyright, Techserv Consulting 11
  12. 12. DETAILED DESCRIPTION The system design must begin with a complete understanding of the customer's needs. The information The system design must begin with a complete understanding of the customer's needs. The information UNDERSTAND UNDERSTAND necessary to begin a design usually comes from preliminary studies and specific customer requests. necessary to begin a design usually comes from preliminary studies and specific customer requests. CUSTOMER CUSTOMER Frequently the customer is not aware of the details of what is needed. Requirements Analyst must enter Frequently the customer is not aware of the details of what is needed. Requirements Analyst must enter NEEDS NEEDS the customer's environment, discover the details, and explain them. Flexible designs and rapid the customer's environment, discover the details, and explain them. Flexible designs and rapid (3) (3) prototyping facilitate identification of details that might have been overlooked. Talking to the customer's prototyping facilitate identification of details that might have been overlooked. Talking to the customer's customer and the supplier's supplier can also be useful. This activity is frequently referred to as mission customer and the supplier's supplier can also be useful. This activity is frequently referred to as mission analysis. analysis. It is the Requirements Analyst's responsibility to ensure that all information concerning the customer's It is the Requirements Analyst's responsibility to ensure that all information concerning the customer's needs is collected. The Requirements Analyst must also ensure that the definitions and terms used have needs is collected. The Requirements Analyst must also ensure that the definitions and terms used have the same meaning for everyone involved. Several direct interviews with the customer are necessary to the same meaning for everyone involved. Several direct interviews with the customer are necessary to ensure that all of the customer's needs are stated and that they are clear and understandable. The ensure that all of the customer's needs are stated and that they are clear and understandable. The customer might not understand the needs; he may be responding to someone else's requirements. customer might not understand the needs; he may be responding to someone else's requirements. PROCESS FLOW © Copyright, Techserv Consulting 12
  13. 13. DETAILED DESCRIPTION What is the problem we are trying to solve? Answering this question is one of the Requirements What is the problem we are trying to solve? Answering this question is one of the Requirements DEFINE AND DEFINE AND Analyst's most important and often overlooked tasks. An elegant solution to the wrong problem is less Analyst's most important and often overlooked tasks. An elegant solution to the wrong problem is less STATE STATE than worthless. than worthless. PROBLEMS PROBLEMS (4) (4) Early in the process, the customer frequently fails to recognize the scope or magnitude of the problem Early in the process, the customer frequently fails to recognize the scope or magnitude of the problem that is to be solved. The problem should not be described in terms of a perceived solution. It is that is to be solved. The problem should not be described in terms of a perceived solution. It is imperative that the Requirements Engineer help the customer develop a problem statement that is imperative that the Requirements Engineer help the customer develop a problem statement that is completely independent of solutions and specific technologies. Solutions and technologies are, of completely independent of solutions and specific technologies. Solutions and technologies are, of course, important; however, there is a proper place for them later in the Product development process. course, important; however, there is a proper place for them later in the Product development process. It is the Requirements Analyst's responsibility to work with the customer, asking the questions It is the Requirements Analyst's responsibility to work with the customer, asking the questions necessary to develop a complete "picture" of the problem and its scope. necessary to develop a complete "picture" of the problem and its scope. PROCESS FLOW © Copyright, Techserv Consulting 13
  14. 14. DETAILED DESCRIPTION The Requirements Analyst must interact with the customer to write the system requirements. The The Requirements Analyst must interact with the customer to write the system requirements. The WRITE WRITE Requirements Analyst must involve the customer in the process of defining, clarifying, and prioritizing Requirements Analyst must involve the customer in the process of defining, clarifying, and prioritizing SOFTWARE SOFTWARE the requirements. It is prudent to involve users, regulators, manufacturers, maintainers, and other key the requirements. It is prudent to involve users, regulators, manufacturers, maintainers, and other key REQUIRMENTS REQUIRMENTS stake-holders in the process. stake-holders in the process. (5) (5) Next, Requirements Engineering process must discover the functions that the system must perform in Next, Requirements Engineering process must discover the functions that the system must perform in order to satisfy its purpose. The system functions form the basis for dividing the system into order to satisfy its purpose. The system functions form the basis for dividing the system into subsystems. Although this makes it sound as if requirements are transformed into functions in a serial subsystems. Although this makes it sound as if requirements are transformed into functions in a serial manner, that is not the case. It is actually a parallel and iterative process. First we look at software manner, that is not the case. It is actually a parallel and iterative process. First we look at software requirements, then at software functions. Then we re-examine the requirements and then re-examine the requirements, then at software functions. Then we re-examine the requirements and then re-examine the functions. Then we re-assess the requirements and again the functions, etc. functions. Then we re-assess the requirements and again the functions, etc. PROCESS FLOW © Copyright, Techserv Consulting 14
  15. 15. DETAILED DESCRIPTION The Requirements Analyst must interact with the customer to write the software requirements. The The Requirements Analyst must interact with the customer to write the software requirements. The ANALYZE ANALYZE software requirements that are gathered and documented in the Software Requirements Specification software requirements that are gathered and documented in the Software Requirements Specification SOFTWARE SOFTWARE should be analyzed further to identify any implied requirements. All the derived requirements should should be analyzed further to identify any implied requirements. All the derived requirements should REQUIRMENTS REQUIRMENTS also be documented. During the analysis of requirements, the relationships between the various also be documented. During the analysis of requirements, the relationships between the various (6) (6) requirements should also be identified. The mechanism of implementing the requirements namely, requirements should also be identified. The mechanism of implementing the requirements namely, through software, hardware, processes, services and documentation should be identified through software, hardware, processes, services and documentation should be identified During the requirement analysis, the operational concept and scenarios are identified. Operational During the requirement analysis, the operational concept and scenarios are identified. Operational concept refers to the Methods of how the system will be developed, deployed, operated, maintained and concept refers to the Methods of how the system will be developed, deployed, operated, maintained and disposed. It has the viewpoints of different stakeholders of the system namely, customer, architects, disposed. It has the viewpoints of different stakeholders of the system namely, customer, architects, developer, tester, maintainer, operator, end users. Operational concept should integrate the system life developer, tester, maintainer, operator, end users. Operational concept should integrate the system life cycle scenarios into a timeline behavior that satisfies the viewpoint of each stakeholder. The outcome cycle scenarios into a timeline behavior that satisfies the viewpoint of each stakeholder. The outcome of this analysis will also provide additional requirements which should be included in the Software of this analysis will also provide additional requirements which should be included in the Software Requirements Specification. Requirements Specification. The risks on cost, schedule, functionality, design and performance should also be assessed and The risks on cost, schedule, functionality, design and performance should also be assessed and documented for project risk mitigation and tracking. documented for project risk mitigation and tracking. All communications and documentation (including hard-copies) related with the requirements gathering All communications and documentation (including hard-copies) related with the requirements gathering and analysis process should be maintained. and analysis process should be maintained. Requirements could be classified as Stated, Implied and Derived requirements. Stated requirements are Requirements could be classified as Stated, Implied and Derived requirements. Stated requirements are those, which are explicitly communicated by the requirement providers during the requirement- those, which are explicitly communicated by the requirement providers during the requirement- gathering phase. Implied requirements are the needs about the system/product in the minds of the gathering phase. Implied requirements are the needs about the system/product in the minds of the requirement provider but not explicitly stated. Such implied requirements should also be recognized requirement provider but not explicitly stated. Such implied requirements should also be recognized and documented. Derived requirements are those requirements that are identified during the analysis of and documented. Derived requirements are those requirements that are identified during the analysis of requirements. requirements. PROCESS FLOW © Copyright, Techserv Consulting 15
  16. 16. DETAILED DESCRIPTION REVIEW REVIEW The Requirements Analyst must continually consult with the customer to ensure that the requirements The Requirements Analyst must continually consult with the customer to ensure that the requirements REQUIREMENTS are correct and complete. The customer should be satisfied that if these requirements are met, then the are correct and complete. The customer should be satisfied that if these requirements are met, then the REQUIREMENTS WITH system will do what it really needs to do. All parties must agree to a way of measuring system system will do what it really needs to do. All parties must agree to a way of measuring system WITH performance to ensure that the system does what the customer wants it to do. The Requirement Analyst performance to ensure that the system does what the customer wants it to do. The Requirement Analyst CUSTOMER CUSTOMER and the customer should identify which requirements can be used as trade-off requirements. and the customer should identify which requirements can be used as trade-off requirements. (7) (7) Sometimes the customer is not available for consultation. In such unfortunate situations, a surrogate Sometimes the customer is not available for consultation. In such unfortunate situations, a surrogate customer will have to be used. customer will have to be used. At these reviews it is important to ask why each requirement is needed. This can help eliminate At these reviews it is important to ask why each requirement is needed. This can help eliminate unneeded requirements. It can also help reveal the requirements behind the stated requirements. It may unneeded requirements. It can also help reveal the requirements behind the stated requirements. It may be easier to satisfy the requirements behind the requirements, than the stated requirements be easier to satisfy the requirements behind the requirements, than the stated requirements themselves. themselves. PROCESS FLOW © Copyright, Techserv Consulting 16
  17. 17. DETAILED DESCRIPTION Validating requirements means ensuring that the requirements are consistent and that a real-world Validating requirements means ensuring that the requirements are consistent and that a real-world VALIDATE VALIDATE solution can be built and proven to satisfy the requirements. Each requirement should be technically solution can be built and proven to satisfy the requirements. Each requirement should be technically SOFTWARE SOFTWARE feasible, and fit within budget, schedule, and other constraints. feasible, and fit within budget, schedule, and other constraints. REQUIRMENTS REQUIRMENTS (8) (8) Requirements are often validated by reference to an existing system that meets most of the Requirements are often validated by reference to an existing system that meets most of the requirements. The requirements that are not satisfied by the existing system are validated by argument, requirements. The requirements that are not satisfied by the existing system are validated by argument, modeling, or simulation. modeling, or simulation. PROCESS FLOW © Copyright, Techserv Consulting 17
  18. 18. DETAILED DESCRIPTION A critical element of the requirements development process is describing the tests, analysis or data that A critical element of the requirements development process is describing the tests, analysis or data that DESCRIBE DESCRIBE will be used to prove compliance of the final system with its requirements. Each test must explicitly link will be used to prove compliance of the final system with its requirements. Each test must explicitly link VERIFICATION VERIFICATION to a specific requirement; this will help expose un testable requirements. Describing the system tests to a specific requirement; this will help expose un testable requirements. Describing the system tests PROCESS PROCESS informs the producers how the system will be tested, so that they know how they will be "graded." This informs the producers how the system will be tested, so that they know how they will be "graded." This (9) (9) process frequently uncovers overlooked requirements. process frequently uncovers overlooked requirements. At this time it may be useful to examine the following definitions. At this time it may be useful to examine the following definitions. Validating Requirements: Ensuring that the set of requirements is consistent, that a real-world solution Validating Requirements: Ensuring that the set of requirements is consistent, that a real-world solution can be built that satisfies the requirements, and that it can be proven that such a system satisfies its can be built that satisfies the requirements, and that it can be proven that such a system satisfies its requirements. If Systems Engineering discovers that the customer has requested a perpetual-motion requirements. If Systems Engineering discovers that the customer has requested a perpetual-motion machine, the project should be stopped. machine, the project should be stopped. Verifying a System: Building the system right; ensuring that the system complies with its requirements. Verifying a System: Building the system right; ensuring that the system complies with its requirements. Verifying a system determines the conformance of the system to its design requirements. It also Verifying a system determines the conformance of the system to its design requirements. It also guarantees the consistency of the product at the end of each phase, with itself and with the previous guarantees the consistency of the product at the end of each phase, with itself and with the previous prototypes. In other words, it guarantees the honest and smooth transition from model to prototype to prototypes. In other words, it guarantees the honest and smooth transition from model to prototype to preproduction unit to production unit. preproduction unit to production unit. Verifying Requirements: Examination, analysis, test, or demonstration that proves whether a Verifying Requirements: Examination, analysis, test, or demonstration that proves whether a requirement has been satisfied. This process is iterative. The requirements should be verified with requirement has been satisfied. This process is iterative. The requirements should be verified with respect to the model, the prototype, the preproduction unit, and the production unit. respect to the model, the prototype, the preproduction unit, and the production unit. PROCESS FLOW © Copyright, Techserv Consulting 18
  19. 19. DETAILED DESCRIPTION For the requirements that are gathered a traceability matrix should be prepared which consists of all For the requirements that are gathered a traceability matrix should be prepared which consists of all UPDATE UPDATE categories of requirements (functional, interface, service etc.) specified by the customer. During categories of requirements (functional, interface, service etc.) specified by the customer. During TRACEABILITY TRACEABILITY analysis this traceability matrix should be updated to include any derived requirements, which are not analysis this traceability matrix should be updated to include any derived requirements, which are not MATRIX MATRIX explicitly stated by the customer. Through out the engineering life cycle, this traceability matrix should explicitly stated by the customer. Through out the engineering life cycle, this traceability matrix should (10) (10) be updated to ensure the implementation of requirements across the development phases. be updated to ensure the implementation of requirements across the development phases. PROCESS FLOW © Copyright, Techserv Consulting 19
  20. 20. DETAILED DESCRIPTION Project Manager in association with the Requirements Analyst schedules the Formal Review meeting Project Manager in association with the Requirements Analyst schedules the Formal Review meeting PLAN PLAN of Software Requirements Specification with the Team Members with adequate notice. The of Software Requirements Specification with the Team Members with adequate notice. The FORMAL FORMAL meeting to be attended by Team Members .. The draft Software Requirements Specification to be meeting to be attended by Team Members The draft Software Requirements Specification to be REVIEW REVIEW circulated in advance and the comments are elicited prior to the meeting to conduct the meeting circulated in advance and the comments are elicited prior to the meeting to conduct the meeting (10) (10) effectively. effectively. The meeting to be led by Project Manager // Requirement’s Analyst by presenting: The meeting to be led by Project Manager Requirement’s Analyst by presenting: Methodologies adopted in eliciting the product requirements Methodologies adopted in eliciting the product requirements Planned effort and actual effort Planned effort and actual effort Planned schedule and actual schedule Planned schedule and actual schedule Summary of Defects found and addressed so far Summary of Defects found and addressed so far Rework effort Rework effort Audit report on this process, if any. Audit report on this process, if any. PROCESS FLOW © Copyright, Techserv Consulting 20
  21. 21. DETAILED DESCRIPTION Requirements Analyst in association with Project Manager conducts the final review of the Product Requirements Analyst in association with Project Manager conducts the final review of the Product CONDUCT CONDUCT Requirements with the Team members before it is base lined. Requirements with the Team members before it is base lined. FORMAL FORMAL REVIEW REVIEW The meeting to be led by Project Manager // Requirement’s Analyst by presenting: The meeting to be led by Project Manager Requirement’s Analyst by presenting: (11) (11) -- Methodologies adopted in eliciting the Software requirements Methodologies adopted in eliciting the Software requirements -- Planned effort and actual effort Planned effort and actual effort -- Planned schedule and actual schedule Planned schedule and actual schedule -- Summary of Defects found and addressed so far Summary of Defects found and addressed so far -- Rework effort Rework effort -- Audit report on this process, if any. Audit report on this process, if any. The review comments are to be documented and addressed in the Software Requirements Specification. The review comments are to be documented and addressed in the Software Requirements Specification. All review comments are to be preserved in the project file. All review comments are to be preserved in the project file. Team Members approval to be obtained to progress further in the product development cycle. Team Members approval to be obtained to progress further in the product development cycle. A Team Members is to look for errors, mistaken assumptions, lack of clarity and deviation from A Team Members is to look for errors, mistaken assumptions, lack of clarity and deviation from standard practice. The composition of the group that conducts the review is important and should standard practice. The composition of the group that conducts the review is important and should include all relevant stakeholders. The reviews should be held periodically to ensure the adequacy and include all relevant stakeholders. The reviews should be held periodically to ensure the adequacy and completeness of requirements, by obtaining feedback about them from relevant stakeholders. completeness of requirements, by obtaining feedback about them from relevant stakeholders. After all the defects are addressed in the SRS, the same is to be sent to Customer for review and After all the defects are addressed in the SRS, the same is to be sent to Customer for review and approval. approval. PROCESS FLOW © Copyright, Techserv Consulting 21
  22. 22. DETAILED DESCRIPTION Based on the approvals for the Software Requirements Specification, the same would be baselined. Based on the approvals for the Software Requirements Specification, the same would be baselined. BASLINE BASLINE SRS SRS Defect free Software Requirements Specification is to be versioned as 1.0 and baselined. Henceforth, Defect free Software Requirements Specification is to be versioned as 1.0 and baselined. Henceforth, (12) (12) this document is under configuration management planning and control process, therefore, it would go this document is under configuration management planning and control process, therefore, it would go through formal change management process for any required changes. through formal change management process for any required changes. PROCESS FLOW © Copyright, Techserv Consulting 22
  23. 23. PROCESS GUIDANCE PROCESS AIDS: PROCESS AIDS: PROCESS COMPLIANCE INDICATORS: PROCESS COMPLIANCE INDICATORS: •• Software Requirements Specification Template (PD-SE-TP- Software Requirements Specification Template (PD-SE-TP- EXISTENCE: EXISTENCE: 001) 001) •• Software requirements Specification Software requirements Specification •• Software Requirements Specification Guidelines (PD-SE-GL- Software Requirements Specification Guidelines (PD-SE-GL- 001) •• Product Requirements Traceability Product Requirements Traceability 001) •• Product Requirements Traceability Matrix (PD-SE-TP-002) •• Review Records Review Records Product Requirements Traceability Matrix (PD-SE-TP-002) •• Study notes Study notes •• Minutes of Meeting Minutes of Meeting EFFECTIVENESS: EFFECTIVENESS: •• No Major Non-Conformances No Major Non-Conformances •• Minimal Changes to Product Requirements Minimal Changes to Product Requirements ADDITIONAL PROCESS NOTES: ADDITIONAL PROCESS NOTES: •• Rework to Requirements Definition effort ratio Rework to Requirements Definition effort ratio © Copyright, Techserv Consulting 23
  24. 24. RACI SR ROLES NO Verification & Validation Configuration In-charge Steering Committee Requirements analyst Quality Coordinator TASK Product Architect Project Manager Developer Unit Head Customer 1 PLAN SOFTWARE REQUIRMENTS PROCESS R A R 2 IDENTIFY SOURCES OF REQUIRMENTS R A 3 UNDERSTAND CUSTOMER NEEDS R A 4 DEFINE AND STATE PROBLEMS R A 5 WRITE SOFTWARE REQUIRMENTS R A 6 ANALYZE SOFTWARE REQUIRMENTS R A 7 REVIEW REQUIREMENTS WITH CUSTOMER R R A R 8 VALIDATE SOFTWARE REQUIRMENTS R R A 9 DESCRIBE VERIFICATION PROCESS R R A 10 PLAN FORMAL REVIEW R A 11 CONDUCTFORMALREVIEW C A R 12 BASLINE SRS A R R RESPONSIBLE A ACCOUNTABLE C CONSULTED I INFORMED © Copyright, Techserv Consulting 24
  25. 25. END © Copyright, Techserv Consulting 25

×