1. 0 About REQUIREMENT 2005 11 E-mail:alexsj.yin@msa.hinet.net

2. 1 About REQUIREMENT based on - DoD-STD-2167A - MIL-STD-490 - IEEE 12207 - INCOSE TUTORIAL - CMMI TUTORIAL

3. 2 Topics 1.About Requirement 2.Guideline to define Requirement 3.Checklist of Requirement 4.Real Practice Case

4. 3 1.0-What is Quality? Watts Humphrey: To improve Product Quality, you must improve Process Quality. Crosby: Quality as Conformance to Requirement. –First, a software product must provide functions of a type and a time when the user needs them. –Second, the product must work.

5. 4 1.1-5 Common Problems in Software Development Poor requirements- unclear, incomplete, too general, or not testable. Unrealistic schedule - if too much work is crammed in too little time. Inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash. Featurities -requests to pile on new features after development is underway. Miscommunication

6. 5 1.2- Interrelationship between Requirement and WBS Requirements WBS SOW

7. 6 Software Bugs Percentage of Bugs by Source Percentage of Cost of Fixing Bugs by Source 8 2 13 56 27 7 10 Requirements Design Code Other 1.3- Why Are Requirements Important? Poor Requirements Requirements

8. 7 Requirement Defect 50 design phase 5 5 10 50

9. 8 1.4-Who is in charge of Requirement? Translating Customer Requirements to HW, SW, Specialty, and Test requirements SE SW Tester HW Rel, Mfg, HFE... Marketing / Proj Mgmt Customer

10. 9 1.6- What is Requirement? (1) 1.Based on CMMI as a)(1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). [IEEE 610.12-1990] b)…, these requirements address the needs of relevant stakeholders, including those pertinent to various product life-cycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).

11. 10 1.6- What is Requirement? (2) 2.Based on DICTIONARY ( article on Wikipedia.org ) as article on Wikipedia.org a)In software engineering, a requirement is a description of what a system should do. Very few systems have a single requirement, and most have hundreds. A collection of requirements then define the characteristics of the desired (required) system, but do not say how the system should implement those requirements.software engineering b)In a classical software engineering approach, requirements are used as input into the design stages (functional design followed by technical design) of the development process. c)The requirements phase may have been preceded by a feasibility study, or a conceptual phase of the project. d)All requirements should be testable. If this is not the case, then offending requirements should be altered or dropped.

12. 11 Level of Detail Project Time Low High Acceptance Testing Problem with V-Model: Clients Perception is the same as the Developers Perception Clients Understanding Developers Understanding Requirements Elicitation Analysis Design System Testing Object Design Unit Testing Integration Testing 1.7- Requirement in V model Acceptance testing against Requirements

13. 12 Process Implementation Activity Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution Organizational Processes: Management, Infrastructure, Improvement, Training System Qual Test System Integra-tion Software Installation Software Acceptance Support Software Item 1: Sys Arch Design System Reqts Analysis Software Qual Test Software Integra- tion Software Code & Test Software Detailed Design Software Arch. Design Software Reqts. Analysis SRS SARAD SRD, UDD SAD, SIDD, DBDD, T/VP SRD, UDD EOCR, SCR,T/VPr, T/VRR SIP,T/VPr T/VPr T/VRR SCR T/VRR SCR SCR, T/VRR DPP, SDSD SCMP, SCMR, SCIR, SQAP, SQAR, SVRR, PR/PRR Software Item 2: Software Qual Test Software Integra- tion Software Code & Test Software Detailed Design Software Arch. Design Software Reqts. Analysis Hardware items 1.7- Requirement in waterfall model (applying 12207)

14. 13 Program Strategy Define All Requirements First? Multiple Development Cycles Distribute Interim Software? Once-Through (Waterfall) YesNo Incremental (Preplanned Product Improvement) Yes Maybe Evolutionary NoYes 1.8- The relationship between Requirement and life cycle model 1.Requirements Freeze Life Cycle Model 2.Life Cycle Model

15. 14 1.9- The interrelationship between Requirement and others Process Discrete Primary Process Continuous Supporting Process

16. 15 RD PI Val Customer TS Ver REQM Requirements Customer needs Product & product component requirements Product components, work products, verification and validation reports Product components Alternative solutions Require- ments Product 1.10- Your Requirement from CMMIs view RD PA Requirements REQM PA Requirements

17. 16 System/Subsystem Design Description (SSDD) System Specification (SS) (MIL-STD-961D) Requirements Requirement: Noun shall verb. Example: The car shall stop within 100 feet at 50 mph. Functional Performance Function: Verb Noun. Example: Stop Car or Verb-ing. Example: Stopping. Component: Noun. Example: Brake. Functions Components System/Subsystem Specification (SSS) System Requirements Document (SRD) System Requirements Specification (SRS) (SSDD/SS) What is Systems Engineering? (cont) JOC Key Terms and Relationships REQUIREMNTS Functionality Performance Attributes

18. 17 Requirements Engineering Process Inputs Customer / User Needs ­Performance Requirements ­System External Interfaces ­Environmental Requirements External Influences ­Federal Regulations ­Navy Orders ­Standards ­Available Funding Top Level System Requirements Requirements Traceability Matrix System Concept of Operations Functional Architecture System Functional Block Diagram System External Interfaces Life Cycle Cost Objectives Verification Methodology Programmatic Risks Technical Performance Measures Logistics Program Systems Engineering Master Schedule Preliminary Models / Simulations Perform Systems Requirements Analysis and Functional Allocation Outputs Politics & Market Place Rules, Orders, Regulations, Standards Program Requirements OPERATIONAL NEEDS AND REQUIREMENTS 1. DEFINE ENVIRONMENT 2. DEFINE SYSTEM BOUNDRIES 3. IDENTIFY ATTRIBUTES TO SUPPORT OBJECTIVES 4. ESTABLISH FUNCTIONAL BASELINE 5. CONDUCT SYSTEM RQMTS. REVIEW DESIGN REFERENCE MISSION SYSTEM DESCRIPTION INTERFACES SYSTEM ANALYSIS TOP LEVEL PERFORMANCE REQUIREMENTS FUNCTIONAL BASELINE GEO-ECOMONIC ALTERNATIVES AFFORDABILITY BOUNDRIES ID KEY COST ATTRIBUTES AND RELATIONSHIPS CONDUCT LCC AND CAIV TRADE-OFFS Requirements Engineering Process Define customer needs Identify requirements Decompose requirements to appropriate working level Identify top-level functions Decompose functions to appropriate working level Integrate functional interfaces Define performance measures of effectiveness Identify Systematic Risks Define customer needs Identify requirements Decompose requirements to appropriate working level Identify top-level functions Decompose functions to appropriate working level Integrate functional interfaces Define performance measures of effectiveness Identify Systematic Risks Allocation CSCI HWCI requirements

19. 18 Topics 1.About Requirement 2.Guideline to define Requirement 3.Checklist of Requirement 4.Real Practice Case

20. 19 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications

21. 20 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications 5.5.3 Requirements Analysis Process 5.5.3.1 Purpose of the Requirements Analysis Process The purpose of the Requirements Analysis Process is to transform the stakeholder, requirement-driven view of desired services into a technical view of a required product that could deliver those services. This process builds a representation of a future system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the developers perspective, what characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements. 5.5.3.2 Requirements Analysis Process Outcomes As a result of the successful implementation of the Requirements Analysis Process: a) The required characteristics, attributes, and functional and performance requirements for a product solution are specified. b) Constraints that will affect the architectural design of a system and the means to realize it are specified. c) The integrity and traceability of system requirements to stakeholder requirements is achieved.... Source: ISO/IEC CD 15288 FDIS, © ISO/IEC2002.

22. 21 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications 5.3.2.1 The specific intended use of the system to be developed shall be analyzed to specify system requirements. The system requirements specification shall describe: functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; design constraints and qualification requirements. The system requirements specification shall be documented. 5.3.4.1 The developer shall establish and document software requirements, including the quality characteristics specifications, described below.... a) Functional and capability specifications, including performance, physical characteristics, and environmental conditions under which the software item is to perform; b) Interfaces external to the software item; c) Qualification requirements; d) Safety specifications, including those related to methods of operation and maintenance, environmental influences, and personnel injury; e) Security specifications, including those related to compromise of sensitive information... Source: IEEE/EIA 12207.0-1997, © IEEE 2001.

23. 22 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications 7.2 Build a well-formed requirement The analysts carry out this subphase by doing the following: a) Ensuring that each requirement is a necessary, short, definitive statement of need (capability, constraints); b) Defining the appropriate conditions (quantitative or qualitative measures) for each requirement and avoiding adjectives such as resistant or industry wide; c) Avoiding requirements pitfalls (see 6.4); d) Ensuring the readability of requirements, which entails the following: 1) Simple words/phrases/concepts; 2) Uniform arrangement and relationship; 3) Definition of unique words, symbols, and notations; 4) The use of grammatically correct language and symbology. e) Ensuring testability. Example: Capability: Move people between Los Angeles and New York Condition: Cruising speed of 200 km/hr Constraint: Maximum speed of 300 km/hr Well-formed requirement: This system should move people between Los Angeles and New York at an optimal cruising speed of 200 km/hr with a maximum speed of 300 km/hr. Source: IEEE 1233-1998, © IEEE 1998.

24. 23 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications Source: IEEE 1233-1998, © IEEE 1998.

25. 24 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications 5.3.2 Functions Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed as shall statements starting with The system shall These include: a) Validity checks on the inputs b) Exact sequence of operations c) Responses to abnormal situations, including: 1) Overflow 2) Communication facilities 3) Error handling and recovery d) Effect of parameters e) Relationship of outputs to inputs... 1) It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does not imply that the software design will also be partitioned that way. 5.3.3 Performance requirements This subsection should specify both the static and the dynamic numerical requirements placed on the soft- ware or on human interaction with the software as a whole. Static numerical requirements may include the following: a) The number of terminals to be supported; b) The number of simultaneous users to be supported; c) Amount and type of information to be handled. Source: IEEE 830-1998, © IEEE 1998.

26. 25 An Example - Requirements Development SP 2.1-1 Establish Product and Product Component Requirements –Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes –Clause 5.5.3 - Requirements Analysis Process IEEE/EIA 12207.0, Software Life Cycle Processes –Clause 5.3.2 - System Requirements Analysis –Clause 5.3.4 - Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications Source: IEEE 830-1998, © IEEE 1998.

27. 26 Topics 1.About Requirement 2.Guideline to define Requirement 3.Checklist of Requirement 4.Real Practice Case

28. 27 System Requirement Checklist Sect No Section TitleActivities 1 Introduction Overview of the SR document and description of what is to be produced and delivered for the Project, – all applicable and reference documents, Definitions, acronyms and abbreviations 2 Background Information about the general factors that affect the product(s) and their requirements, – physical, hardware, operating environments Relation to other systems, state whether the system is independent, subsystem of a larger one or a replacement 3 Specific requirements Information about project requirements: –Detailed requirements structured top-down, Feasibility study, Benchmarking study, Requirements Analysis, Project Planning, Evaluation of available products, Technological trials, Development of demonstrator (system mock-up) 4 Hardware requirements If the contract delivers hardware, specify requirements for each item of equipment; specify: type, number, functionality, standards, interfaces, performance, capacity, expansibility, reliability, availability, durability, maintainability, running cost limitations, operational requirements etc

29. 28 System Requirement Checklist 5 Tele-communication services Specify requirements if telecommunication facilities are to be delivered by the project. Omit this section if the project makes use of existing telecommunication facilities 6 System capability Functional (6.1) – purpose of system Interfaces (6.2) –Software: e.g., software environments, file formats, database management systems and other software applications · –Hardware: hardware configurations · –Communications: use of a particular network protocol · –External interface requirements should be described or referenced in Interface documents. User interface requirements should be specified under Operational requirements (see below). Interface requirements can be illustrated with system block diagrams · Operational (6.3) · Security (6.4) · Safety (6.5) Quality (6.6)

30. 29 System Requirement Checklist 7 System management Installation support (7.1) Diagnostic tools (7.2) Configuration, release control and faults (7.3) Instrumentation (7.4) Tuning (7.5) Back-up and recovery (7.6) Operational control (7.7) 8 Operational characteristics Capacity (8.1) –eg processing power, memory, disc space etc; include expansibility· Performance (8.2) – must be quantitative, not qualitative, statements; possibly include worst/best cases and nominal value to be used for planning· Availability (8.3) – details of days/times, tolerable breaks, system failure notification, usage during failure and availability monitoring · Reliability (8.4) – acceptable mean time between failure (MTBF), minimum acceptable MTBF; reliability verification

31. 30 System Requirement Checklist 9 System architecture Maintainability (9.1) – fault repair and adaptability in quantitative terms; influence of user availability/adaptability · Portability (9.2) – software ability to work on other (named) systems · Prescribed components (9.3) – applications, tools and techniques available from other projects and OSNs; consider Horizontal Actions and Measures · Software constitution and structure (9.4) – name actual products 10 Documentation Documents may include user training, user reference, system management, operational support, release notes, configuration control files, system maintenance, supplier reference, warranties 11 Other services ·Training (11.1), Installation processes (11.2), Data set- up (11.3), Parallel running (11.4), Operational support (11.5), Warranty (11.6) Maintenance (11.7)

32. 31 System Requirement Checklist 12 Developmental requirements Roles and responsibilities (12.1) Phases (12.2) Verification (12.3) A Requirements traceability matrix B Services provided by the Commission Specify any tools, services or facilities to be provided by or on behalf of the European Commission. Examples are equipment, software licences, telecommunication facilities, software from earlier systems, office facilities and services, staff time.(These are not requirements and are therefore shown in an appendix)

33. 32 Topics 1.About Requirement 2.Guideline to define Requirement 3.Checklist of Requirement 4.Real Practice Case

34. 33 One real case –for feasibility 1. 1.1 1.2 1.3 1.4 1.5 1.5.1 1.5.2 1.5.3 1.5.4 1.5.5 1.5.6 1.5.7 1.5.8 1.5.9 1.6 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.6.6 1.6.7 1.6.8 1.10.5 1.10.6 1.11 1.11.1 1.11.2 1.12 1.12.1 1.12.2 1.12.3 1.12.4 1.12.5 1.13 1.13.1 1.13.2 1.13.3 1.13.4 1.13.5 2. 3. 3.1 3.2 4. 1.6.9 1.7 1.7.1 1.7.2 1.7.3 1.7.4 1.8 1.8.1 1.8.2 1.8.3 1.8.4 1.9 1.9.1 1.9.2 1.9.3 1.9.4 1.9.5 1.9.6 1.10 1.10.1 1.10.2 1.10.3 1.10.4

35. 34 Question 1: Feasibility of Testable 1.WORK ( ) - MTBF ( ) 20,000 20,000 2.APPLICABLE STANDARD - 3.VERIFICATION REQUIREMENT - / …. 180 / …. (MCBF) /(MTBF) /(MTTR) 90% confidence ….

36. 35 Question 1: Feasibility of Testable No. of Failure(r)Test Ratio(M)Total Test Time(hr) 02.302620,000*2.3026=46,052(hr) 13.889720,000*3.8897=77,794 25.322320,000*5.3223=106,446 36.680820,000*6.6808=133,616 47.9936159,872 59.2747185,494 610.5321210,642 711.7709235,418 812.9947259,894 914.2060204,120 1015.4088308,176 MTBF 180 (4320 hours)Demonstration Test GEM (20,000 hours MTBF) 46,052 hours 0 failure non-feasible test item 4.IMPACT - 90% GEM (General Exponential Model) table 1. requirement 5,000 2. MTBF ( 1.5defets per 50 CPU operating hours)

37. 36 Question 2: Incompleteness of Requirement 1.WORK ( ) - - 2.APPLICABLE STANDARD - Requirement ( EMI EMC) 3.DELIVERY DOCUMENT – None 4.VERIFICATION REQUIREMENT - None 5.IMPACT - (1) ( ) (2) WBS Level 5DATA element (NDI DI) (3) (4)fault isolation 1. applicable standard ATP

38. 37 Question 3: Ambiguous of LAN Requirement 1.WORK ( ) - (LAN) (Network Cables) IEEE802 2.APPLICABLE STANDARD - IEEE802 Gigabit Ethernet IEEE 802.3z 1000 Base-T IEEE 802.3ab IEEE802.3u Fast Ethernet standard IEEE802.11 …. 3.DELIVERY DOCUMENT – None 4.VERIFICATION REQUIREMENT – None 5.IMPACT - (1) (2) (3) ….. 1. applicable standard ATP

39. 38 Question 4: Ambiguous of Software Requirement 1.WORK ( ) - 2.APPLICABLE STANDARD - SDG 2.0 1.8 1.System Mode- None 3.DELIVERY DOCUMENT – 4.VERIFICATION REQUIREMENT – None (Without TESTING BED) 5.IMPACT - (1)REWORK (2)hard to perform ATP (3)hard to plan test procedure ….. 1. VCRI (Verification Cross Reference Table) ATP

40. 39 Question 5: Ambiguous of Test Equipment 1.WORK ( ) - troubleshooting program calibrating 2.APPLICABLE STANDARD - None (if for Automatic Test Equipment) 1.Test Coverage- None 3.DELIVERY DOCUMENT – 4.VERIFICATION REQUIREMENT – 5.IMPACT - (1) O I D Level support equipment (2) test coverage (3) hardware fault isolation (3) software fault isolation

41. 40 Question 6: Feasibility of Software MTBF 1.WORK ( ) - 2.APPLICABLE STANDARD - None 3.DELIVERY DOCUMENT – None 4.VERIFICATION REQUIREMENT – MTBF= ( )/ ( ) 5.IMPACT - (1)