31 July 2014 Copyright © 2014 Colin Hood Systems Engineering -1- Requirements Engineering: Eliminate and Automate Colin Hood Systems Engineering Evans

31 July 2014

Copyright © 2014 Colin Hood Systems Engineering -1-

Requirements Engineering:Eliminate and Automate

Colin Hood Systems EngineeringEvans Business CentreRegents Pavilion4 Summerhouse RoadMoulton ParkNorthampton NN3 6BJGreat Britain

Tel: 0044 1604 638 [email protected]

31 July 2014

31 July 2014


AutomateEliminate

Traceability

Requirements

Eliminate and Automate

31 July 2014


AutomateEliminate

Traceability

Requirements

Eliminate Requirements

31 July 2014

System

Interface

Mech.-E

lect. Interface

Mechanical

Electronics

Elect.-S

W Interface

Scheduling Software

Re

ad

Write

Filte

rP

riority

Fe

asib

ilityR

eq

ue

st

Customer Requirements

Eliminate Requirements

The major work in requirements development the stepwise refinement of interfaces.

31 July 2014

Simple Information Model

Sub-System Requirements

Sub-System Architecture

Sub-System Detailed Design





System Requirements

System Architecture




31 July 2014

Stepwise introduction of design constraints

Every level is a mixtureof freedom of choiceand constraints, somemore, and some less








System Requirements

System Architecture




31 July 2014








System Requirements

System Architecture




Customer

System Analyst

System Architect

Sub-System Analyst

Sub-System Architect

Sub-System Developer

Function Owner and Chief Requirements Engineer

Unless someone is responsible for satisfying customer requirements,no-one is responsible for satisfying customer requirements

Chi

ef R

equi

rem

ents

Eng

inee

r

Fun

ctio

n O

wne

r

Fun

ctio

n O

wne

r

31 July 2014








System Requirements

System Architecture




Customer

System Analyst

System Architect

Sub-System Analyst

Sub-System Architect

Sub-System Developer

Architectural Team of Experts

The architect as leader of a team of experts

The major role of the architects is to act as team leader, leading a team of sub-system experts to negotiate and decide together how higher level requirements should be implemented in sub-systems.

31 July 2014

Copyright © 2012 Colin Hood Systems Engineering Ltd -10-

AutomateEliminate

Traceability

Requirements

Automate Requirements

31 July 2014







Requirements Processes


System Requirements

System Architecture




ElicitSpecifyQuality CheckRelease

Understand

31 July 2014

Automatically Creating Textual Requirements

Diagrams can be usedboth to documentdesigns, and todocumentunderstanding.

Here we consider thediagrams used todocument understanding.

State Transition Diagram

31 July 2014


Current State ->

Reference to Customer

RequirementEvent State Design

Open(A)

Closed(Unlocked)(B)

Closed Locked and not yet signalled(C)

Closed, Locked and signalling(D)

Description of State ->

1 or more door(s) is ajar. No other action taken in this state

All doors are closed and the vehicle is unlocked

The vehicle has just been locked

The vehicle has been locked and the turn indicators are flashing

ACTION -> None None lock vehicle

Flash Turn Indicators to show sucessful lock

R1 1.1.1.1.1

the Ignition Status is OFF, the Ignition Key is out, and the key in the driver's or passenger’s door lock cylinder is turned to the lock position or the lock button is pressed on the Remote Key (if configured) and Reverse Cycling configuration. F C C C

R2 1.1.1.1.1

the Ignition Status is OFF, the Ignition Key is out, and the key in the driver's or passenger’s door lock cylinder is turned to the lock position or the lock button is pressed on the Remote Key (if configured) and Slam locking configuration. G C C C

S 1.1.1.1.2, 1.1.1.1.3 All doors are closed and locked X X X D

State Transition Table

31 July 2014


Generating sentences from frameworks

1. 1979: specifications written by programmers

2. 1985: direct from specification to code, overwhelmed by design detail

3. 1993: direct from specification to code, design detail pre-determined

4. 1998: Using DOORS to create requirements from templates

5. 2008 – 2011: Using DOORS to create requirements from templates

For User Requirements this is a simplified example based upon ideas from Richard Stevens:

The <user> shall [not] be able to <perform this function>, [under <these conditions>] [, with <this performance>]

Sentence Templates

31 July 2014


AutomateEliminate

Traceability

Requirements

Eliminate Traceability

31 July 2014

Eliminate Traceability

One organisation say they do not document for traceability because: they find that any documentation is less than perfect, they do not know where the mistakes are, so they do not know which documentation to trust,

therefore they mistrust all documented dependencies.

Could anyone understand your documentation without your help?

31 July 2014


AutomateEliminate

Traceability

Requirements

Automate Traceability

31 July 2014

Automate Traceability

Creating traceability documentation automatically

1. Traceability via Name

2. Traceability via Object

3. Traceability via Reference

4. Traceability via Link

Visio

DaVinci

DOORS

Link

Object

Name

CustomerRequirements

SystemRequirements

SystemArchitecture

SoftwareRequirements

SoftwareArchitecture

Requirements Interfaces Structure Sys. Behaviour

31 July 2014


Do as little as possible, and as much as necessary.

Conclusion

31 July 2014


Colin Hood Systems EngineeringEvans Business CentreRegents Pavilion4 Summerhouse RoadNorthampton NN3 6BJ – UK

[email protected]. +44 1604 638 302

Systems Engineering since 1985

Founding Member of IREB 2006(International Requirements

Engineering Board)

Member of INCOSEsince 1998

31 July 2014

Reasons to reduce the number of requirements

It takes twice as long to check a requirement as it takes to write it

It takes twice as long to check a link as it does to create it

It takes about as long to create a correct link as it does to write a requirement

So for each requirement, it takes six times more effort than we might at first think

And then we still have to document the attributes…

31 July 2014

Do not blindly follow a process

widely accepted is the belief that we need to re-write requirements at each level. At the architectural levels some believe that requirements need to be derived from the level above in order to allocate from the system to the sub-systems. In some development environments, this is exaggerated to such an extent that even when it is known that a requirement from a higher level is sufficient and acceptable, the requirement is re-written just because people think that the process demands this.

Well, I would like you to print out the above paragraph, tear it into little pieces, and set fire to it.

31 July 2014

Traceability

Traceability is the ability to follow requirements and related information throughout the network of dependencies.

Creating the possibility to follow requirements and related information throughout the network of dependencies:

takes a lot of time costs money introduces errors is necessary

Documents

31 July 2014 Copyright © 2014 Colin Hood Systems Engineering -1- Requirements Engineering: Eliminate and Automate Colin Hood Systems Engineering Evans