Work Products in Software Requirements Analysis - Report Example

Introduction ISO/IEC 15504 is a framework of international standards used to know the process capability of Software lifecycle development process and other similar business areas. The aim of this report is to identify a set of work products required for the assessment of outcomes achieved in the Software Requirements Analysis Process along with their justification. The report specifically explores the work products required for the assessment of Capability Level 2 of this process. 2. ISO/IEC 15504 Overview ISO/IEC 15504 framework consists of two dimensions- the process dimension and the capability dimension. In the process dimension five process categories are defined as customer-supplier, engineering, supporting, management and organization. In the capability dimension, six capability levels and nine corresponding process attributes are defined. These are presented in Table 2.1. The measurement for all process attributes is done on a four-point scale. The process dimension of this framework classifies the processes into Process categories and groups. Software Requirements Analysis is a part of the Software Implementation Process (DEV) within Software Life cycle Processes. Table 2.1: ISO/IEC 15504 – Process Capability Levels & Process Attributes Level Number Level Name Process Attribute Number Process Attribute Name 0 Incomplete Process - - 1 Performed Process 1.1 Process Performance 2 Managed Process 2.1 Performance Management 2.2 Work Product Management 3 Established Process 3.1 Process Definition 3.2 Process Deployment 4 Predictable Process 4.1 Process Measurement 4.2 Process Control 5 Optimizing Process 5.1 Process Innovation 5.2 Process Optimization 3. Software Requirements Analysis Process – Purpose & Outcomes The purpose of this process is to identify and establish the requirements for the software elements of the system. As an outcome of successful implementation of this process the accuracy and testability of software requirements is established. It is made sure that the software requirements are consistent and in line with system requirements. The priorities of the requirements are established and their impact on cost and effort estimates is analyzed (ISO/IEC FDAM 15504-5: 2011, p.72). 4. Basic work products for Software Requirements Analysis Process This section details the work products required for Software Requirements Analysis Process, their justification, characteristics and outcomes (ISO/IEC FDAM 15504-5: 2011, ISO/IEC 15504-2:2003). I. Contract Contract implies an agreement between two parties (internal or external to the organization) regarding the scope of deliverables, time required to deliver them, statutory considerations, cost of delivery, service level agreements, performance evaluation criteria, review and approval procedure. A contract is required for software requirements analysis process so that the scope of the requirements to be identified is frozen to prevent any issues later. Contract is the most important document for ant stage or project and is also referred as SOW (Statement of Work) in some cases. As an outcome of this work product, the organization would be to chart its project plans. II. User Documentation User documentation is in fact required at every stage of software development process. But it is very critical for Software Requirements Analysis process because it acts as a basis for other processes. This documentation would be referred in design, development and testing phases significantly. Documentation could include both internal as well as external documentation. III. Plan A plan is essential at every stage of software life cycle process but becomes very vital for requirements analysis phase. Plan consists of objectives, scope, assumptions, constraints, risks, milestones, deliverables, methods, resources and schedules involved in requirements analysis. There may be a large overlap between contract and plan. Whereas a contract is generally between two parties, a plan may not be shared with the other party. IV. Policy Policy is a set of rules or practices established within an organization. Policy is a generic work product which is driven by the top management but everyone needs to be cognizant of it. For example, there may be certain disclosure policies being followed by an organization while doing software requirements analysis. V. Process Description This work product contains the detailed process to be followed for requirements analysis. It shows how the standard process of the organization has to be customized for a particular project. It also consists of the purpose, outcomes, activities to be performed, priority and order of activities, inputs, outputs, interfaces, measures, expectations, roles and responsibilities in the requirements analysis process. VI. Product Product is a deliverable or outcome of the software requirement process. There may be deliverables at various milestones within this process. The deliverables may include Minutes of Meeting, Weekly status documents and requirements documents. VII. Repository Repository is a common storage place for all documents which have been used or are essential for the smooth execution of the process. Repository may consist of documents received from the customer, interview notes, meeting notes, statutory documents, final deliverables etc. The purpose of repository is to make these documents accessible to everyone involved in the project. This also ensures transparency and accountability. VIII. Requirement Specification Software Requirements Specifications (SRS) documents is the most significant deliverable of the requirements analysis process and one of the most critical documents for the entire process. It lists all the requirements and acts as a reference point for all following processes. IX. Templates Templates are the documents which contain standard form and style of capturing the results. It is ideal to fix templates at the start of the project so that time is saved later. It also ensures standardization of documents. There may be templates for recording minutes of meeting, questionnaire responses, requirements gathering etc. 5. Performance Management Attribute & work products The purpose of the performance management attribute is to measure the degree of management of the process performance. As an outcome of high performance on this attribute, the objectives for process performance are identified. Plans are developed, roles are assigned and resources are identified to achieve high score on this attribute (ISO/IEC FDAM 15504-5: 2011, p.96). 5.1. Additional Work Products and their characteristics The following additional work products are required along with basic work products of software requirements analysis for this attribute (ISO/IEC FDAM 15504-5: 2011, ISO/IEC 15504-2:2003). I. Record This work product gives a record or history of results achieved and the activities performed in the process. It also provides a record of meetings conducted, interviews, e-mail and phone communication, reviews done, corrections made. These evidences prevent any mis-understandings later and allow an objective process performance measure. II. Register This work product is basically a record of status information. It documents the current status of the process, the review done, the corrections made, the schedule adherence, cost adherence, work breakdown structure and project management details. It also identifies and tracks the current status of risks involved and mitigated. III. Report Report is an assessment of the process performance vis-a-vis the objectives and plans decided at the start of the process. It highlights the unfavorable deviations from the plans. It also gives information about the steps taken by the higher management. 5.2. Enhanced characteristics for basic work products I. Plan In addition to basic characteristics, the plan must contain details of how the level of management of process performance would be measured. The key metrics used for the same must be identified in the plan. For example, a key metric could be the number of reviews required. Similarly the plan must contain the control and adjustment mechanisms required. II. Process Description This work product must contain a detailed description of the steps to be taken to measure process performance management. The key metrics used and the process for review and approval must be mentioned. 6. Work Product Management Attribute & work products The purpose of work product management attribute is to measure the degree of management of the work products produced by the process. As an outcome of high performance on this attribute, the requirements for the work products, their documentation and control, revision and approval are identified. Reviews are performed on the work products by comparing the actual with the planned and any adjustments required are made (ISO/IEC FDAM 15504-5: 2011, p.98). 6.1. Additional Work Products and their characteristics The following additional work products are required along with basic work products of software requirements analysis for this attribute (ISO/IEC FDAM 15504-5: 2011, ISO/IEC 15504-2:2003). I. Record This work product gives a record or history of work products reviewed. It also provides a record of any deviations during work product reviews and the steps taken to rectify them. It provides evidences of changes being under control. These evidences prevent any mis-understandings later and allow an objective process performance measure. II. Register This work product is basically a record of status information. It documents the current status of the work products and their documentation, the review done and the corrections made. III. Standard Standard helps in identify the requirements of a work product which may be functional or non-functional in nature. It identifies how various work products are related to each other. It also gives details of the conditions to be fulfilled for approval of work products. IV. Work product It is basically a list of the work products to be managed in the entire process. 6.2. Enhanced characteristics for basic work products I. Plan In addition to basic characteristics, the plan must state the policies associated with managing work products. It must specify the requirements for work product development, storage and retrieval. Also it must contain the quality control measures required for producing high quality work products. II. Templates The templates for each work product can be specifically built in advance to enable standardization and quality and to save time. Similarly, the templates of reports to be generated to measure work product quality can be designed. 7. Conclusion From this study, it can be said that the work products help significantly in the determination of process capability. They help in standardizing the whole process. They ensure efficient planning, timely execution, accurate measurement and enhanced control of the software requirements analysis process. The work products in this process are critical because errors in this process can get magnified in the subsequent processes leading to significant deviations in the plans. It was observed that Plan, Goals, Record, Template, Requirement Specification, Process Description and User Documentation were some of the most significant work products of the Requirements analysis process which enable the process to be implemented in a managed way. 8. References ISO/IEC 12207:2008, Information technology – Software life cycle processes. ISO/IEC 15504-2: 2003, Information technology – Process assessment – Requirements ISO/IEC FDAM 15504-5: 2011, Information technology – Process assessment – An exemplar Process Assessment Model. Read More