Project Requirements - Revision Control
Section	Currently being Edited by	Link to plain text
INTRODUCTION
1.1 Purpose / Objectives / Goals / Aim (Software to operate Robot)	Complete
1.2 Scope (System Boundary)	Complete
1.3 Glossary	Complete
1.4 Overview (Document Overview)	Complete
REQUIREMENTS DEFINITION
2.1 Product Perspective (What the user expects/is getting)	Complete
2.2.1 Scenario, Actors, Objects ("Abott's" Techniques?)	Complete
2.2.2 & 2.2.3 Use case models & use cases	Complete
2.2.4 Comprehensive list of system abilities	Complete
2.3 Product Environment (Operating System, Bluetooth , GUI)	Complete
2.4 Product Assumptions (Requirements that can be put off)	Complete
REQUIREMENTS SPECIFICATION
3.1.1System Functionality - Technical Overview	Complete
3.1.2System Functionality - Sequence Chart	Complete
3.2 Source of Inputs	Complete
3.3 Destination of Outputs	Complete
3.4 Value Ranges	Complete
3.5 Communication Protocol (3.5.1 Data Protocol & 3.5.2 Data Format)	Complete
3.6 Timing Constraints	Complete
3.7 Technical Assumptions	Complete

 

Note: "WIP" = Work in Progress 

 

Updates:

 

---

 DSharpe

 

Good, good... I'll bring the binder. For the activity log, we had two meetings: the January 31st meeting (1.5 hours), and the February 1st meeting (3.5 hours). See you in class.

 

---

 bpeake

 

Hi all. That just happened. Yup it's compiled :) feel free to check it out and edit it directly (just post an updated link.)

 

I will be printing it off hopefully around 1 o'clock tomorrow. Black and white this time I think, since we don't have a gannt chart schedule that is unreadable without color. Tomorrow I will be updating the table of contents/activity chart and hopefully I little bit of the project plan (so we can say we are listening to his advise.)

 

---

 

 Just finished reading all the documents you guys written, very impressive. Specially thx  BP & DS for made my part more smooth and fluent. You guys rocks.

~ Yuan Huang ( Vincent )

---

DSharpe

 

Yeah, I'm worried about the functionality section too. It still says WIP (work in progress), so maybe Kwabena's still up and working on it, but there's some stuff there that just has to go. We don't have a camera or light sensors.

 

 

 

---

DSharpe

 

I hope everyone's doing well and almost done. Brett, are you putting the document together, or would you like me to do it this time?

 

Either way, everyone, please be sure to mark your sections "Complete" as you complete them, and don't forget to include a link to the plaintext!

 

p.s. Give me a call if you need anything: 380-4348. Call whenever (but maybe not after 1AM).

 

---

David S

 

Vincent asked me for some help with section 3.7, as in what to include.

 

Our section 2.4 covers "Product Assumptions." I haven't seen what Brett has put in there yet, but according to page 195 of the text, "Requirements Definition 6," we list environment assumptions there: i.e. what environment conditions would cause our system to fail, and what environment conditions would cause us to change our requirements. Like I said though, I don't know what Brett is writing, I just got that from the text.

 

So what should be in section 3.7 then? Maybe what in our system itself might cause the system to fail, or what in our approach might cause us to change our requirements, from a technical point of view? We are, after all, assuming that Visual Basic is going to allow us to quickly and easily build a GUI for our system. That's a technical assumption, right? And of Visual Basic turned out to not be useful in developing a GUI quickly and easily, we might change our requirements, right?

 

My reasoning behind this for putting this in "Technical Assumptions" is that in "Product Assumptions" we might talk about environment assumptions, so it would make sense that "Technical Assumptions" would talk about internal (system) assumptions. Even if that's not the case, and Brett is writing something completely different for "Product Assumptions," the Visual Basic idea might be a good idea for a "Technical Assumption."

 

Thoughts?

Dave F  

 

- Wrote up Value Ranges, not too sure if there is any more details to throw in there.. In the slides he says value ranges apply only to inputs/outputs so I assume that means the range of values we may be working with. I laid out the ranges for user input (aka max size of movement plans for movement plan array, max number of movement plans) and also for bluetooth output (aka max message length, byte command options etc). Also put a little section at the top for the actual range of bluetooth, since that in a way does determine the ACTUAL range of inputs/outputs haha

 

- Also wrote up Glossary, put in stuff from my docs and am starting to look over others for particular terms I think can be clarified. If you see any you could add just edit the page.

 

-  I also set my other areas to 'Open', I just edit the page I created in the wiki so if you guys can think of anything to add to them just edit the page. If you wanna let me know your thoughts I can run with that too just post here.

 

---

---

Kwabena

 

• I am working on the Document overview and the comprehensive list of system abilities.
• I am also working on the Functionality, thus the Technical overview. Somebody can also write on this so that we can

  extract important points from the two, cos I don't think I can produce the final work on this.

• I am not sure what this means: "Value of Ranges" and the "source of wants". I hope to get some clarifications on these.

 

---

 - I changed a few things with the document layout (added an assumptions to the requirements definition part, removed the system architecture bullet, Moved use cases up into the requirements definition) feel free to start attacking this thing (bpeake)

 - Add text to the “Actors and Scenario” and "Product Perspective" section and inserted a few terms into the glossary (bpeake)

 - Added David's introduction sections to the formated version of the paper (I added one additional line to the end of the scope). I also added an early draft of a Use Case Model and defined 2 of the 5 use cases. It is an early attempt so it is still up in the air.  Edits and suggestions are welcome. Your parts looks good David, let me know when you have completed the environment section and I will add it to the document (bpeake)

 

---

 

Nice work Brett, as usual.

 

Here's the document we were working on: feb-01-meeting.doc

~David Sharpe

 

 

---

 

Don't worry, nothing's happening on this yet. Just thought I would post a link to a "cleaned up" version of the project requirements. I only changed the formatting so there is no new information, but feel free to grab a copy if you find it easier to read.

 

- Requirements (Formatted)

 

-- Brett

 

---

 

I'm typing up my notes, real quick, just for some more documentation.

 

Models:

• structural (ER diagrams, class diagrams)
• dynamic (shows behavior and interactions between entities)

 

We identify classes and cases through "use case" diagrams. We develop "use case" diagrams after scenarios, and we develop scenarios after finding actors.

 

Actors are external entities acting upon the system. They are abstractions of roles.

 

Some questions to think about when developing scenarios:

• what are the primary system tasks?
• what data will the actor interact with?
• what external changes does the system need to know about?
• what events does the actor need to know about?

 

To develop "use case" diagrams:

1. Name the use case
2. Find the actors
3. Concentrate on the event flow

 

From "use case" diagrams you can develop class diagrams. To do this, you can use both the "use case diagrams" and the original scenarios. From the scenarios, nouns can be good candidates for classes, and verbs for operations.

 

Summary:

1. Formulate scenarios
2. Extract use cases
3. Analyze flow of events
4. Generate class diagrams

 

Robert suggests we identify different types of objects in our meetings: entities, control objects, and interface/boundary objects.

 

Dynamic Modeling involves sequence charts and state charts. Sequence charts model interactions between objects. State charts model the dynamic behavior of a single object. Both types of charts are typically developed from "use cases" and scenarios.

 

Relevant resources:

1. Relevant parts of Chapter 4: Capturing the Requirements.
2. Robert's slides that talk about requirements (lots of good ideas).
3. The project requirements (Brett's formatting).

 

~David Sharpe