Usage Cases

 Today was our day to meet with our instructor. We got an update on what we should be doing and how we should conduct business when choosing our work. This will avoid things being done that may have already been taken care of and will avoid work done that might not be used and would be scrapped instead. We will use Trello and we are assigned specific tasks. I was assigned to complete the SDD and add usage cases. I looked online and found a few examples and I didn't realize that it was more work than i expected. On the upside, the definitions portion of the SDD provide some great examples of what i can use for our usage cases. Tomorrow evening is when I can write each one of these out and have them added to the SDD. I have included links to the sites i would reference inside the Trello card. They are also posted below, just for good measure.

What is a Use Case? (techtarget.com)

Use Cases | Usability.gov

Git hub link will be created soon, and we can start our next week with coding for our web application.


As I was writing for the usage cases section of our SDD, I noticed that a lot of the purpose for the design doc lies with in different ways of explaining the functionality of this application. SDD is designed to be a catch all for ideas that may go unnoticed when detailing multiple process for one combined process. the expected outcome for each part of the application is important because the time to be divided out evenly and spent on production instead of time being spent of fixing problems.

I started my ideas of usage cases with the definitions section of the SDD and realize that i am using terminology in the usage cases section that can be further explained in the definitions section itself. It would help save a lot of time trying to explain each and every part of each detail in the usage cases and would allow the reader to have a clearer understanding of what is being read.


In reference to Usage cases and folder hierarchy 

 particularly chapters 7 & 8

AND

this book called writing effective use cases page 176

are some of the reading materials i used to come up with my cases. I learned that the features of the application lend themselves as a much better indicator of what usage cases should be. I also read about software design in general. Most software ideas need to be fleshed out to prevent confusion from each step in an Agile development environment. This is fascinating. 

Comments

Popular posts from this blog

Authentication token and refraining from using Cron

Long week of Detailing