Requirement Engineering

1
Requirement Engineering

• Jean-Loup TERRAILLON,
• Dr. Eric CONQUET,
• TOS-EME
• Software Engineering standardisation section

2
Outline

• Scope of this domain
• Objectives of RD in this domain
• Relevant technologies required
• Major RD activities envisaged

3
Scope of this domain

• ECSS-E10 1.1B Draft 2 July 2002
• 4.3 Requirement engineering
• 4.3.1 Objectives of Requirements Engineering
• Requirement Engineering shall ensure
• a. proper interpretation of the customer needs
  and constraints, produce, consolidate and agree
  with the customer on technical requirements for a
  product that satisfies the customer needs,
• NOTE This can be done in interaction with the
  customer.
• b. generation, control and maintenance of a
  coherent and appropriate set of system and lower
  level specifications,
• c. full traceability of the requirements within
  the above set of specifications down to final
  verification close-out.
• Classes of requirements, attributes, criticality
  assessment, traceability
• Process capture, analysis validation,
  allocation, maintenance
• Functional Technical Spec
• Requirement management tools capture, analyse,
  allocate and prepare verification

4
Objectives of RD in the domain

• Manage complexity
• Completeness
• Consistency
• Feasibility, (understandable)
• Traceability (upper requirement, lower design,
  later verification)
• Verifiable as early as possible (implies to
  identify verification means)
• Manage schedule
• Shorter schedule
• System requirements are first so delay everybody
• Late system requirement change has large cost
  impact
• Improve communication system requirements /
  sub-system implementation
• Due to short schedule, subsystem implementation
  has to start when system is not yet fully defined

5
Relevant technologies required

• Requirement capture how to ensure completeness
  and consistency of the requirement set.
• Requirement management how to store and
  manipulate a big number of requirements.
• Requirement traceability
• From System to Subsystem requirements,
• From Subsystem requirements down to design,
  implementation and tests.

6
Requirement capture

• Guidelines for writing good requirements can be
  defined
• Establish a set of must be answered questions.
• Define templates for the different categories of
  requirements.
• Use a modeling formalism to support this phase,
  but
• modeling formalism is useful to capture
  functional requirements capturing other
  requirements is much more difficult.
• Use more formal languages
• Powerful language, but need trained engineers

7
Requirement management

• Requirements can take the form of
• Purely textual requirements,
• Graphical descriptions,
• Behavioural or data flow models (UML)
• Formal descriptions,
• Tools exist DOORS, Requisite Pro,
• Those tools are generally seen as too complicated
  and introduce too many constraints,
• But the complexity is more on the system than on
  the tool,
• Those tools just make things more visual,
• Such tools have to be associated with a process
  and a database and tool manager has to be
  nominated.

8
Requirement traceability

• Traceability links are easy to place but they
  only have a strong meaning if the requirement is
  verified.
• When a requirement is changed, impact analysis
  has to be performed.
• Tools that support requirement management offer
  support to traceability, but without guidelines
• Reports can be automatically generated to show
  the project status and make impact analysis,
• A project manager view can be generated to show
  level of requirement stability (needed to
  identify parts of the project to which attention
  shall be paid)
• Global requirements traceability may require huge
  databases (tool limitations and ease of use may
  require to split databases into smaller ones).

9
The example of software
System properties definition
Avionics Architecture Description Language (AADL,
UML, etc)
Projects
Performance optimisation
HW and communication description
Object-oriented architecture
Data models
Behavioural models
System properties verification
Tailoring
Automatic test generation
System models
Instantiation
Equipment models
Autocoding
SW/HW co-design
Generic 00 architecture frameworks and models
System/SW repository
System models
Software models
Data models
Cross compilation
FPGA / ASIC
Integration models
Open source
Performance validation
verification
Code
Code
Code
Standard drivers
Operational validation
Frameworks
Distributed middleware, operating system
Virtual satellite for VV
10
Major RD activities envisaged
Select an Architectural Language for Avionics
and implement tool support
Define the Process
System Software Co-Engineering Set-Up
Develop frameworks engineering process and tools
SPECIFY
Select and consolidate data model technology
Interface all the modelling views
Requirement Engineering
Behavioural models (State machines, Data Flow
Diagrams, synchronous and asynchronous languages)
Formal Methods
Performance and Properties Verification tools
HRT-UML
Requirement Management
Model Complexity/Cost Analysis
Value analysis, Natural Language processing