CONFIDENTIAL
INNOVATIONDAY 2011 Slide 2
SYSTEM REQUIREMENTS
ANALYSIS:THE FIRST STEP TO
VALUE
BASED SYSTEM DEVELOPMENT
CONF...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 3
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 4
What is a system requirement?
1. A need: a process or improvement, that
stakeholde...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 5
The bridge function of requirements
Requirements
Stakeholders
-) Business
-) Custo...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 6
For who are requirements important?
Requirements
Stakeholders
Customer
Service Pro...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 7
Users: The system must create Added Value
Utility
Desirability
Usability
Alowabili...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 8
What is the importance of requirements
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 9
If you cannot manage to define the requirements at the start of a project, than it...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 10
Conclusion: Leffingwell & Widrig (2003): Of the total budget for (software)
devel...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 11
Criteria for well-defined requirements
Completeness:
Consistency:
No missing requ...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 12
Criteria for well-defined requirements
Unambiguity:
Validity:
• Only 1 interpreta...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 13
Requirements Analysis issues
The first step in the system engineering process:
RE...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 14
System Requirements Analysis
In the traditional waterfall model of system develop...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 15
The System Engineering Process
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 16
Origin Process Inputs
Analyze all aspects of the entire system life cycle includi...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 17
Key System Requirements
• Operational :
Where will the system be used?
How long w...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 18
Break-down requirements
• Items to be Developed: These are the primary requiremen...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 19
Holistic approach
• Define the Functional & Performance
requirements
• Define Des...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 20
Define functional and performance requirements
 Functional requirements: What th...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 21
Constraints & Interfaces
Define design constraints:
Limit Design flexibility
Envi...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 22
Functional
Requirements
Performance
Requirements
Customer
Requirements
Security S...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 23
Break-down requirements
Security System for the Traffic Controller (Traffic Light...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 24
Design constraints
• Easy serviceability & maintainability
• Minor Assembly effor...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 25
Interface requirements
Routing the Error Messages to a Remote Central Security Sy...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 26
Functional Analysis & Allocation
• Clearly define the Global Framework and the di...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 27
Functional Analysis Tool: FAST diagram
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 28
Result: Functional Architecture
A Simple Rule:
Look to see if all the functions a...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 29
Refine Interface architecture
Controller
System
Sensors
Timer
Highway
Lights
Farm...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 30
Convert system architectures from Functional to Physical
Synthesis
• Physical dec...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 31
Morphological map
Alternative Design Concepts
Alternative concepts can be defined...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 32
Example: Mobile Phone
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 33
It is challenging to fix the concept, that will create the most Added
Value in re...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 34
System Analysis and Verification
• Diverge: create a spectrum of requirements, su...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 35
System Specifications
• Add the Secundary Development Items
• Clearly defined spe...
CONFIDENTIAL
INNOVATIONDAY 2011 Slide 36
Hogenakkerhoekstraat 21
9150 Kruibeke (B)
tel +32 (0)3 250 19 00
fax +32 (0)3 254...
Upcoming SlideShare
Loading in …5
×

Verhaert Innovation Day 2011 – Joris Vanderschrick (VERHAERT) - System Requirements Analysis

695 views

Published on

Speaker of Verhaert at the 8th edition of our Innovation Day on October 21st 2011.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
695
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Requirements define the needs and demands of the stakeholders invloved
    They form a bridge between the stakeholders and the development team
  • Is It feasible? Desirable? Allowable?
    Pain of absence? Pleasure of presence?
    Competitive advantage against Risk

  • 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
  • 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

  • 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
  • The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step  Development
  • 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

  • Functional and physical interfaces would include mechanical, electrical, thermal, data, control and other interactions.
  • 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.
  • 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.
  • 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.
  • 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.
  • By allocating these physical elements to the different functions and sub-functions of the system, you will generate a complete project or system architecture
  • Verhaert Innovation Day 2011 – Joris Vanderschrick (VERHAERT) - System Requirements Analysis

    1. 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
    2. 2. CONFIDENTIAL INNOVATIONDAY 2011 Slide 3
    3. 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. 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. 5. CONFIDENTIAL INNOVATIONDAY 2011 Slide 6 For who are requirements important? Requirements Stakeholders Customer Service Provider USERS Development Team Testers/ Validation
    6. 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. 7. CONFIDENTIAL INNOVATIONDAY 2011 Slide 8 What is the importance of requirements
    8. 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. 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. 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. 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. 12. CONFIDENTIAL INNOVATIONDAY 2011 Slide 13 Requirements Analysis issues The first step in the system engineering process: REQUIREMENTS ANALYSIS
    13. 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. 14. CONFIDENTIAL INNOVATIONDAY 2011 Slide 15 The System Engineering Process
    15. 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. 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. 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. 18. CONFIDENTIAL INNOVATIONDAY 2011 Slide 19 Holistic approach • Define the Functional & Performance requirements • Define Design constraints • Define the Interface requirements
    19. 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. 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. 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. 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. 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. 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. 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. 26. CONFIDENTIAL INNOVATIONDAY 2011 Slide 27 Functional Analysis Tool: FAST diagram
    27. 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. 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. 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. 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. 31. CONFIDENTIAL INNOVATIONDAY 2011 Slide 32 Example: Mobile Phone
    32. 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. 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. 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. 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.

    ×