Verhaert Innovation Day 2011 – Joris Vanderschrick (VERHAERT) - System Requirements Analysis
Download as PPTX, PDF0 likes3,778 views
The document discusses the importance of system requirements analysis as the first step in value-based system development. It outlines key aspects of defining requirements such as completeness, consistency, and validity. Requirements must fulfill stakeholder needs and create added value. The analysis process involves understanding user needs, developing functional and performance requirements, defining design constraints and interfaces, and analyzing and verifying solutions to select the optimal system concept.
Verhaert Innovation Day 2011 – Joris Vanderschrick (VERHAERT) - System Requirements Analysis
- 1. CONFIDENTIAL INNOVATIONDAY 2011 Slide 2 SYSTEM REQUIREMENTS ANALYSIS:THE FIRST STEP TO VALUE BASED SYSTEM DEVELOPMENT CONFIDENTI AL Joris Vanderschrick Embedded system development Joris.vanderschrick@verhaert.com
- 3. CONFIDENTIAL INNOVATIONDAY 2011 Slide 4 What is a system requirement? 1. A need: a process or improvement, that stakeholders want to realize through a system. 2. A demand to a system: the behavior (= functionality) or quality (= performance) that a system must have to fulfil the need of the stakeholders. Uit: Handboek Requirements
- 4. CONFIDENTIAL INNOVATIONDAY 2011 Slide 5 The bridge function of requirements Requirements Stakeholders -) Business -) Customer -) Users … Development Team • Requirements: What the system must be able to do… • Stakeholders: …to optimally be able to support us • Development team: …and we have to implement them
- 5. CONFIDENTIAL INNOVATIONDAY 2011 Slide 6 For who are requirements important? Requirements Stakeholders Customer Service Provider USERS Development Team Testers/ Validation
- 6. CONFIDENTIAL INNOVATIONDAY 2011 Slide 7 Users: The system must create Added Value Utility Desirability Usability Alowability Feasibility AddedValue The ‘requirements’ must enable the developed system concept to create Added Value for the end- user • What is the Added value of your product/system?
- 7. CONFIDENTIAL INNOVATIONDAY 2011 Slide 8 What is the importance of requirements
- 8. CONFIDENTIAL INNOVATIONDAY 2011 Slide 9 If you cannot manage to define the requirements at the start of a project, than it does not matter anymore how good you execute the following actions. Importance of adequately defining the requirements Phase Relative Correction costs Requirements 1-2 Technical Concept 5 Realisation 10 Unit Test 20 Acceptance Tst 50 Maintenance 50 Davis (1993)
- 9. CONFIDENTIAL INNOVATIONDAY 2011 Slide 10 Conclusion: Leffingwell & Widrig (2003): Of the total budget for (software) development tasks, 25 to 40% will be spent on the correction of errors in the requirements. Importance of ‘good’ requirements
- 10. CONFIDENTIAL INNOVATIONDAY 2011 Slide 11 Criteria for well-defined requirements Completeness: Consistency: No missing requirements: All the requirements, that the system must fulfil, must be defined No conflicting requirements: Requirements can conflict when stakeholders have different opinions about the specific demands for the systems
- 11. CONFIDENTIAL INNOVATIONDAY 2011 Slide 12 Criteria for well-defined requirements Unambiguity: Validity: • Only 1 interpretation possible of the requirements. • Not 100% possible Written in natural language Requirements are only valid if they contribute to the added value for the stakeholders “Around 45% of the developed functionality for a system is never used!” “Don’t waste time with the overkill functionality.“ The Standish Group, 2003
- 12. CONFIDENTIAL INNOVATIONDAY 2011 Slide 13 Requirements Analysis issues The first step in the system engineering process: REQUIREMENTS ANALYSIS
- 13. CONFIDENTIAL INNOVATIONDAY 2011 Slide 14 System Requirements Analysis In the traditional waterfall model of system development, the first phase of requirements analysis is also the most important one. Goal: • Understanding the customer's business context and constraints • Functions the product must perform • The performance levels it must adhere to • The external systems it must be compatible with
- 14. CONFIDENTIAL INNOVATIONDAY 2011 Slide 15 The System Engineering Process
- 15. CONFIDENTIAL INNOVATIONDAY 2011 Slide 16 Origin Process Inputs Analyze all aspects of the entire system life cycle including all equipments touch points with consumers, installers, service & maintenance staff 1. Customer Needs/Objectives/Demands • Goals • Measures of Effectiveness • Environments • Constraints 2. Other: • Technology Base • Output Requirements from Prior Development Effort • Requirements Applied Through Specifications and Standards Attract Choose UseSupport Retain Customer Needs Objectives Demands
- 16. CONFIDENTIAL INNOVATIONDAY 2011 Slide 17 Key System Requirements • Operational : Where will the system be used? How long will the system be in use by the user? • Environmental: How are the various system components to be used? Utility! What environments will the system be expected to operate in an effective manner? • Goal: How will the system accomplish its mission objective? Added Value! • Performance: What are the critical system parameters to accomplish the goal? How effective or efficient must the system be in performing its goal?
- 17. CONFIDENTIAL INNOVATIONDAY 2011 Slide 18 Break-down requirements • Items to be Developed: These are the primary requirements that will create the added value of the system. The biggest development efforts are initiated to fulfil these requirements. • Specifications: Secundary development Items: These are the quantified requirements that do not need much development effort. They can immediately be fulfilled by existing components or sub-systems. Usually purchasing parts.
- 18. CONFIDENTIAL INNOVATIONDAY 2011 Slide 19 Holistic approach • Define the Functional & Performance requirements • Define Design constraints • Define the Interface requirements
- 19. CONFIDENTIAL INNOVATIONDAY 2011 Slide 20 Define functional and performance requirements Functional requirements: What the system must do… Performance requirements: How well the system must perform… Break-down of the ITD
- 20. CONFIDENTIAL INNOVATIONDAY 2011 Slide 21 Constraints & Interfaces Define design constraints: Limit Design flexibility Environmental conditions & limits Standards Interface requirements: Define the functional and physical interfaces to external or higher-level and interacting systems.
- 21. CONFIDENTIAL INNOVATIONDAY 2011 Slide 22 Functional Requirements Performance Requirements Customer Requirements Security System for the Traffic Light Controller Functional Requirements Performance Requirements Customer Requirements Interface System between traffic lights & Central for coördination Traffic Light Controller IPC Remote Security System Central for coordination Interface Requirements Interface Requirements
- 22. CONFIDENTIAL INNOVATIONDAY 2011 Slide 23 Break-down requirements Security System for the Traffic Controller (Traffic Lights) Functional Requirements: • Polling the Traffic Controller for Error • Analysis of the Error Messages • Routing the Error Messages to a Remote Central Security System Performance Requirements: • Polling speed (@1Hz) • Data transfer speed Error report available at remote system within 20 seconds • Redundant Interface System Functional Requirements: • Receiving commands of the central system for the coordination of the Traffic Lights • Translating the specific command towards the protocol of the Traffic Controller Performance Requirements: • Reaction time between command & traffic lights change: <3 seconds
- 23. CONFIDENTIAL INNOVATIONDAY 2011 Slide 24 Design constraints • Easy serviceability & maintainability • Minor Assembly efforts • Re-use known company plaforms: Cirrus Logic ARM • Easy accessiblity • IP-67 • No internal Airflow • System temperature up to 70°C. • Migration options for future communication upgrades • EN-50129 Safety related electronic systems for signaling
- 24. CONFIDENTIAL INNOVATIONDAY 2011 Slide 25 Interface requirements Routing the Error Messages to a Remote Central Security System Receiving commands of the central system for the coordination of the Traffic Lights • Functional: IPC communication network to the Security & Interface system • Physical layer: Long-range wireless network or installed cable infrastructure Polling the Traffic Controller for Error • Functional: IPC communication network to the Traffic Controller • Physical layer: Short-range wireless network
- 25. CONFIDENTIAL INNOVATIONDAY 2011 Slide 26 Functional Analysis & Allocation • Clearly define the Global Framework and the different sub modules • Define successively lower-level functions • Allocate Performance and other limiting requirements • Defining/Refine functional architectures at ever-increasing levels of detail • Refine the Internal/External Functional Interfaces
- 26. CONFIDENTIAL INNOVATIONDAY 2011 Slide 27 Functional Analysis Tool: FAST diagram
- 27. CONFIDENTIAL INNOVATIONDAY 2011 Slide 28 Result: Functional Architecture A Simple Rule: Look to see if all the functions are verbs. If there is a function identified as a noun, then there is a problem with the understanding of the functions.
- 28. CONFIDENTIAL INNOVATIONDAY 2011 Slide 29 Refine Interface architecture Controller System Sensors Timer Highway Lights Farmroad Lights Detect Tractor Long Time Over Short Time Over Restart Command Green ON Command Yellow ON Command Red ON Command Yellow ON Command Red ON Command Green ON
- 29. CONFIDENTIAL INNOVATIONDAY 2011 Slide 30 Convert system architectures from Functional to Physical Synthesis • Physical decomposition defines the physical elements needed to execute the function. • Define preferred physical solutions for the Primary and Secondary Development Items • Define Internal and External Physical Interfaces • Define Alternative System Concepts (Morphological map)
- 30. CONFIDENTIAL INNOVATIONDAY 2011 Slide 31 Morphological map Alternative Design Concepts Alternative concepts can be defined via a Morphological map that provides a structure overview of the different Items to Be Developed (ITD’s) and the different options to develop them. to a correct Risk Profile
- 31. CONFIDENTIAL INNOVATIONDAY 2011 Slide 32 Example: Mobile Phone
- 32. CONFIDENTIAL INNOVATIONDAY 2011 Slide 33 It is challenging to fix the concept, that will create the most Added Value in respect to a correct Risk profile. This is a very important task when defining the best System concept
- 33. CONFIDENTIAL INNOVATIONDAY 2011 Slide 34 System Analysis and Verification • Diverge: create a spectrum of requirements, sub-modules, functions, solutions,… Avoid fixation to 1 or 2 solutions Other options will become variations • Verfication: Verify with the requirements, constraints, main goal, Added Value • Converge: Trade-Off the different solutions and select
- 34. CONFIDENTIAL INNOVATIONDAY 2011 Slide 35 System Specifications • Add the Secundary Development Items • Clearly defined specifications and baselines • System Architecture • Concept Design • Decision Database
- 35. CONFIDENTIAL INNOVATIONDAY 2011 Slide 36 Hogenakkerhoekstraat 21 9150 Kruibeke (B) tel +32 (0)3 250 19 00 fax +32 (0)3 254 10 08 info@verhaert.com More at www.verhaert.com helps companies and governments to innovate. We design products and systems for organizations looking for new ways to provide value for their customers. We are a leading integrated product innovation center; creating technology platforms, developing new products and business in parallel, hence facilitating new- growth strategies for our clients.
Editor's Notes
- #6: Requirements define the needs and demands of the stakeholders invloved They form a bridge between the stakeholders and the development team
- #8: Is It feasible? Desirable? Allowable? Pain of absence? Pleasure of presence? Competitive advantage against Risk …
- #10: Inconsistent, missing or wrong requirements will keep on influencing the results during the development activities. The cost to correct errors will increase significantly, the further you progress in the development & deployment cycle
- #12: The definition of each requirement must contain detailed information The definition is complete when the developers have enough information to realize the system Solution: Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project. Solution: Be a clear as possible in the definition of requirements
- #14: No well-specified customer requirements Management of changes to the requirements Sufficient User’s Inputs? Good Communication: Avoid gaps between the customers and the development team
- #15: The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step Development
- #18: Customer Requirements: Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering (Chapter 1), with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in
- #22: Functional and physical interfaces would include mechanical, electrical, thermal, data, control and other interactions.
- #27: Bij veel ontwerpmethodes een strikte scheiding aangehouden tussen twee fases in het proces: In de divergente fase wordt een aantal ideeën gegenereerd, waarbij geen selectie plaatsvindt. Men spreekt van divergentie, omdat het aantal ideeën hierbij toeneemt. Dit is gebaseerd op het principe, dat bij een grote hoeveelheid ideeën de kans op goede ideeën toeneemt, en dat door het achterwege laten van selectie de creativiteit niet wordt gehinderd. Nadat op deze wijze een groot aantal ideeën is verkregen, volgt de convergente fase. hierbij vindt pas beoordeling en selectie. Men spreekt van convergentie, omdat het aantal ideeën hierbij wordt gereduceerd. Het principe hierbij is, dat men oplossingen slechts goed kan beoordelen indien men het geheel overziet. In de beschreven methode is er sprake van divergentie tot aan het combineren van oplossingen. Convergentie vindt hoofdzakelijk pas plaats bij het schiften van de oplossingscombinaties.
- #28: Bij veel ontwerpmethodes een strikte scheiding aangehouden tussen twee fases in het proces: In de divergente fase wordt een aantal ideeën gegenereerd, waarbij geen selectie plaatsvindt. Men spreekt van divergentie, omdat het aantal ideeën hierbij toeneemt. Dit is gebaseerd op het principe, dat bij een grote hoeveelheid ideeën de kans op goede ideeën toeneemt, en dat door het achterwege laten van selectie de creativiteit niet wordt gehinderd. Nadat op deze wijze een groot aantal ideeën is verkregen, volgt de convergente fase. hierbij vindt pas beoordeling en selectie. Men spreekt van convergentie, omdat het aantal ideeën hierbij wordt gereduceerd. Het principe hierbij is, dat men oplossingen slechts goed kan beoordelen indien men het geheel overziet. In de beschreven methode is er sprake van divergentie tot aan het combineren van oplossingen. Convergentie vindt hoofdzakelijk pas plaats bij het schiften van de oplossingscombinaties.
- #29: Bij veel ontwerpmethodes een strikte scheiding aangehouden tussen twee fases in het proces: In de divergente fase wordt een aantal ideeën gegenereerd, waarbij geen selectie plaatsvindt. Men spreekt van divergentie, omdat het aantal ideeën hierbij toeneemt. Dit is gebaseerd op het principe, dat bij een grote hoeveelheid ideeën de kans op goede ideeën toeneemt, en dat door het achterwege laten van selectie de creativiteit niet wordt gehinderd. Nadat op deze wijze een groot aantal ideeën is verkregen, volgt de convergente fase. hierbij vindt pas beoordeling en selectie. Men spreekt van convergentie, omdat het aantal ideeën hierbij wordt gereduceerd. Het principe hierbij is, dat men oplossingen slechts goed kan beoordelen indien men het geheel overziet. In de beschreven methode is er sprake van divergentie tot aan het combineren van oplossingen. Convergentie vindt hoofdzakelijk pas plaats bij het schiften van de oplossingscombinaties.
- #30: Bij veel ontwerpmethodes een strikte scheiding aangehouden tussen twee fases in het proces: In de divergente fase wordt een aantal ideeën gegenereerd, waarbij geen selectie plaatsvindt. Men spreekt van divergentie, omdat het aantal ideeën hierbij toeneemt. Dit is gebaseerd op het principe, dat bij een grote hoeveelheid ideeën de kans op goede ideeën toeneemt, en dat door het achterwege laten van selectie de creativiteit niet wordt gehinderd. Nadat op deze wijze een groot aantal ideeën is verkregen, volgt de convergente fase. hierbij vindt pas beoordeling en selectie. Men spreekt van convergentie, omdat het aantal ideeën hierbij wordt gereduceerd. Het principe hierbij is, dat men oplossingen slechts goed kan beoordelen indien men het geheel overziet. In de beschreven methode is er sprake van divergentie tot aan het combineren van oplossingen. Convergentie vindt hoofdzakelijk pas plaats bij het schiften van de oplossingscombinaties.
- #31: By allocating these physical elements to the different functions and sub-functions of the system, you will generate a complete project or system architecture