ANSWER

There are many ways this question could be answered based on the type of SDLC method being used and other environmental considerations.

The steps outlined assume the marketing and promotion of the product will be handled by another group.  An iterative/Agile approach has also been assumed and combined with User Centered Design principles, though other approaches could be used.

1. Market Analysis: Market Analysis is a critical step to perform before deciding to undertake the development of any product.  Research needs to be performed to determine:
   • The size and demographic of the potential market
   • The needs of the target demographic
   • The growth of the market; is it growing and at what rate, or is it contracting
   • Competition within the market; who are the key players
   • Is there a widely excepted cost structure for the product that is being introduced
   • Based on the cost structure that is to be chosen, what kind of profitability can be expected?  This can be determined by performing a Cost-Benefit Analysis.
2. Competitor Analysis: For the competitors identified during market analysis:
   • Understand the features offered by the competitors product
   • Compare each competitors feature to those feature which are deemed to be most important to your targeted customer base, and rank each competitor based on the results
   • Speculate as to the strategic direction each competitor may be taking
   • Identify the clients of each competitor and determine which demographic segment they fall into
   • Understand the cost structure that each competitor uses for their product
   • Identify key weaknesses of competitors that may be able to be exploited, etc
3. SWOT Analysis: Combining information from the market and competitor analysis, it is often helpful to perform and document a SWOT analysis to determine internal strengths, weaknesses and external opportunities, and threats. 
4. Personas:  Develop Personas to reflect users of your product by market segment.
5. Strategic Vision and Feature Set: Determine strategic vision and feature set for product. This is the start of your Product Backlog (features to be developed).
6. Prioritize Features: Create and initial priority for the features to be developed aka requirements prioritization
7. Use Cases/User Stories: (Caveat: Use Cases and User Stories can mean very different things to different people.  There isn’t a single standard used throughout the industry) Create high-level Use Case descriptions or User Stories for the features that are intended for the first iteration of development. The objective of the use case description is to define the behavior of the features without getting in to specifics about how the screens will support it.
8. Logical Data Model: In parallel with the Use Case descriptions, create a Logical Data Model (to be further refined throughout the SDLC).  The logical data model creates a common terminology for referencing information that needs to be manipulated by the features of the product.  It also becomes a great starting point for the physical data model and database design.
9. Persona to Use Case Mapping:  Understand which Usage Scenarios will be invoked by each Persona.  This ensures that the appropriate emphasis is given to the segment of the demographic you are targeting as the highest priority.
10. Screen Mockups/Storyboards: Create initial Screen Mockups and begin Storyboarding for those features which are prioritized for the first iteration of development.  This will be a very iterative process.  There will be many ways to design the product/application to provide the feature functionality as defined by the Use Cases. Also, as the team iterates through the screen designing process it may become clear that missed features will need to be added, or a change in the feature priorities needs to occur.
11. Product Backlog: Finalize the priority of features and create the Product Backlog which is the list of all features that need to be prioritized, tracked, and eventually developed for the product.
12. Begin the first iteration of feature development
    • For-Each Iteration
      • Logical Specifications: Create logical specifications to define the precise screen behavior.  This will include screen mockups, description of on screen behavior, screen transition behavior and navigation, sounds, details about controls and the information (logical data model) that each control displays or accepts from the user, etc.  The Behavior can be described textually using PseudoCode, or when appropriate process flow diagrams can be used (UML Activity diagrams or similar) 
      • Test Cases: Create test cases reflecting the expected outcome for each usage scenario
      • Physical Design Specifications: Translate the logical design into physical design.  This may include a physical data model and database schema design, static structure modeling using techniques such as class diagrams to reflect the physical structure of the code, class interface design, and behavioral modeling using techniques such as sequence diagrams as necessary. While the design of the code and database at this level is primarily intended for the iteration in progress, consideration should be given to the overall code and database architecture to ensure appropriate scalability for large user populations and large numbers of concurrent users.
      • Write Code: Code to the specs
      • Unit Testing: Perform unit testing
      • System Integration Testing: Perform system integration testing based on the test cases created prior to coding
      • Regression Testing: Regression Test the application using test cases from prior iterations to ensure that new changes didn’t introduce unforeseen bugs.
      • Deploy Code: Deploy the code and release the product.  Depending on the situation this may be a beta release with a pre-defined set of beta users.
    • Once the iteration is complete, then the next iteration can begin.
13. Metrics and Monitoring: After a product has been deployed, specific metrics about the product can be tracked and monitored to see how the users are actually using the product.  What do they use frequently? What do they use infrequently?  This is especially relevant for SaaS products.  Though even shrink-wrap software can have built in metrics tracking that is reported back to the developing organization. This information can be used to further refine features and build the product out in areas where it is found to be lacking.
14. Strategy for Scalability: For SaaS products, database/server monitoring should occur to ensure that concurrent user activity can be supported.  Strategies for scalability should be in place well in advance of ever needing them.

Some of these steps could be combined, pared down, or avoided altogether depending on the demands of the project and complexity of the product or application. Use the minimum amount of tools, models, and specifications needed  to communicate the necessary information to the coders in a way that ensures the final product meets the expectations of the customer and is defect free. Once might refer to this as “just enough documentation” – not too much, but not too little.

However, the decision to eliminate certain steps or deliverables should be a pragmatic one, and should not be done out of laziness or a lack of understanding of the importance of a particular deliverable. 

--
Chris Adams
LinkedIn Profile