R.Gerlich, R.Gerlich (BSSE)
Tool-Guided, Domain-Specific, Systematic Requirements Management Workshop W k h 07.10.2010 07 10 2010 “Requirementsengineering in der Luft- und Raumfahrt“ Fachausschuss Software Engineering T6.4 der DGLR Institut für Luft- und Raumfahrt, TU München, Garching bei München
Dr. Rainer Gerlich BSSE Systen and Software Engineering Auf dem Ruhbühl 181 88090 Immenstaad Germany © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
Tel. +49/7545/91.12.58 Fax +49/7545/91.12.40 Mobil +49/171/80.20.659 email
[email protected]
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
1
BSSE Technology: “at a touch“ Immediately executable system providing feedback through observed properties
Specification
Fully automated test cycle starting with source code as input providing feedback through measured properties int caseDemo(_IN_ TyMyEnum myEnum) { int ret; switch ((myEnum) y ) { case enum1: ret=1+(int)myEnum; break; case enum2: ret=2+(int)myEnum; break; case enum3: ret=3+(int)myEnum; break; case enum4: ret=4+(int)myEnum; break; default: ret=5; } return ret; }
Source Code
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
2
Overview
!
Status
!
Systematic Requirements Management
!
Applications
!
Conclusions
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
3
Text-based vs. Modelling Approaches
Text-based Approach
Model-based Approach
!
Imprecise requirements (natural language)
!
Formalised (i.e. defined form)
!
Tools only provide containers for requirements
!
Semantics = Model + Meta-Model
(free-text, black-box, no semantics)
!
Better support for verification and
!
Manual management of dependencies and links
!
Harmonisation requires discussion in the team
!
Non-specific: UML, SysML, ... (“universal”)
!
Overhead due to manual maintenance
!
domain-specific: more implicit information
!
No support for verification © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
validation
about domain DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
4
Improving Text-based Specifications
Glossary Knowledge Database (HOOD)
Limited Grammar (SOPHIST)
Interpretation, harmonisation, verification, validation and maintenance still manual labor Administrative, contractual and planning aspects not supported © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
5
Universal Modelling Approaches
UML
SysML
!
formal semantics only to a small degree; ambiguous
!
ambiguity is part of the strategy (universality)
!
major parts still as text
!
no support pp of non-functional requirements q
!
overwhelmed users (“How do I express ...?”)
!
inherits many UML issues (originally UML Profile)
!
central element is text-based requirements
!
formal requirements (e.g. OCL) have decidability issues
N information No i f ti about b t domain d i No inherent support for verification and validation Administrative, contractual and planning aspects not supported © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
6
Systematic, Domain-Specific Approaches Domain-Specific !
information about domain encoded in meta-model / semantics
!
unique representation of all relevant requirements
!
formal semantics,, user-centric representation p
!
still infinite set of applications
!
dependencies, links established / identified automatically
!
verification by tool possible (completeness, consistency, correctness)
Systematic !
verification by tool implemented
!
support validation by graphical / numerical feedback
!
quality measurement by domain-specific metrics
!
automatic test-case derivation
!
exploration of problem / solution space (what-if, version comparison)
!
connection to planning, software engineering, management, ...
!
guide the user; “slap on the wrist” © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
7
What the Title Means domain-specific • The application domain is known, e.g. distributed and/or real-time systems, or communicating processes • The number of supported applications out of this domain is infinite systematic • All issues of requirements management are supported inherently and silently by the method and the related tool: • Requirements engineering: structuring, analysis, elicitation, verification and validation • Administration: linking and tracing • Organisation (multi-team, multi-site) • Issues of project management tool-guided • All requirements are correlated by rules and an underlying meta-model • The method and tool can assess the quality of the requirements by concrete figures based on metrics applied to the requirements • These figures are provided as direct feedback to the user • The user is guided by this feedback towards a quality goal as specified by the meta-model © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
8
The Principal Approach for Systematic Requirements Management (SRM)
Requirements Capturing scheme to guide the user
iterative + incremental capturing
Validation
Metrics for feedback and quality analyses
Monitoring g of progress
Verification
visualisation of product properties
checks based on meta-model
graphics + reports
feedback by (fault) reports
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
9
Some Domains
Communicating Processes • Dynamic view on a system • Any system operations based on message exchange • Systematic Requirements Management (SRM) • Specification of system operations (complete coverage of all requirement types) • Distributed systems • Client-server systems • Checks based on metamodel • Auto-reporting • Correlation with project management issues • “at a touch“
Project Management • Systematic Project Management (SPM) • Specification of work packages, personell, resources, effort, inputs/outputs, due dates, cost rates etc. • Check of dependencies of work packages: • via explicit dependencies • Implicitly, via dependencies from input/putput coupling • Checks Ch k based b d on metat model • Auto-reporting • Bridge to MS-Project® • “at a touch“
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
Distributed Real-Time Systems • Executable specification (model-based) • Support of functional, functional behavioural and nonfunctional requirements • Verification on modelling level • Auto-coding • Model-based Testing • Auto-reporting • Validation support • “at a touch“
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
10
Some Projects
Product Lifecycle Management (PLM) • Configuration of a product by an end-user • Specification S f off the product definition assembly • Specification of the product configuration assembly • Specification of interaction with ERP (Enterprise Resource Planning), CRM (Customer Relation Management) etc.
Shop
Bank Transfer
Quality Analysis
• Shop-portal for end-user • Specification of all activities from f login, configuration, procurement, invoicong, delivery to payment
• Execution of a bank transfer • Specification of all activities from f login, definition of the transfer elements, check of creditwothiness to execution of transfer
• Analysis of several already existing specifications, ifi ti established with MS-Word® or UML • The efficient SRM approach allowed to transfer the requirements at low costs within a short time period • Resulted in “poor quality“ conclusions • Neither the applied (universal) tools nor users could identify incompleteness, inconsistency and incorrectness of the requirements from the chosen (universal) notation
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
Project Management • Definition of all planning, management and costt elements l t as needed for a proposal • For several projects • Checks on feasibility of planning
Distributed RealTime Systems • Experiment onboard ISS • In operation
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
11
Efficiency Figures (RE)
Example
Tool
# RQs
Effort*
Efficiency
/ m-h
/ (RQ / m-h)
PLM (Analysis)
Word
1000
14000
0.07
poor quality not completed
PLM (Analysis)
UML
~ 5600
200000
~ 0.028
poor quality not completed
PLM (Specification) Product Lifecycle Management
SRM
1000
1000
1
Shop (Specification)
SRM
300
100
3
Bank Transfer (Specification)
SRM
400
50
8
Embedded (Executable Specification)
SRM
5000
1000
5
*effort roughly estimated, figures indicate a trend © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
12
Logic Flow of Operation Error report Incremental refinement Information to be completed
Requirements from structured forms
Error report
Validation
Workbreak.-down + scheduling info
Syntax checks
Syntax checks
Meta-Model
SRM
Information to be completed
Planning info from structured forms
Meta-Model
SPM
Repository
Repository
Systematic Project Mgt
Evaluation of information
Evaluation of information
check
check
derive
Requirements document
report
Planning document
report
Scheduling Information Validation
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
derive
Planning document+ costs
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
13
Derived Information: Performance Predictions System
CRM ERP Shop St Store
max. CPU Utilisation (%) 80 80 80 80
CPU Time ms/d
Actual Utilisation (%)
36028813 54259275 31536491 74217643 Action
System CRM ERP Shop Store
41,7 62,8 36.5 85 9 85.9
Available Mass Memory (MB) 100000 100000 100000 100000
Needed Amount (MB/d) 23.50 7.80 3.60 14.70
Effort CPU Time # Consumed CPU Time (man-hours) (ms) (ms) Executions / d
accept registration
15
1
1000
1000
check registration data
10
4
1000
4000
committment period exceeded
5
1
10
10
committment period valid
5
1
500
500
compile list of ordered products
20
5
100
500
initiate monitoring of delivery
10
1
150
150
load data of registered user
10
2
400
800
reject registration
5
1
10
10
send confirmation of purchase order to user
15
1
150
150
validity check
5
3
510
1530
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
14
Requirement Types on Operational Systems – SRM 1/2 Requirements‘ Reference Requester Incoming Information Input Channel Processing Sequences
Akcion Output Channel OutgoingInformation Receiver Performance Profile Planning Information
Authorisation SRM Basic Information
Requirements‘ Reference Description Requirements‘ Reference
Systems
Availability
Size of Disk Storage
Resources Reliability Channels
max. CPU load
Transfer rate Protocol Synchronisation Name Description
Actions
CPU
Resources GUI Reference
Required Disk Storage
Estimated Effort © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
15
Requirement Types on Operational Systems – SRM 2/2 Skalare Strukturen Data Objects
Datenelemente Text
Textual Requirements Planning Information
Private Arrays N Name Type
References Documentation
Deadline
Output Planning Option SRM Basic Information
Work Package Effort Release Option Op o Planning Options Description
Planning Information
Assumption
Goal
Clarification
Actionee
open
Status
started
Work Package
completed
Deadline © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
16
SRM – Derived Information 1/2 System Interfaces Incoming Information vs. Systems Outgoing Information vs. Systems Actions vs. Systems Actions vs. GUIs Dependencies
Roles vs. Systems Systems vs. Systems
from requirements
Roles vs. Authorisation Commands vs. Data Data Archives vs. Systems DerivedInformation
Data Definitions vs. Usage System Tests Test Cases Interface Tests Data Budget vs. Systems Channel Load Resource Budgets
CPU Load Required disk space per system Event profiles
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
17
SRM – Derived Information 2/2 serious Flaws in requirements Error Reports
medium light
Planning flaws Total effort for actions
Derived Information
Effort
Releases
for GUIs per system Planning Reports
Planning options
Options
Sorted requirements Correlations
alphabetically
Sorting criteria
Statistics
Assumptions
Status
Distribution Requirement type
Goal Clarification Actionee Deadline Work package
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
18
Qualification vs. Activity Requirement-ID VVdemoANF-208 VVdemo-ANF-154 VVdemo-ANF-156 VVdemo-ANF-180 VVdemo-ANF-177 VVdemo-ANF-184
Kommunikation identification request no delivery possible price of configured product update configuration shopping basket restored orderRejected
A Actions vs. systems vs s. Channels vs. Data
What-If and Comparison of Versions
Requirement-ID AP Aktion Termin MA VVdemo-GR-322 WP1.1 Provide contents 31.01.00 RGs VVdemo-GR-332 WP1.1 clarify 2 15.01.00 TF VVdemo-GR-333 WP1.1 clarify 3 31.01.00 WW
SystemCommunication DOK-ID
Status offen in_Arbeit erledigt
Correlation with Planning • options • releases • clarification Requirement- Beschr Ort ID VV-GR-329 GR8 c_GR.xls, Z16 VV-GR-330 GR9 c_GR.xls, Z17 VV-GR-331 GR10 c_GR.xls, Z18 Kanal
Rel 2 3 4
Doc vs. RQ
Structured operational RQs • sequences • systems • channels • actions • data objects • communication
Dokument
ApplDocConfig ApplDocLogin ApplDocL Logout t ApplDocPurchase
RD Config Procedure RD Login Procedure RD Logout P Procedure d RD Purchase Order Procedure ApplDoc- RD Systems System
Typ doc doc doc doc
doc
Beschreibung
SRM / SPM Repository + Meta-model
User specific configurations shall be preserved after the end of a session. shall be restored at the beginning of the next session. Following standards shall be applied: enabled entries in black color disabled entries in gray color
Textual Requirements
Klärung Release 2 Release 3 Release 4
Testfall
Derived information
System
Ablauf
Daten
Betroffene Requirements Shop-PA-41, Shop-PA-34, … Shop-PA-9, ShopPA-11, … Shop-PA-16, Sh PA 17 … Shop-PA-17, Shop-PA-56, Shop-PA-53, … VVdemo-SYS-66, VVdemo-SYS-67
Bezug Planungsbezug Shop Shop Release 1 Shop
Release 2
Shop S Shop Shop
Alle Alle
Ergebnisse
Bezug zu RQ purchase order Shop-PArejected, purchase 53, Shoporder accepted PA-54
Daten- #Pak/d Volumen committment CRM Shopkeine rate MB/d check PurchaseOrder (MB/s) Shop-IF-CRM 10 2000 49.3 Shop-IF-ERP 10 3000 78.5 Requirement-ID System abgeleitet aus rejected Shop ShopcommentedC update Shop-PA-31 Shop-IF-Extern 10 1000 17.6 VVdemoProject-SYS- Shop Shop-PA-56, Shop-PAconfiguration Configuration onfiguration configuration Shop-IF-Intern 10 5000 234.8 66.syscom1 11, Shop-PA-53, … finalisePurcha Shop Shopkeine committment Shop-PA-51 Shop-IF-Portal 10 11000 443.9 VVdemoProject-SYS- Store Shop-PA-59, Shop-PAseOrder PurchaseOrder check Shop-IF-Store 10 4000 356.2 66.syscom2 60, Shop-PA-61, … © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt. 19
Requirements Capturing Element Type
Occurrence
Authorisations Process Sequences Documents Non-functional Requirements
1 1 1 1
Actions
11
Processings Steps Systems
10 5
Channels Data Objects TOTAL
1 14 59
Input notation may be adapted ! #
Requirement-ID
Sender
Incoming Request
Chann el
Actionee
Action
Outgoing Request
Receiver
Chan nel
1
CmdDemo-PA-2
SystemControl ExternalCmd
STD
CmdManager
Verify command
insertCmd
Queue
STD
2
CmdDemo-PA-3
CmdManager g
STD
Queue
sendACK
inqueue q
SystemControl y
STD
3
CmdDemo-PA-4
storeCmdInBuffer
NOP
NOP
NOP
4
CmdDemo-PA-5
validate
validateCmd
CheckCmd
STD
5
CmdDemo-PA-6
verifyCmd
checkResult
CmdManager
STD
6
CmdDemo-PA-7
NOP
getNextCmd
Queue
STD
7
CmdDemo-PA-8
CheckCmd
getNextCmd
STD
Queue
checkOnCmdLoss AL(lost) validateCmd CheckCmd
STD
8
CmdDemo-PA-9
CheckCmd
checkResult
STD
CmdManager
distribute
AL(isValid) ValidCmd
CmdDistribution
STD
9
CmdDemo-PA-10
NOP
AL(isInvalid) NAK
SystemControl
STD
10
CmdDemo-PA-11 CmdManager
NOP
NOP
NOP
Queue
insertCmd
validateCmd
ValidCmd
STD
STD
CheckCmd
CmdDistribution distributeValidCm d
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
20
Conclusions Universal vs. specific • Universal approaches give poor support to users, cannot conclude on the quality, and increase the overhead • Cause a lot of discussions on harmonisation of requirements coming from different teams, possibly on multiple sites • Limitation to a specific domain allows to make use of information for optimisation • Systematic organisation allows to guide a user towards high quality of specification and planning • Domain-specific approaches can support a large number of individual applications
Efficiency • Systematic organisation saves a lot of effort due to synergies enabled by the meta-model • Due to the inherent, integrated capabilities on quality assessments systematic approaches avoid a lot of human intervention • Due to the significantly reduced effort a user can concentrate on application issues rather than on maintaining links manually and looking for completeness, consistency and correctness of requirements
Verification and Validation • The underlying meta-model defines inherently the outmost quality goal for any application of the chosen domain • When the tool cannot identify an error anymore, the quality goal is reached • Due to the feedback from the tool a user can validate the requirements easily and immediately © Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
21
Interface to Existing Infrastructure
Existing Infrastructure • company-wide standards may exist requiring use of certain tools must • e.g. DOORS is often a “must“ • other tools may also have to be considered
Solution • SRM, SPM are applied on top of such tools • effort and risk can be reduced due to guidance, verification and validation • interface can be established to provide inputs to such tools which only are containers of information • links usually manually established in such standard tools can automatically be generated through such an interface
© Dr. Rainer Gerlich BSSE System and Software Engineering, 2010 All Rights Reserved
DGLR Workshop 07.10.2010, Tool-guided, Domain-Specific, Systematic Requirements Mgt.
22
