Group Members

2. Group Members NailaHamid BSEF08M004 MunazzaFarooqBSEF08M012 BushraArifBSEF08M007 Arooj-un-NisaBSEF08M035

3. REQUIREMENT DEVELOPMENT (CMMI)

4. Table of Contents • Introduction • Specific Goals • Develop Customer Requirements • Develop Product Requirements • Analyze and Validate Requirements • Generic Goals • Institutionalize a Defined Process

5. Introduction This process area describes three types of requirements: • Customer requirements • Product requirements • Product-component requirements The purpose of Requirements Development is to produce and analyze all of the these.

6. Requirements also address constraints caused by the selection of design solutions (e.g. integration of commercial off-the-shelf products). Requirements are the basis for design

7. Activities Involved • Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders • Collection and coordination of stakeholder needs • Development of the life-cycle requirements of the product • Establishment of the customer requirements • Establishment of initial product and product-component requirements consistent with customer requirements

8. This process area addresses all customer requirements rather than only product-level requirements

9. Specific Goals This area includes three specific goals: • Develop Customer Requirements • Develop Product Requirements • Analyze and Validate Requirements

10. The analysis includes • Analysis of needs and requirements for each product life-cycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user expectations and satisfaction, such as safety, security, and affordability • Development of an operational concept • Definition of the required functionality

11. Analyses occur recursively and as a result of the analysis of requirements, we get more derived requirements such as: • Constraints of various types • Technological limitations • Cost and cost drivers • Time constraints and schedule drivers • Risks • Consideration of issues implied but not explicitly stated by the customer or end user • Factors introduced by the developer’s unique business considerations, regulations, and laws

12. Related Process Areas • Requirements Management process area • Technical Solution process area • Product Integration process area • Verification process area • Validation process area • Risk Management process area • Configuration Management process area

13. Practice-to-Goal Relationship Table SG 1 Develop Customer Requirements • SP 1.1 Elicit Needs • SP 1.2 Develop the Customer Requirements

14. Practice-to-Goal Relationship Table SG 2 Develop Product Requirements • SP 2.1 Establish Product and Product-Component Requirements • SP 2.2 Allocate Product-Component Requirements • SP 2.3 Identify Interface Requirements

15. Practice-to-Goal Relationship Table SG 3 Analyze and Validate Requirements • SP 3.1 Establish Operational Concepts and Scenarios • SP 3.2 Establish a Definition of Required Functionality • SP 3.3 Analyze Requirements • SP 3.4 Analyze Requirements to Achieve Balance • SP 3.5 Validate Requirements with Comprehensive Methods

16. Practice-to-Goal Relationship Table GG 3 Institutionalize a Defined Process • GP 2.1 Establish an Organizational Policy • GP 3.1 Establish a Defined Process • GP 2.2 Plan the Process • GP 2.3 Provide Resources • GP 2.4 Assign Responsibility • GP 2.5 Train People • GP 2.6 Manage Configurations • GP 2.7 Identify and Involve Relevant Stakeholders

17. Practice-to-Goal Relationship Table • GP 2.8 Monitor and Control the Process • GP 3.2 Collect Improvement Information • GP 2.9 Objectively Evaluate Adherence • GP 2.10 Review Status with Higher Level Management

18. Develop Customer Requirements

19. Elicit Needs Elicit stakeholder needs, Expectations, constraints, and interfaces for all phases of the product life cycle. Engage relevant stakeholders using methods for eliciting needs

20. Develop Customer Requirements Transform stakeholder needs, expectations, constraints and interfaces into customer requirements. It is an Iterative Process

21. Develop the Customer Requirements • The various inputs from the customer must be consolidated • Missing information must be obtained • conflicts must be resolved

22. Develop the Customer Requirements Typical Work Products • Customer requirements • Customer constraints on the conduct of verification • Customer constraints on the conduct of validation

23. Develop the Customer Requirements Sub practices • Document customer requirements. • Define constraints for verification and validation.

24. Developing Product Requirements

25. Customer requirements are refined and elaborated to develop product and product-component requirements. Product and product-component requirements address the needs associated with each product life-cycle phase. Develop Product Requirements

26. Develop Product Requirements cont.. • The requirements are allocated to product functions and product components including objects, people, and processes. • The traceability of requirements to functions, objects, tests, issues, or other entities is documented. • As internal components are developed, additional interfaces are defined and interface requirements established

27. Establishing Product and Component Requirements

28. Establishing Product and Product-Component requirements • The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions.

29. Cont.. • The product requirements are the expression of these requirements in technical terms that can be used for design decisions. • An example of this translation is found in the first House of Quality Functional Deployment, which maps customer desires into technical parameters. For instance, “solid sounding door” might be mapped to size, weight, fit, dampening, and resonant frequencies.

30. Cont.. • Product and product-component requirements address the Satisfaction of customer, business project objectives and associated attributes, such as effectiveness and affordability. • Design constraints include specifications on product components that are derived from design decisions, rather than higher level requirements.

31. Work products • Derived requirements • Product requirements • Product-component requirements

32. Sub practices • Develop requirements in technical terms • Derive requirements that result from design decisions. • Establish and maintain relationships between requirements for consideration during change management and requirements allocation.

33. Derived requirements • Derived requirements also address the cost and performance of other life-cycle phases to the extent compatible with business objectives.

34. Modifications of requirements • Due to approved requirement changes is covered by the “maintain” function of this specific practice • The administration of requirement changes is covered by the “Requirements Management process area”.

35. Allocating Product-component Requirements

36. Allocate Product-Component Requirements • It includes allocation of product performance, design constraints, form, and function to meet requirements and facilitate production. • In cases where a higher level requirement specifies performance that will be the responsibility of two or more product components, the performance must be partitioned or unique allocation to each product component as a derived requirement.

37. Work products • Requirement allocation sheets • Provisional requirement allocations • Design constraints • Derived requirements • Relationships among derived requirements

38. Sub practices • Allocate requirements to functions • Allocate requirements to product components. • Allocate design constraints to product components. • Document relationships among allocated requirements.

39. Identifying Interface Requirements

40. Identify Interface Requirements • Interfaces between functions are identified. • Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.

41. Cont.. • Interface requirements between products or product components identified in the product architecture are defined. • They are controlled as part of product and product-component integration and are an integral part of the architecture definition.

42. Sub practices • Identify interfaces both external to the product and internal to the product. • Develop the requirements for the identified interfaces.

43. Analyze and Validate Requirements

44. The requirements are analyzed and validated, and a definition of required functionality is developed. • Establish Operational Concepts and Scenarios • Establish a Definition of Required Functionality • Analyze Requirements • Analyze Requirements to Achieve Balance • Validate Requirements with Comprehensive Methods

45. Establish Operational Concepts and Scenarios

46. Establish and maintain operational concepts and associated scenarios. Typical Work Products • Operational concept • Product installation, maintenance, and support concepts • Use cases • New requirements

47. Sub practices • Develop operational concepts and scenarios • Define the environment the product will operate • Review operational concepts and scenarios to refine and discover requirements. • Develop a detail operational concepts

48. Establish a Definition of Required Functionality

49. Establish and maintain a definition of required functionality. Typical Work Products • Functional architecture • Activity diagrams and use cases • Object-oriented analysis with services identified

50. Sub practices • Analyze and quantify functionality required by end users • Analyze requirements to identify logical partition. • Allocate customer requirements to functional partitions, • Allocate functional and performance requirements to functions and subfunctions.