I have been building software for 25+ years. During this time, I have tried many different types of methods to clearly capture and describe software requirement. My experience has taught me that using an Agile type methodology for requirements gathering works the best. Using this method it will take you from initial ideas or user stories down to the details of tasks to be implemented. This blog describes the steps I follow to do this.
buy doxycycline online uk User Stories
User stories are simple, concise descriptions of a software requirement that describes the “Who”, “What”, and “Why”. It is made up of one or more sentences, in the day to day language of a user of the software, that captures what a user does or needs to do. There are many ways to write them, but generally they follow a template like:
As a <“Who”>, I (we) want to < perform some action – “What” > so that I can < achieve some end – “Why”>
As a “sales representative for ABC Corp”, I want to “track all of my lead email correspondences” so that I can “view when I last emailed them and what we discussed”.
This is just an example and there are many different ways of capturing the “Who”, “What”, and “Why” of a requirement. User stores can come from your company and/or engineers as well. It does not have to be just end users. For example, here is a user story from the engineering team:
As an “engineer” I want to “add unit tests to our source code projects” so that we can “improve quality in our software”.
http://christenallocco.com/goodtype-tuesday-need-a-hand-lettering/ Product or Feature Backlog
I started using user stories to describe requirements before there was software that helped organize them. My team and I would write the user stories on post it notes and stick them on whiteboards in conference rooms. We would brainstorm for user stories as well as receive them from our users and employees. Once we had all of the user stories we could think of we started organizing them into areas. This formed the basis of the changes we needed to make to our software called the product or feature backlog.
Currently, we follow the same process but we use software to manage this. We create user stories into a feature backlog in Team Foundation Server from Microsoft. Then we organize them into areas. These areas are just groupings of the user stories that help us define what will be going into the sprint backlogs.
NOTE: There are many different software programs out there that can be used to manage your software requirements. However, I recommend using one that is tightly integrated with your source code control.
This backlog also helps do our long term planning. From here we can do high level estimates for deliverables that make up our product road map. See my other blogs about project management that describes road maps.
http://liveforyounow.com/blog/the-benefits-of-vitamin-b/?replytǚ,_474,_respond,_521_) Sprint Backlogs
Sprints are a set of backlog items and tasks that are scheduled to be released. Please see my blog, “How to build software with a small outsourced development team”, for details on this.
Once the areas are organized then I move start creating sprint backlogs items. Sprint backlog items are linked (associated) to the user stories in the feature backlog that it defines. These backlog items contain much more details about the user story. I try to keep this limited to the following:
- Architecture – If this is a new product define the architecture to use. This includes Hardware and software. You may decide to use the LAMP stack(Linux, the Apache HTTP Server, the MySQL relational database management system, and the PHP programming language), Microsoft Azure, etc.
- Styling – If this is a new product or a change in the styling of an existing product, it is important to define what the software will look and feel like. Give examples and enough details via screen shots.
- Views – This describes how the feature backlog item will work within the software. But does not get into the details of how to implement it. Remember to describe the views based on access control or the user roles. For example:
Title: Sales Correspondence History View
Description: Create a system that will allow sale representatives to bc(blind copy) an email address as specified in the settings (eq. email@example.com). The system will receive these emails and store the email based on the sender. It will record the date received the persons sent to and the message sent. It will correlate these persons sent to to a contact in the our system via the email addresses. Create a page under the Sales Tab called “Sales Correspondence”. That shows a listing of all correspondences recorded for the logged in user. When they click on an a correspondence then show the details of this correspondence….
Once you have this level of detail you can start estimating the amount of effort that you should record with the sprint backlog item. With the level of effort estimations now you can start planning on what sprint to put the backlog items into. At this point, you can start to assign these backlog items to teams or team leaders.
The last level I use are tasks. Each sprint backlog item needs more details. It needs to have specific tasks defined so that it can be assigned to an engineer. I try to define these tasks to be 1-3 days of effort. Sometimes it has to go longer but the more granularity you have the easier it is to manage your time and estimates. It also forces the Product Owners (see “How to build software with a small outsourced development team”) to think through the feature so you do not waste time in engineering doing something incorrectly or that you don’t need. An example of a task is:
Title: Correspondence Emails settings page
Description: Add to our settings page an input box that allows a comma separated list of emails to process. This will be used by the SMTP email reader service to process these incoming emails. Store this in the settings table in the following column: settings.CorrespondenceEmails. The label will be Correspondence Emails …
This blog describes how to create software requirements down to the details of the tasks to be performed. The key is starting with user stories. By following these guidelines it will help you get a product that your users need and will use.
Build a team of outsourced software developers to help build the software you and your customers need.