Specifications for RNDS Software Requirements and Use Cases in Aviation Systems

1. RNDS: Use cases CS 236700: Software Design Winter 2004-2005/T3

2. Homework bonus program • Report a bug • Report a programming challenge

3. Problem description: RNDS (1/3) • RNDS: Replicated Navigation Data Store • A formation of Aircrafts + A ground station • A single flight plan (FP) made up of several way-points (WP) • A single steering point (SWP) • Requirements: • Allow flight-plan editing • Allow setting of the current SWP • Display Info • Distance to SWP • Heading to SWP • Heading correction to SWP

4. Problem description : RNDS (2/3) • Interoperability with existing systems • A GPS device • Provides: Position, time, speed, current heading • A communication layer (CL) • Supports various communication protocols • Broadcasting, Send-reply, … • Preconfigured with relevant “addresses”: • Formation’s aircrafts • Ground station

5. Problem description : RNDS (3/3) • More requirements • Human interaction thru GUI • Data (WPs, FP, SWP) should be consistent • Reliability (99% up time ?) • Software platform: Java/Embedded Windows NT • Hardware configuration is uniform • Same setup in the ground station and the aircrafts • Boundaries • A single RNDS system is the software components running on a single computer (either at the aircraft or at the ground station) • Other RNDS instances (reachable thru CL) are considered to be identical peers • => In the typical settings (four aircrafts + a ground station) there are five RNDS systems working concurrently.

6. The mission Write the use-case specifications for the SRS document • SRS = Software Requirements Specification • Describes the functionality the system will provide • Written from the client’s perspective • Defines the developer’s obligation to the client • Must be approved by the client • Who is the client ? • Many times someone from within the organization

7. SRS Document • SRS Template • Glossary • Primary actor • Principal actor that interacts with the system to fulfill a goal • Secondary actor • A non primary actor • Active actor • Initiates interaction with the system • Passive actor • A non-active actor • Function points

8. Actors • Who can interact with our system? • Pilots • Ground station operator • Is he really different than a pilot? • GPS • Communication Layer • Administrator? • Mission planner? • Flight commander? • Operating System? • File system?

9. “User Level Activities” • The key question: What can a user “do” with the RNDS? • Enter a new WP • Remove a WP • Change a WP • Add a WP to the FP • Remove a WP from the FP • Change the current SWP • The standard set of operations on a data item: • Create • Change • Delete • Lookup

10. Other activities • What about non-human actors? • The system communicates with its peers thru the CL • The system reads current position from the GPS

11. The list of use-cases (1/2) • Add a new WP • Delete a WP • Edit a WP • Add a WP to the FP • Remove a WP from the FP • Change SWP • Show Info • Read GPS data • Receive updates • Send updates

12. The list of use-cases (2/2) • Q: Can we have a “calculate-info” use case? • The answer depends on • The client • The description of the problem • The SRS author Anyway, it seems like an Implementation detail • The Use cases: • Add a new WP • Delete a WP • Edit a WP • Add a WP to the FP • Remove a WP from the FP • Change SWP • Show Info • Read GPS data • Receive updates • Send updates • The bottom line: • The client must understand the SRS document • The client must approve the SRS document

13. Use case diagram (1/2)

14. Use case diagram (2/2) • NavInfoChange can generalize 6 of the use cases

15. The list of use-cases - updated • Change Navigation Info • Add a new WP • Delete a WP • Edit a WP • Add a WP to the FP • Remove a WP from the FP • Change SWP • Show Info • Read GPS data • Receive updates • Send updates

16. “User Level Activities” – again (1/3) • The key question: what can a user “do” with the GUI ? • A picture worth 1000 words • He can start an action: New WP, Delete WP, Change SWP, … • These actions are already covered (see previous slide) • He can read the directions • This is the “ShowInfo” use case • He can scroll the WP list • He can scroll the FP list • He can show/hide various parts of the display Run RndsGui

17. “User Level Activities” – again (2/3) • …So, the user can also scroll the display • Q: Is it possible for the ShowInfo use-case to handle scrolling? • A: No • NavInfoChange uses ShowInfo for refreshing the display • “Refresh” and “scroll” are distinct • The same goes for showing/hiding parts of the display • The solution: • Rename ShowInfo to RefreshInfo • Add a ChangeVisibleInfo use-case • Will handle scrolling, showing/hiding, … • We can also define a generalization hierarchy: • ChangeVisibleInfo – The general use-case • Scroll, Show, Hide – More specific use-cases • Reflecting GUI interaction in the SRS document…

18. “User Level Activities” – again (3/3) • What about the order of the FP ? • We should add an up/down facility • => Adding a new specialization of NavInfoChange Run RndsGui

19. Final list of use-cases • Change Navigation Info • Add a new WP • Delete a WP • Edit a WP • Add a WP to the FP • Remove a WP from the FP • Change SWP • Change FP order • Refresh Info • Change visible info • Read GPS data • Receive updates • Send updates

20. Final use-case diagram

21. UC Description • Name: “EditWP” • Actors: User, CL • Goal: Change the position an existing WP • Reference to requirements: … • Pre-conditions • Number of WPs >= 1 • System displays the list of WPs • Description • User selects a WP • System displays the WP’s details • User enters new details and submits • The system updates all peers by invoking the “SendUpdates” use-case • The display is refreshed by invoking the “RefreshInfo” use-case • Post-conditions • The position of the selected WP has changed in all RNDS systems. • Variations • 4,5 - The WP is removed by another RNDS system => Operation stops • 4,5 - The WP position is changed by another RNDS system => Operation stops • Excpetions • 6 -Not all peers could be updated => A partial success message is displayed

22. “Holes” (1/2) • Is it possible that the guy who described the problem was not doing a good job? • What did he forget to mention? • What definitions are missing? • What is WYSIWYG ? • What You See Is What You Get • What is IKIWISI ? • I’ll Know It When I See It

23. “Holes” (2/2) • IKIWISI is evil • Changes at an early stage are usually made by a combination of the “cut”, “copy”, and “paste” keys • Changes towards the end of the development cycle call for a major redesign-rewrite-retest process • Thus, the later the change the more it costs • Nonetheless, many times requirements do change in a very late stage • Sometimes, IKIWISI yields better result than careful pre-planning • Especially in the holy-land !! • The bottom line • Not everything can be predicted • An impeccable requirement document is a fairy-tale • Accept the change

24. Dealing with late changes • Some techniques • Understanding the client’s needs • Avoiding hard-coded values • Avoiding hard-coded decisions/assumptions • Deja vu reduction • Increased locality, modularity • Representing “things” as classes • Adding levels of abstractions • On the other hand, beware of over-engineering. • Anyway, these techniques are out of the scope of this lecture