Software is a challenging business and is rife with opportunities to go wrong. Over the years a number of methodologies have evolved to help make sure that things go right. In an effort to contribute to this I’ve created a list of user stories that I think should be included and sometimes are just assumed. Note this is a work in progress, so I’m looking for your feedback. I’m curious what you would add or change in my list.
· As a DBA I am working with a Normalized data model that reflects an agreed upon logical model for the system
· As a DBA I am using consistent names for my fields which match the naming standards of my organization
· As a DBA my model supports simple CRUD operations against all the entities
· As an Application Architect the UI has been validated against the Business requirements and a complete set of user story’s have been created
· As an Application Architect the database model has been validated against the UI
· As an Application Architect we have a logical business model that describes all the known and/or expected usage of the system during the software’s expected lifecycle
· As an Application Architect we have a Deployment diagram that describes how the application components will be deployed
· As an Application Architect we have a navigation diagram that describes the typical application flow
· As an Application Architect we have identified points of interaction which describes how the UI interacts with the services and the data storage
· As an Application Architect we have identified external systems which may now or in the future use the data of this application and have adapted the logical model to include these interactions
· As an Application Architect we have identified existing systems and tools that can be extended and/or reused to help this application achieve it’s business goals
· As a Project Manager all team members understand the goals of each release and iteration as they are planned
· As a Project Manager all team members understand their role and the roles of others
· As a Project Manager we have support of the business to do the right thing even if it is not the expedient thing
· As a Test/QA Analyst we have created a simulation environment for testing the system which does not use sensitive data and accurately reflects the scenarios of all the data that will be supported by the system
· As a Test/QA Analyst we have identified the matrix of supported clients used to access the system including the likely browsers, mobile devices and other interfaces to work with the application
· As a Test/QA Analyst we have created exit criteria for each user story that match the requirements of the business story that was used to create them
· As a Test/QA Analyst we have access to a Test environment that is isolated from production and staging environments
· As a Test/QA Analyst there we have a way to reset the environment so we can rerun tests when a new version of the software becomes available
· As a Test/QA Analyst I am able to automate portions of the test process
Thoughts?
-mike