Authored by : Hitesh Sanghavi
SEI authorized Lead Appraiser
Hitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
PI: Product Integration
TS: Technical Solution
ICWG: Interface Control Working Group
PC: Product Component
Objectives of PIThe objective of PI is to ensure planned successful assembling of the complete product (or services) from one or more, simple or complex PCs (or service components), ensuring that the product (or services), as integrated, functions properly as intended by design , and deliver/deploy the product (or services) at the end user/customer site.
Where PI applies:
PI SCOPE:
PI deals with achieving complete and functionally successful PI through progressive assembling of PCs, in one or incremental stages, according to defined integration sequence and procedures. PI calls for interface management throughout the project i.e. the management of internal/external interfaces of the products and PCs to ensure compatibility among the interfaces as defined by design team and ICWG.
This process may begin with analysis and simulations (e.g., threads, rapid prototypes, virtual prototypes, and physical prototypes) and steadily progress through increasingly more realistic and incremental functionality until the final product is achieved. To ensure smooth and successful product verification and validation, in each successive build, prototypes (virtual, rapid, or physical) are constructed, evaluated, improved, and reconstructed based upon knowledge gained in the evaluation process.
Inputs to PI from RD:
PI accepts requirements from RD where PCs are combined and interfaces are verified (by ICWG) to ensure that they meet the interface requirements supplied by RD. PI may refer to RD for detail information on interfaces and may refer to RM for information on managing changes to interface requirements.
Impact on RM due to TS-PI interdependencies:
RM fundamentally controls changes to requirements are reflected in the deliverables of other engineering PA’s (due to recursive and dynamic sequence of events by RM) and subsequently in integrated project plans, activities and work products. The table of TS-PI deliverables (at the end of this document) clearly depicts the goal wise deliverables of TS and PI (i.e. the requirements generated by enacting TS-PI activities), the activities which are to be included in the project plan and managed by RM.
Differences in TS-PI Base and Advance practices. (PI does not have advance practices.)
• In TS, SP1.1-1(base practice) “Develop Alternative solutions” is there, on which TS 1.1-2; (advance practice) is built, as “Develop detailed Alternative solutions” which is relatively more demanding. Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP1.1-1(base practice).
• In TS. SP2.3-1(base practice) we have “Establish Interface Descriptions” and in TS.SP2.3-3 (advance practice is built on base practice), we see” Design Interfaces Using Criteria” .Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP2.3-1(base practice).
PI
PI has 3 goals (9 SPs - no base practices) with the respective Deliverables/work products listed. i.e.
a) Prepare for Product Integration
•PI sequence with a rationale for selecting or rejecting the sequence.
•Verified and documented environment for PI
•PI procedures and criteria
b) Ensure Interface Compatibility
•Categories of interfaces and list of interfaces/category
•Mapping interfaces to the PCs and PI environment.
•Table of relationships amongst PCs and between PCs and the external environment.
•List of agreed-to interfaces defined for each pair of PCs.
•Reports from the ICWG meetings.
•Action items for updating interfaces
•Updated interface description and defined APIs
c) Assemble PCs and Deliver the Product
•Acceptance documents for the received PCs
•Delivery receipts/documentation, Checked packing lists
•Exception reports and Waivers
•Assembled product or PCs
•Interface evaluation reports and PI summary reports
•Packaged product
SEI authorized Lead Appraiser
Hitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
PI: Product Integration
TS: Technical Solution
ICWG: Interface Control Working Group
PC: Product Component
Objectives of PIThe objective of PI is to ensure planned successful assembling of the complete product (or services) from one or more, simple or complex PCs (or service components), ensuring that the product (or services), as integrated, functions properly as intended by design , and deliver/deploy the product (or services) at the end user/customer site.
Where PI applies:
PI SCOPE:
PI deals with achieving complete and functionally successful PI through progressive assembling of PCs, in one or incremental stages, according to defined integration sequence and procedures. PI calls for interface management throughout the project i.e. the management of internal/external interfaces of the products and PCs to ensure compatibility among the interfaces as defined by design team and ICWG.
This process may begin with analysis and simulations (e.g., threads, rapid prototypes, virtual prototypes, and physical prototypes) and steadily progress through increasingly more realistic and incremental functionality until the final product is achieved. To ensure smooth and successful product verification and validation, in each successive build, prototypes (virtual, rapid, or physical) are constructed, evaluated, improved, and reconstructed based upon knowledge gained in the evaluation process.
Inputs to PI from RD:
PI accepts requirements from RD where PCs are combined and interfaces are verified (by ICWG) to ensure that they meet the interface requirements supplied by RD. PI may refer to RD for detail information on interfaces and may refer to RM for information on managing changes to interface requirements.
Impact on RM due to TS-PI interdependencies:
RM fundamentally controls changes to requirements are reflected in the deliverables of other engineering PA’s (due to recursive and dynamic sequence of events by RM) and subsequently in integrated project plans, activities and work products. The table of TS-PI deliverables (at the end of this document) clearly depicts the goal wise deliverables of TS and PI (i.e. the requirements generated by enacting TS-PI activities), the activities which are to be included in the project plan and managed by RM.
Differences in TS-PI Base and Advance practices. (PI does not have advance practices.)
• In TS, SP1.1-1(base practice) “Develop Alternative solutions” is there, on which TS 1.1-2; (advance practice) is built, as “Develop detailed Alternative solutions” which is relatively more demanding. Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP1.1-1(base practice).
• In TS. SP2.3-1(base practice) we have “Establish Interface Descriptions” and in TS.SP2.3-3 (advance practice is built on base practice), we see” Design Interfaces Using Criteria” .Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP2.3-1(base practice).
PI
PI has 3 goals (9 SPs - no base practices) with the respective Deliverables/work products listed. i.e.
a) Prepare for Product Integration
•PI sequence with a rationale for selecting or rejecting the sequence.
•Verified and documented environment for PI
•PI procedures and criteria
b) Ensure Interface Compatibility
•Categories of interfaces and list of interfaces/category
•Mapping interfaces to the PCs and PI environment.
•Table of relationships amongst PCs and between PCs and the external environment.
•List of agreed-to interfaces defined for each pair of PCs.
•Reports from the ICWG meetings.
•Action items for updating interfaces
•Updated interface description and defined APIs
c) Assemble PCs and Deliver the Product
•Acceptance documents for the received PCs
•Delivery receipts/documentation, Checked packing lists
•Exception reports and Waivers
•Assembled product or PCs
•Interface evaluation reports and PI summary reports
•Packaged product
Authored by : Hitesh Sanghavi
SEI authorized Lead Appraiser
Hitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
TS: Technical Solution
PI: Product Integration
ICWG: Interface Control Working Group
PC: Product Component
Objectives of TS
The objective of TS is to design (developing architecture, high level and low level/detail design), develop (coding or data conversion activity for Data migration), and implement (successful deployment at the customer’s site) solutions as per agreed and documented requirements (as per the requirements management and development activities/phase). This includes products, PCs (programs or modules), and product-related lifecycle processes (user manual, design manuals etc).
Where TS applies:
TS SCOPE:
TS is applied to every product and service that the organization develops/deploys including PCs (units, modules, large programs etc), product related life-cycle process and service/maintenance of products/PCs at all levels of the product architecture. Also, the product-related life-cycle processes are developed along with the product/PC, selecting and adapting existing processes (including standard processes) for use as well as developing new processes as per the tailoring guidelines in the model and the QMS. The interfaces are identified and defined during the design phase (TS: SG2). TS is valid for various types of projects like support activities, off shore development, software maintenance, ERP implementation, data migration etc. TS has a clear focus on:
1.Evaluating/selecting “design approaches/concepts” or “prototypes/preliminary designs/Proof of concepts” that potentially satisfy an appropriate set of allocated requirements or PC prototypes or service models.
2.Implementing the designs (of product, PCs or service models) with integrated activities interactively support each other.
Inputs to TS from RD:
TS accepts requirements from RD, subsequently convert it into product architecture, PC (coding or data conversion activity for Data migration) or PC design (high or low level).
Impact on RM due to TS-PI interdependencies :
RM fundamentally controls changes to requirements are reflected in the deliverables of other engineering PA’s (due to recursive and dynamic sequence of events by RM) and subsequently in integrated project plans, activities and work products. The table of TS-PI deliverables (at the end of this document) clearly depicts the goal wise deliverables of TS and PI (i.e. the requirements generated by enacting TS-PI activities), the activities which are to be included in the project plan and managed by RM.
Differences in TS-PI Base and Advance practices. (PI does not have advance practices.)
• In TS, SP1.1-1(base practice) “Develop Alternative solutions” is there, on which TS 1.1-2, (advance practice) is built, as “Develop detailed Alternative solutions” which is relatively more demanding. Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP1.1-1(base practice).
• In TS. SP2.3-1(base practice) we have “Establish Interface Descriptions” and in TS.SP2.3-3 (advance practice is built on base practice), we see” Design Interfaces Using Criteria” .Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP2.3-1(base practice).
TS
TS has 3 goals (9 SPs with 2 base practices) for TS with the below Deliverables/ work products.
a) Select PC Solutions
- Alternative solution screening criteria leading to solutions.
- Evaluations of new technologies
- Selection criteria for final selection
- PC operational concepts, scenarios, and environments for all product-related life-cycle processes(e.g. operations, support, training, manufacturing, deployment and delivery)
- Timeline analyses of PC interactions using OOAD and Use cases
- PC selection decisions and rationale
- Documented relationships between requirements and PCs, Document solutions, evaluations, and rationale.
b) Develop the Design
- Product architecture, PC designs
- Technical data package
- Interface design specifications with criteria
- Interface control documents
- Rationale for selected interface design
- Criteria for design and PC reuse
- Make-or-buy analyses and Guidelines for choosing COTS PCs.
c) Implement the Product Design
- Implemented design
- End-user training materials, User's/Operator’s manual, Maintenance manual, online help etc.
SEI authorized Lead Appraiser
Hitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
TS: Technical Solution
PI: Product Integration
ICWG: Interface Control Working Group
PC: Product Component
Objectives of TS
The objective of TS is to design (developing architecture, high level and low level/detail design), develop (coding or data conversion activity for Data migration), and implement (successful deployment at the customer’s site) solutions as per agreed and documented requirements (as per the requirements management and development activities/phase). This includes products, PCs (programs or modules), and product-related lifecycle processes (user manual, design manuals etc).
Where TS applies:
TS SCOPE:
TS is applied to every product and service that the organization develops/deploys including PCs (units, modules, large programs etc), product related life-cycle process and service/maintenance of products/PCs at all levels of the product architecture. Also, the product-related life-cycle processes are developed along with the product/PC, selecting and adapting existing processes (including standard processes) for use as well as developing new processes as per the tailoring guidelines in the model and the QMS. The interfaces are identified and defined during the design phase (TS: SG2). TS is valid for various types of projects like support activities, off shore development, software maintenance, ERP implementation, data migration etc. TS has a clear focus on:
1.Evaluating/selecting “design approaches/concepts” or “prototypes/preliminary designs/Proof of concepts” that potentially satisfy an appropriate set of allocated requirements or PC prototypes or service models.
2.Implementing the designs (of product, PCs or service models) with integrated activities interactively support each other.
Inputs to TS from RD:
TS accepts requirements from RD, subsequently convert it into product architecture, PC (coding or data conversion activity for Data migration) or PC design (high or low level).
Impact on RM due to TS-PI interdependencies :
RM fundamentally controls changes to requirements are reflected in the deliverables of other engineering PA’s (due to recursive and dynamic sequence of events by RM) and subsequently in integrated project plans, activities and work products. The table of TS-PI deliverables (at the end of this document) clearly depicts the goal wise deliverables of TS and PI (i.e. the requirements generated by enacting TS-PI activities), the activities which are to be included in the project plan and managed by RM.
Differences in TS-PI Base and Advance practices. (PI does not have advance practices.)
• In TS, SP1.1-1(base practice) “Develop Alternative solutions” is there, on which TS 1.1-2, (advance practice) is built, as “Develop detailed Alternative solutions” which is relatively more demanding. Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP1.1-1(base practice).
• In TS. SP2.3-1(base practice) we have “Establish Interface Descriptions” and in TS.SP2.3-3 (advance practice is built on base practice), we see” Design Interfaces Using Criteria” .Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP2.3-1(base practice).
TS
TS has 3 goals (9 SPs with 2 base practices) for TS with the below Deliverables/ work products.
a) Select PC Solutions
- Alternative solution screening criteria leading to solutions.
- Evaluations of new technologies
- Selection criteria for final selection
- PC operational concepts, scenarios, and environments for all product-related life-cycle processes(e.g. operations, support, training, manufacturing, deployment and delivery)
- Timeline analyses of PC interactions using OOAD and Use cases
- PC selection decisions and rationale
- Documented relationships between requirements and PCs, Document solutions, evaluations, and rationale.
b) Develop the Design
- Product architecture, PC designs
- Technical data package
- Interface design specifications with criteria
- Interface control documents
- Rationale for selected interface design
- Criteria for design and PC reuse
- Make-or-buy analyses and Guidelines for choosing COTS PCs.
c) Implement the Product Design
- Implemented design
- End-user training materials, User's/Operator’s manual, Maintenance manual, online help etc.
Authored by : Hitesh Sanghavi
SEI authorized Lead AppraiserHitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
RM: Requirements Management
Requirements management and requirements development play a very important role in the project management activity. Project managers have to keep a constant vigil on these two activities.
The purpose of Requirements Management (RM) is to “manage” the requirements of the project's products and product components
RM identifies inconsistencies between requirements and project's plans/work products
RM stakeholders:
RM stakeholders are customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product/process.
RM defines process for collecting and defining Customer requirements, Project management requirements and process specific requirements, necessary to be satisfied by the organization. This checklist may help RM activity:
1. Has the final statement of requirements been checked against the original source?
2. What other requirements relate to this requirement? Are they clearly noted via cross reference matrix or other mechanism? Does the requirement violate any domain constraints?
3. Is the requirement traceable to any system model that has been created?
4. Is the requirement traceable to overall system/product objectives?
5. Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?
6. Has an index for the specification been created?
7. Is the source (e.g., a person, a regulation, a document) of the requirement identified?
8. RM ensures reduction of costly rework, or customer rejection by establishing the criteria for the acceptance of requirements to se that requirements are clear, complete, consistent with each other, uniquely identified, implementable, verifiable and traceable.
RM process area expects a common understanding to be developed between the project stake holders from the customer’s side and software development organization. Project related requirements from process areas like RD, technical solutions, Product integration, verification and validation (testing) shall be created when these process areas are enacted. These evolving project and process requirements changes may “dynamically and often recursively” affect all other engineering process areas. Functional and non functional requirements review by SME (Subject matter expert) ensures consistency between the RM document, project planning, WBS, work products and products components to ensure smooth implementation of the design and coding activities. RM takes care of managing the requirements developed in the RD stage and subsequent stages of the life cycle by handling requirement changes and sign-offs in an organized manner. In the RD stage and subsequent stages of the life cycle by handling requirement changes and sign-offs in an organized manner. As and when RD changes the requirements, RM manages and controls the requirement changes and assesses its impact on other work products and the phases of the life cycle. RM process ensures that requirements are reviewed by an agreed SPOC (Single point of Contact) from the customer, after necessary review on functional, non functional and technical specifications. The requirements are decomposed for clarity and systematically negotiated without keeping any TBD (to be decided) factors. This ensures that misunderstanding, misconception and assumptions in the documents are resolve at an early stage of life cycle. This prevents them to be converted into risk in later phases of the life cycle.
RM
1. Deals with communication between requirements analysts and customer. RM is customer management
oriented.
2. RM process defines a clear and explicit understanding of all the project activities executed by the SW
development organization. This is also agreed by the customer SPOC, and PM communicates various
technical/ non technical aspects of the requirements to his team members.
3. RM manages the activities emerging out of RD and other PA in the life cycle. Several process activities
shall get added to the project plan (e.g. Staff training, review requirements, test equipments, interfaces,
integration environments, documentation requirements, prototyping needs etc) at various phases of
SDLC.
4. Bi–directional requirements traceability is maintained using matrix format which helps in managing
control of requirement changes by using CRL (Change request log) and version control process
configuration management) and its impact on project planning, design, WBS, coding and the testing
activities is logged.
5. RM uses requirements tracking tools, traceability tools and bi-directional matrix to manage requirement
changes
6. RM training includes: Application domain, ??Requirements definition, analysis, review, ??Configuration
management and RM tools, ??Negotiation and conflict resolution
7. RM deliverables placed under configuration management are requirements and requirements traceability
matrix.
8. Work products reviewed include requirements and requirements traceability matrix.
9. RM does not have any advance practice built on the base practice.
10. Typical RM work products are:
For successful RM implementation, we have the following work products.
1. Criterion for evaluation and acceptance of requirements with results of analyses against criteria.
2. An agreed to set of documented requirements (complete, consistent, verifiable, traceable, unique and
appropriate to implement) with commitments .This can be in a document called URS (User
requirements specification)
3. Requirements Impact assessments.
4. Requirements status in requirements database with decision statements.
5. Requirements Traceability Matrix and tracking system procedures.
6. Documentation of inconsistencies including sources conditions and rationales and the follow-up
corrective actions.
7. Corrective actions on Requirements review
SEI authorized Lead AppraiserHitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
RM: Requirements Management
Requirements management and requirements development play a very important role in the project management activity. Project managers have to keep a constant vigil on these two activities.
The purpose of Requirements Management (RM) is to “manage” the requirements of the project's products and product components
RM identifies inconsistencies between requirements and project's plans/work products
RM stakeholders:
RM stakeholders are customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product/process.
RM defines process for collecting and defining Customer requirements, Project management requirements and process specific requirements, necessary to be satisfied by the organization. This checklist may help RM activity:
1. Has the final statement of requirements been checked against the original source?
2. What other requirements relate to this requirement? Are they clearly noted via cross reference matrix or other mechanism? Does the requirement violate any domain constraints?
3. Is the requirement traceable to any system model that has been created?
4. Is the requirement traceable to overall system/product objectives?
5. Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?
6. Has an index for the specification been created?
7. Is the source (e.g., a person, a regulation, a document) of the requirement identified?
8. RM ensures reduction of costly rework, or customer rejection by establishing the criteria for the acceptance of requirements to se that requirements are clear, complete, consistent with each other, uniquely identified, implementable, verifiable and traceable.
RM process area expects a common understanding to be developed between the project stake holders from the customer’s side and software development organization. Project related requirements from process areas like RD, technical solutions, Product integration, verification and validation (testing) shall be created when these process areas are enacted. These evolving project and process requirements changes may “dynamically and often recursively” affect all other engineering process areas. Functional and non functional requirements review by SME (Subject matter expert) ensures consistency between the RM document, project planning, WBS, work products and products components to ensure smooth implementation of the design and coding activities. RM takes care of managing the requirements developed in the RD stage and subsequent stages of the life cycle by handling requirement changes and sign-offs in an organized manner. In the RD stage and subsequent stages of the life cycle by handling requirement changes and sign-offs in an organized manner. As and when RD changes the requirements, RM manages and controls the requirement changes and assesses its impact on other work products and the phases of the life cycle. RM process ensures that requirements are reviewed by an agreed SPOC (Single point of Contact) from the customer, after necessary review on functional, non functional and technical specifications. The requirements are decomposed for clarity and systematically negotiated without keeping any TBD (to be decided) factors. This ensures that misunderstanding, misconception and assumptions in the documents are resolve at an early stage of life cycle. This prevents them to be converted into risk in later phases of the life cycle.
RM
1. Deals with communication between requirements analysts and customer. RM is customer management
oriented.
2. RM process defines a clear and explicit understanding of all the project activities executed by the SW
development organization. This is also agreed by the customer SPOC, and PM communicates various
technical/ non technical aspects of the requirements to his team members.
3. RM manages the activities emerging out of RD and other PA in the life cycle. Several process activities
shall get added to the project plan (e.g. Staff training, review requirements, test equipments, interfaces,
integration environments, documentation requirements, prototyping needs etc) at various phases of
SDLC.
4. Bi–directional requirements traceability is maintained using matrix format which helps in managing
control of requirement changes by using CRL (Change request log) and version control process
configuration management) and its impact on project planning, design, WBS, coding and the testing
activities is logged.
5. RM uses requirements tracking tools, traceability tools and bi-directional matrix to manage requirement
changes
6. RM training includes: Application domain, ??Requirements definition, analysis, review, ??Configuration
management and RM tools, ??Negotiation and conflict resolution
7. RM deliverables placed under configuration management are requirements and requirements traceability
matrix.
8. Work products reviewed include requirements and requirements traceability matrix.
9. RM does not have any advance practice built on the base practice.
10. Typical RM work products are:
For successful RM implementation, we have the following work products.
1. Criterion for evaluation and acceptance of requirements with results of analyses against criteria.
2. An agreed to set of documented requirements (complete, consistent, verifiable, traceable, unique and
appropriate to implement) with commitments .This can be in a document called URS (User
requirements specification)
3. Requirements Impact assessments.
4. Requirements status in requirements database with decision statements.
5. Requirements Traceability Matrix and tracking system procedures.
6. Documentation of inconsistencies including sources conditions and rationales and the follow-up
corrective actions.
7. Corrective actions on Requirements review
Authored by : Hitesh Sanghavi
SEI authorized Lead AppraiserHitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
RD: Requirements Development
RD stakeholders:
RD stakeholders are customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product/process.
Requirements Elicitation includes:
1. Problems of Scope.
2. Problems of understanding.
3. Problems of volatility.
System engineers must approach the RD gathering activity in an organized manner like:
1. Assess the business and technical feasibility for the proposed system.
2. Identify people who can specify requirements and understand their Organizational basis.
3. Define the technical environment (e.g., computing architecture, operating System, telecommunications needs) into which the system or product will be placed.
4. Identify "domain constraints" (i.e., characteristics of the business environment) that limit the functionality or performance of the system or product to be built.
5. Define one or more requirement elicitation methods (e.g., interviews, focus groups, and team meetings).
6. Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded.
7. Identify ambiguous requirements as candidates for prototyping for functional, behavioral and performance modeling.
8. Create usage scenarios to help customers/users better identify key requirements.
The work products produced as a consequence of RD are validated to ensure that all system requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product.
Following checklist can be useful:
1. Is the requirement bounded in quantitative terms?
2. Is the requirement testable? If so, can we specify tests validation criterion?
3. Have requirements associated with system performance, behavior, and operational characteristics been dearly stated? What requirements appear to be implicit?
4. Are requirements stated clearly? Can they be misinterpreted?
RD:
- Deals with communication between PM, domain and functional architect, designer and his team. In object oriented domain, it relates to defining services.
- RD collects stakeholder needs, expectations, constraints, formulating product and product-component requirements, and analyzing and validating them.
- RD proactively elicits customer requirements by the way of technology demonstrations, Interface and technology working groups, project reviews, questionnaires, interviews, brainstorming, simulating operational scenarios and walkthroughs, business case analysis, end-user task analysis, prototypes, models, ?market surveys, beta testing and reverse engineering.
- Sometimes there are several iterations of refinements in the architecture ( product or product components) and thus in the detail design and so on due to variation of:
-Design Constraints and• Technological limitations, risks, Cost, effort, time and Schedules
-Implied needs by the customer and uncontrolled factors introduced by the
Developer’s unique business considerations, regulations, and laws.
- GP 2.3 RD uses requirements specification tools, simulators, modeling/ prototyping tools, scenario definition and management tools.
- GP 2.5 Examples of TD training includes :
- Application domain,Requirements definition, analysis and requirements elicitation,
-Requirements specification, modeling and tracking
- GP 2.6 RD deliverables placed under configuration management are customer requirements, functional architecture, product and product-component requirements and Interface requirements.
- Work products reviewed include product and product-component requirements, Interface requirements and functional architecture.
- RD has 2 advance practices built on base practices.
- Typical RD work products are:
For successful RD implementation, we have the following work products.
1. Customer requirements. (SP 1.2-1)
2. Customer constraints on conduct of verification and validation. (SP 1.2-1)
3. Derived requirements and relationships amongst them. (SP 2.1-1 and SP2.2-1)
4. Product requirements and product component requirements (SP 2.1-1)
5. Requirements allocation sheet and provisional requirement allocations (SP2.2-1)
6. Design constraints (SP2.2-1)
7. Interface Requirements. (SP2.3-1)
8. Operational and disposal concepts. (SP3.1-1)
9. Product installation, operational, maintenance and support concept (SP3.1-1)
10. Use cases, activity diagrams, OOAD, services identified and timeline scenarios (SP3.1
1&SP3.2-1)
11. Functional architecture (SP 3.2-1)
SEI authorized Lead AppraiserHitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
RD: Requirements Development
RD stakeholders:
RD stakeholders are customers, end users, developers, producers, testers, suppliers, marketers, maintainers, disposal personnel, and others who may be affected by, or may affect, the product/process.
Requirements Elicitation includes:
1. Problems of Scope.
2. Problems of understanding.
3. Problems of volatility.
System engineers must approach the RD gathering activity in an organized manner like:
1. Assess the business and technical feasibility for the proposed system.
2. Identify people who can specify requirements and understand their Organizational basis.
3. Define the technical environment (e.g., computing architecture, operating System, telecommunications needs) into which the system or product will be placed.
4. Identify "domain constraints" (i.e., characteristics of the business environment) that limit the functionality or performance of the system or product to be built.
5. Define one or more requirement elicitation methods (e.g., interviews, focus groups, and team meetings).
6. Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded.
7. Identify ambiguous requirements as candidates for prototyping for functional, behavioral and performance modeling.
8. Create usage scenarios to help customers/users better identify key requirements.
The work products produced as a consequence of RD are validated to ensure that all system requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product.
Following checklist can be useful:
1. Is the requirement bounded in quantitative terms?
2. Is the requirement testable? If so, can we specify tests validation criterion?
3. Have requirements associated with system performance, behavior, and operational characteristics been dearly stated? What requirements appear to be implicit?
4. Are requirements stated clearly? Can they be misinterpreted?
RD:
- Deals with communication between PM, domain and functional architect, designer and his team. In object oriented domain, it relates to defining services.
- RD collects stakeholder needs, expectations, constraints, formulating product and product-component requirements, and analyzing and validating them.
- RD proactively elicits customer requirements by the way of technology demonstrations, Interface and technology working groups, project reviews, questionnaires, interviews, brainstorming, simulating operational scenarios and walkthroughs, business case analysis, end-user task analysis, prototypes, models, ?market surveys, beta testing and reverse engineering.
- Sometimes there are several iterations of refinements in the architecture ( product or product components) and thus in the detail design and so on due to variation of:
-Design Constraints and• Technological limitations, risks, Cost, effort, time and Schedules
-Implied needs by the customer and uncontrolled factors introduced by the
Developer’s unique business considerations, regulations, and laws.
- GP 2.3 RD uses requirements specification tools, simulators, modeling/ prototyping tools, scenario definition and management tools.
- GP 2.5 Examples of TD training includes :
- Application domain,Requirements definition, analysis and requirements elicitation,
-Requirements specification, modeling and tracking
- GP 2.6 RD deliverables placed under configuration management are customer requirements, functional architecture, product and product-component requirements and Interface requirements.
- Work products reviewed include product and product-component requirements, Interface requirements and functional architecture.
- RD has 2 advance practices built on base practices.
- Typical RD work products are:
For successful RD implementation, we have the following work products.
1. Customer requirements. (SP 1.2-1)
2. Customer constraints on conduct of verification and validation. (SP 1.2-1)
3. Derived requirements and relationships amongst them. (SP 2.1-1 and SP2.2-1)
4. Product requirements and product component requirements (SP 2.1-1)
5. Requirements allocation sheet and provisional requirement allocations (SP2.2-1)
6. Design constraints (SP2.2-1)
7. Interface Requirements. (SP2.3-1)
8. Operational and disposal concepts. (SP3.1-1)
9. Product installation, operational, maintenance and support concept (SP3.1-1)
10. Use cases, activity diagrams, OOAD, services identified and timeline scenarios (SP3.1
1&SP3.2-1)
11. Functional architecture (SP 3.2-1)
Hitesh Sanghvi, MD of Cunix, is an SEI authorized SCAMPI Lead appraiser with rich experience in IT Consulting ,S/w Test Strategies, Software Process Quality, CMM / CMMI, SPI Consulting, Training and appraisals.
