Week 30

Analysis

User Stories -

The users will have direct input into the user stories that will foundation the Use Cases for this analysis. According to research user stories should be ideally written by the users themselves. In this case the MIS being constructed is for the purpose of demonstrating the functionality of the middleware and not its (The MIS) functionality. As a result the detail that the users may want to include in user stories would exceed the needs of this system. The user stories should cover enough functionality to modle some of the interactions the user would engage in daily processes. The MIS will not however model these processes in detail. If the users were left to propagate the stories on their own they would most likely exceed the detail necessary and loose sight of the focus of the *Mock MIS*.

The user stories will be initially drafted by me and then sent to the departments for approval. This way the users dont need to spend too much time bogged down with the details of what the project entails and how i need to go about achieving it. When I meet with the department representatives for the second time to show them the user stores that I created, I will give a brief of what type of the system the stories represent.

The user stories will be tied to testing. No its not that strange. For each User story there will be on the same document a corresponding test case. The user stories will be used as a starting place for the user stories that will lead directly into the design but they will not be able to give an appropriation of design time. The user stories will only cover the basics of the Mock MIS operation and therefore cannot be an estimation of the entire development process.

The four simple rules outlined by David Churchville on the Agile Project Planning blog is a clear guide for writing user stories and I employed these guidelines as thoroughly as possible.

http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html

Mountain Goat Software outlines the advantages of user stories. It also individualizes user stories from use cases and requirement definitions.

There is a very good metaphor identifying user stories with goals instead of requirements. This really brought home to me the meaning of what the user story should tell and maybe how to tell it. They described requirements and made mention of the IEEE style for writing them. They contrasted on how formal requirements can be unclear when trying to outline the general or rather actual wants of the user in contrast to a goal. And how a user story is not a goal but rather a description of a goal in the form of a story.



The following resources were also used in forming the methods used for collecting and writing the user stories.

http://www.agile-software-development.com/2008/01/example-of-user-story.html

http://dannorth.net/whats-in-a-story

http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/

http://www.agilemodeling.com/artifacts/userStory.htm

.

Work Flow Diagram -