Space 4.0 and the Belgian start-up ecosystem by Omar Mohout
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?
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
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
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.
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
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
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
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