October 15th, 2009

Euro TeamAlauzet Pierre, Ahvenniemi Mikko,

Colin Julien, Starck Benoit

FDIR Spacecraft fault protection system

CS554 - Design for Software & Systems

Project 1Problem understanding

& UI design

TABLE OF CONTENTS

1.Problem understanding

2.Functional requirements (use-case model)

3.Non-functional requirements

4.Usability analysis & design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

3 / 24

October 15st 2009

Project 1October 15th, 2009

AHVENNIEMIALAUZET

COLINSTARCK

1. Problem understandingBusiness purpose & problem frames

1.Problem understanding

2.Functional requirements (use-case model)

3.Non-functional requirements

4.Usability analysis & design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

4 / 24

October 15st 2009

BUSINESS PURPOSE & REQUIREMENTS

Fault Detection, Isolation and Recovery (FDIR) system is monitoring systems for spacecraft.

FDIR Guarantee the completion of any time critical activities Provide manual control Display information continuously Collect data to data storage Locate the fault Store irresolvable conditions in reports Automatic recovery to failure Keep the control with safety, observability & commandability

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

5 / 24

October 15st 2009

PROBLEM FRAMES

Information Display

FDIR

Ground Control

Crew

Systems

FDIR Storage System

Report

Context Diagram :

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

6 / 24

October 15st 2009

PROBLEM FRAMES (CONT.)Problem diagram 1/2: Display information continuously

FDIR Display information

b: Systems!{functionnal/not funct. proper./broken}

b

a

Information display

Systems

c: Systems! {send value/no value}

c

d

d: FDIR! {display in tol/out-of-tol/no resp} a: Information display!{console}

Display problem frame

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

7 / 24

October 15st 2009

PROBLEM FRAMES (CONT.)Problem diagram 2/2: Information retrieval

FDIR Retrieve information

b:Crew!{search} FDIR!{display}

d

a

Crew/ Ground Control

FDIR Storage System

c:FDIR! {query} FDIR SS! {return data}

b

c

a: FDIR SS!{status data}

Commanded behaviour problem framed: Crew!{search}

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

8 / 24

October 15st 2009

PROBLEM FRAMES (CONT.)

New aspects of requirements were emphasized using problem frames.

Necessity of:

Clearly defining which domains

interact with the machine

Considering both data storage,

processing and display

Considering errors and

exceptions in interactions

Conclusion:

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

9 / 24

October 15st 2009

Project 1October 15th, 2009

AHVENNIEMIALAUZET

COLINSTARCK

2. Functional requirementsUse-case & sequences diagrams

1.Problem understanding

2.Functional requirements (use-case model)

3.Non-functional requirements

4.Usability analysis & design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

10 / 24

October 15st 2009

USE CASE DIAGRAMProblem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

11 / 24

October 15st 2009

SEQUENCE DIAGRAMS

Safe response in case of hazardous conditions :

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

12 / 24

October 15st 2009

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

13 / 24

October 15st 2009

SEQUENCE DIAGRAMS (CONT.)

Start system, restart system & refresh system state :

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

14 / 24

October 15st 2009

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

15 / 24

October 15st 2009

Project 1October 15th, 2009

AHVENNIEMIALAUZET

COLINSTARCK

3. Non-functional requirementsIdentified & improvised quality attributes

1.Problem understanding

2.Functional requirements (use-case model)

3.Non-functional requirements

4.Usability analysis & design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

16 / 24

October 15st 2009

IDENTIFIED ATTRIBUTESAttributes Explanations Priority

Testability

The system and its parts have to be able to be tested through inspections, simulations and analyses before on-board installation. Hence, FDIR functionality must be validated through a combination of inspection, simulation, and analysis. [EAS98]

Availability

The system must not lock or stall when processing data. It must work asynchronously and must be available all the time. Fault protection operates asynchronously, and may be invoked at any time. [EAS98]

Adaptability

The system has to be configurable in order to adapt to several environment. FDIR has to be adaptable for manned and unmanned spacecraft. It also has to adapt to several hardware component, different from one spacecraft to another.

For unmanned spacecraft […] additional requirements over those for unmanned craft. [EAS98]

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

17 / 24

October 15st 2009

IMPROVISED ATTRIBUTESProblem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

18 / 24

October 15st 2009

IMPROVISED ATTRIBUTES (CONT.)Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

19 / 24

October 15st 2009

Project 1October 15th, 2009

AHVENNIEMIALAUZET

COLINSTARCK

4. Usability analysis & designPrototypes & usability scenarios discussions

1.Problem understanding

2.Functional requirements (use-case model)

3.Non-functional requirements

4.Usability analysis & design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

20 / 24

October 15st 2009

USER INTERFACE DESIGN

Screen 1

System ListScreen 2

System InformationScreen 3

Logs

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

21 / 24

October 15st 2009

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

22 / 24

October 15st 2009

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

23 / 24

October 15st 2009

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

24 / 24

October 15st 2009

USABILITY SCENARIOS DISCUSSIONS

24 Views has to be consistent from one to another

25 Modification in one screen affect the others

15 Concurrent activities

16 Navigation within a single view

26 Displaying in different views & ways

03 Canceling actions

19 Display expected duration of any action

Problem understanding Functional Requirements Non-Functional Requirements Usability Analysis & Design

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

25 / 24

October 15st 2009

Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Project 1

26 / 24

October 15st 2009

CONCLUSIONSolutions to bring to system’s requirements

UML desig

n

Understand the underlying problems before considering any specification

Problem

frames

Measure the quality of interaction

Usabilit

y

October 15th, 2009

Euro TeamAlauzet Pierre, Ahvenniemi Mikko,

Colin Julien, Starck Benoit

FDIR Spacecraft fault protection system

CS554 - Design for Software & Systems

Project 1Problem understanding

& UI design

REFERENCES

1. [Eas98] Steve Easterbrook, and et al., Experiences Using Lightweight Formal Methods for Requirements Modeling” IEEE Transactions on Software Engineering, Vol. 24, No. 1, January 1998.

2. [Jac05] Michael Jackson, Problem frames and software engineering, Information and Software Technology, Special Issue: 1st Int Workshop on Advances and Applications of Problem Frames, K. Cox, et al. eds, Vol. 47 No. 14, pp. 903-912, Nov. 2005.

3.http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF, about non-function requirements