Coffee Connections
Wherever your travels take you, from sunny Long Beach, California, to the cobblestone streets of Hamburg, Germany, chances are that there is a coffee shop nearby. Whether it is a Starbucks (located on just about every corner) or a local coffee shop tucked neatly in between all the antique stores on Main Street, they all have one thing in common, coffee, right? Well yes, they do have coffee in common, but more importantly, they are places for people with shared interests to gather, relax, and enjoy their coffee while taking in the environment around them. Coffee shops offer a wide variety of services in addition to coffee, from WiFi to poetry readings to local bands; they keep people coming back by offering them more than just a cup o' Joe.
But how do you find the coffee shops that have the type of atmosphere you are looking for? In addition, how do you locate them in your surrounding area? That's where Coffee Connections comes in; it is its desire to fill this void by creating a website where coffee lovers and coffee shop regulars can connect and search for coffee shops in their local area that cater to their specific needs. Coffee Connections has a vision to create a website that will bring this together and help promote coffee shops around the world. Users will be able to search for coffee shops by zip code,
types of entertainment, amenities, or name. It will also allow its customers to purchase goods online and communicate with others through chat rooms and forums.
Determining Client Needs
In any project, it is important to determine the needs of the client before work begins on the project. When designing a business-driven solution for your client your options range from an extensive Request for Proposal (RFP) and case modeling, to user stories and Microsoft Solutions Framework (MSF). To determine the needs and document the requirements of Coffee Connections we will use user stories.
We selected User Stories as our requirements collection method for two reasons. First, the DotNetNuke core team uses this method when building enhancements and upgrading the DotNetNuke framework. Thus using user stories will help to give you a better understanding of how the core team works, the processes team members follow, and how they accomplish these tasks in a short amount of time. Second, it is a very clean and concise way to determine the needs of your client. We will be able to determine the needs of Coffee Connections without the need for pages and pages of requirement documents.
User stories were originally introduced as part of Extreme Programming. Extreme Programming is a type of software development based on simplicity, communication, and customer feedback. It is primarily used within small teams when it is important to develop software quickly while the environment and requirements of the program rapidly change. This fits the DotNetNuke project and the DotNetNuke core team well.
User stories provide a framework for the completion of a project by giving a well-designed description of a system and its major processes.
The individual stories, written by customers, are features they wish the program to possess. Since the user stories are written by the customer, they are written in the customer's terminology and without much technical jargon. The user stories are usually written on index cards and are approximately three sentences long. The limited space for detail forces the writer to be concise and get to the heart of the requirement. When it is time to implement the user story, the developer will sit down with the customer-in what is referred to as an iteration meeting-to go over particular details of each user story. Thus, an overview of a project is quickly conceptualized without the developer or customer being bogged down in minor details.
User stories also help in the creation of acceptance tests. Acceptance tests are specified tests performed by the user of a system to determine if the system is functioning correctly according to specifications the user presented at the beginning of the development process. This assures that the product performs as expected.
There are many different methods of defining requirements when building an application, so why use user stories? User stories fit well into Rapid Application Development (RAD) programming. Software and the computer industry in general change on a daily basis. The environment is fast moving and in order to compete in the marketplace it is important to have quick turn around for your product. User stories help to accomplish this in the following ways:
- Stressing the importance of communication: One of the central ideas behind user stories is the ability to have the users write down what exactly is expected from the product. This helps to promote communication by keeping the client involved in the design process.
- Being easily understandable: Since user stories are written by the customer and not by the developer, the developer will not have the problem of "talking over the head" of the customer. User stories help customers know exactly what they are getting because they personally write down what they want in terms that they understand.
- Allowing for deferred details: User stories help the customer as well as the developer understand the complete scope of a project without being bogged down by the details.
- Focusing on project goals: The success of your project depends less on creative coding strategies and more on whether you were able to meet the customer's goals. It is not what you think it should do but what the customer thinks it should do.
Below you will find the user stories for Coffee Connections. From these stories, we will use DotNetNuke to build the customer's website. The title of the card is followed by a short description of what is needed. Throughout the book, we will refer back to these as we continue to accomplish the project goals for Coffee Connections.
When referring back to the user stories later in the book, we will use a card to compare and determine if we have met the customer's needs.
