PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Share a file Manage my documents Convert Recover PDF Search Help Contact



gruppe xy architecture .pdf



Original filename: gruppe_xy_architecture.pdf
Author: Microsoft Office-bruker

This PDF 1.5 document has been generated by Microsoft® Word 2013, and has been sent on pdf-archive.com on 18/02/2016 at 05:44, from IP address 80.203.x.x. The current document download page has been viewed 287 times.
File size: 623 KB (3 pages).
Privacy: public file




Download original PDF file









Document preview


Task 4: Overall Architecture Design
Part 1: Intent of the System
Our system will visually alert the driver of critical information, like broken lights, engine
problems, failiing brakes etc. extending the functionality of the small and unnoticable
dashboard indicators. This will bring drivers closer to their cars, reduce the long term costs
of ignoring issues, and increase safety.

Part 2: Use cases
Name: Handbrake Error
Summary: User is notified of misuse of handbrake
Rationale: Many car users forget to turn off their handbrake before driving. This might cause
damage to the car if not dealt with.
Users: All users
Preconditions: Car is running, handbrake is on.
Basic course of events:
1. User starts the car, and the handbrake is switched on.
2. User shifts into gear and start accelerating.
3. The software will notice this and display a warning, telling the user that they need to
turn off the handbrake
4. User will turn off their handbrake.
Postconditions: Handbrake is turned off while driving.
Name: Broken Lights
Summary: Information about broken lights will be visible.
Rationale: Lights break frequently, and a major safety hazard for vehicles is driving with
impaired or broken lights. A lot of drivers use their car without being aware of having broken
lights, or they are aware but don’t think about it because they normally cannot see them.
"Out of sight, out of mind".
Users: All users
Preconditions: Car is running, one or more of the car lights are broken.
Basic course of events:
1. User is driving the car.
2. The software notices that one or more of the lights are not functioning
3. The software will make this information easily available on the display, by
highlighting a relevant icon.
4. The user will now think more about the problem of broken lights
Alternative paths:
1. In step 3, if the car has just been turned on, the software will display a bigger warning
about lights that are broken. This will fade after a short while of driving, to be less
invasive.
2. If every light in the car is broken, the software will deem this as more critical and the
warning will fade slower, or not at all
Postconditions: User is more aware of the lights in their car not working, and will more
quickly deal with the problem

Part 3: Overview of Product

Figure 1: Domain Model (Note LAL: Mener øverste pilene peker feil vei?)

Figure 2: Hand drawn illustration (1)

Figure 3: Hand drawn illustration (2)

Number of hours: 2h  6 people


gruppe_xy_architecture.pdf - page 1/3
gruppe_xy_architecture.pdf - page 2/3
gruppe_xy_architecture.pdf - page 3/3

Related documents


gruppe xy architecture
alternative introductory course
laptop screen repair troubleshooting steps1586
recover hard drive
basic knowledge about pc repair1728
proposal


Related keywords