SOFT 423: Software Requirements - Queen's...

SOFT 423: Software Requirements

Week 11 Class 1

Telescope Example – End-to-End

SOFT 423 – Winter 2015 1

Last Class

•CRUDO

•Activity Diagrams


This Class

•Telescope System Example•We won’t get into full details•A look at what is done at each phase


The System

•Telescope Control System•24” Telescope (mirror size)


Elicitation


Interviews

•Doug•Past President and Lead on Venour Project

•Tom•Past Chair of ATM committee and Observing Chair


Stakeholders

•Amateur Telescope Making (ATM) Contacts•Tom and Doug


Stakeholders


•System Team


Stakeholders

•Users (how many user groups?)•Novice User•Demanding Astrophographer•Casual User•Public Observing Supervisor•Public Observer


Stakeholders

•Users (how many user groups?)•Novice User•Demanding Astrophographer•Casual User•Public Observing Supervisor•Public Observer

•Developers and Testers


The Problem

•Once a proper site is found, and observatory will be built to house telescope on a permanent basis. Members want to use the scope for advanced research as well as Photography


The Problem

•The telescope will be used for public observing. The scope is aimed at a given celestial object and the public takes turns looking through the scope.


The Problem

•The scope is taken to star parties. These are gatherings of amateur and professional astronomers in remote locations.


The Problem

•The scope must remain mobile so that it can be used at start parties and public sessions.


The Problem

•The scope needs an electronic tracking system to control the scope. Astrophotography requires that the scope maintain a high pointing accuracy over 10-20 minute periods


Background Research (Telescopes)

•Two kinds of mounts, Equatorial and Alt-Azimuth.•both mounts have two axis

•Equatorial has one aligned with Earth’s axis (i.e. on an angle), easy to track

•Alt-Az is often called a cannon mount• local coordinates, harder to track




Credit:Marie-Lan Nguyen



Credit: Wikipedia user ECeDee

Background Research (Coordinates)

•Stellar Coordinate Systems (RA, Dec)•equatorials use this

•Local Coordinate System (Alt,Az)•alt az uses this

•The sky moves 360° in 23 hrs 56 minutes, 4.009 seconds (360/86164 = 0.00417 °/s)•Resolution of a telescope: 4.466/D(inches) = 0.2 arc seconds (0.0000555 degrees)•75 times a second... (upper limit)•40 steps a second reasonable...


Background Research (Tracking)

•Telescope tracking is difficult at zenith (directly overhead) (telescope must spin)•need to warn user for photography•public viewing

•Slewing speed (5 °/s)

•Field De-rotation


Background Research (General)

•Three star alignment algorithm

•Mount errors characterization (backlash)

•Existing Solutions•Commercial (Dobdriver II)•Open Source (Mel Bartel)


Background Research (Astronomy)

•Celestial Object Database•Messier, NGC, Stellar Names

•Lunar, Solar and Planetary motion•planetary includes planetoid (comets) and extra-terrestrial moons.•ephemeris descriptors, calculations•eccentricity

•Meteorological considerations


Stakeholder Needs (System Team)

•Details of the LCD Screen (special symbols LCD screen vs Alphanumeric)

•Keypad Layout and Keys (do we get to label the keys, or has the system team designed the labels)


Stakeholder Needs (System Team)

•Details of motor drive trains

•Possible existence of encoders?

•Details of microprocessor

•Clock accuracy, clock drift


Stakeholder Needs (RASC Kingston)

•(Royal Astronomical Society of Canada)

•Cost/Delivery Schedule

•Priorities

•Acceptance Testing Details

•Ranking of functionality for schedule slippage


Stakeholder Needs (RASC Kingston)

•(Royal Astronomical Society of Canada)

•Other Details based on background research

•Details of User group needs based on background research


Stakeholder Needs (Developers and Testers)

•Feasibility: •Capacity of micro controller : Stellar

• Database Size (need extra external disk?)

•reconciled with system team’s hardware design•Speed of Microprocessor

•Development time/cost estimates


AnalysisProblem Domains


PDOA

•System Types?


PDOA

•System Types?•Control•Information•Connection


PDOA



Commanded Behaviour Frame


TelescopeControlRules

User

Telescope

Controller

TelescopeAnd FieldRotatorPosition

Control Frames


Content Techniques

Data model for subdomains Entity Relationship Diagram, Data Dictionary

Characteristics and innate behaviour of subdomains, causal laws

Text, Finite State Machines, DecisionTables

Shared phenomena observed Text (event list)

Actions that can be initiated Text (action list)

Distortions or delays introduced by a Connection Domain

Text

Behaviour rules and valid commands

Text, Finite State Machines, DecisionTables

Control Frames

•Data model for subdomains•telescope position

• Straightforward degrees

•Sky• Data model for celestial objects

• static coordinates for star and deep space objects

• coordinate formats for various • movable celestial objects


Control Frames

•Characteristics and innate behaviour of subdomains, causal laws•most astronomy information•coordinate systems, rate of sky motion, dynamic body calculations (lunar, planet, etc.)•telescope motion limitations (vertical, horizon)•alt azimuth characteristics (including field rotation requirements)


Control Frames

•Shared Phenomena observed•Three star alignment (user interaction)•user fine grain control (user interaction)•manual slewing• internal position model (discrete control over motors)•encoders


Control Frames

•Actions that can be initiated•Position telescope horizontally•Position telescope vertically• internal position model (discrete control over motors)•encoders


Control Frames

•Distortions or delays introduced by a Connection Domain•We have a separate connection domain were we will look at this


Control Frames

•Behaviour rules and valid commands•Tracking rules (translation, update frequency)•Three star alignment•Manual slewing•Manual guiding•Automatic slewing• tracking while performing lookup

(concurrency)•User Modes (for tracking input)•Reference Formal models


PDOA



Information System Frames


InformationSystem

RealWorld

InformationFunction

Reports

Information Frames

•Not going to go through each table entry for this one…

•…you get the idea


Information Frames

•Really two information systems•Telescope position

• provides feedback to user on current position of telescope

•Celestial Database System• Allows users to look up celestial objects and pass

information to the control frame


PDOA



Connection System Frames

•Again, there is no need to go through the table line by line.



•Abstracts management of telescope•Control domain is user to telescope position•Similar to 4 variable NAT

•Describes interface to motors (4 phase lines to each of alt and az, 2 phase control of field rotator)•Description of Mount Errors•Description of physical drive train including

backlash/vibration calculations



•Acceleration/Deceleration

•Max speed of motors

•Max precision of motors (micro-stepping)


AnalysisModeling, NFR, and the Requirements Document


Representational Modeling

•User Display (Static)•Menu Driven System for tasks such as looking up objects, Three star alignment, etc•storyboard

•Keyboard Layout•interface prototype•computer program with window for display

window for buttons, window with animated picture of telescope


Non-Functional Requirements

•Performance•Slew speed



•Capacity•Number of stellar objects in database



•Safety•When tracking close to overhead, telescope must turn rapidly. What happens if random member of the public is on the ladder 12 feet in the air?•Bright Objects - when skewing, what happens if we move the moon into the field of view


The Requirements Document

•Distill Analysis into Document

•Multiple User Classes (important)


Specification


Specifying the Requirements

•Finite State Model of some sort•SCR

• SCR description ignores connection system• Some concurrency, so multiple mode variables are

required.

•state charts also possible


Specifying the Requirments

•Data model of database including both static and dynamic celestial objects•DD vs ER


The Specification Document

•Distill into Document•this example is rather easy to stay away from any premature design


Validation


Validation

•First things first…•Documents reviews

• Format, all the sections, etc.

•Make sure all of the easy stuff is taken care of.


Validation

•Requirements Review Meetings•Doug and Tom•Representative from System Team•2-3 users (different classes)•A Developer•A Tester


Validation

•Requirements Review Meetings•Line by line, review the documents•Produce the list of problems and agreed upon actions to resolve problems


Validation

•Take Action•Resolve any problems found during reviews

• These should be fairly minor (additional information required, corrections to errors, etc.)


Validation

•Return the Requirements Review Meetings•Same group of people•Ensure that actions correctly resolve problems•Read through again to ensure correctness


AND THAT’S IT!


Assignment 4


Assignment 4

•Posted on Website

•Review of Research Paper in Software Requirements•Two (2) pages IEEE Conference Format•Summary of Paper•Critical Assessment


Next Class

•More System Examples


SOFT 423: Software Requirements - Queen's...

Documents

Transcript of SOFT 423: Software Requirements - Queen's...