The least I can do..

A lot of the conversation I have around BA deliverables focus on all the different information what *could* be useful, rather than the minimum that will pretty much always be used. I'm constantly frustrated by the amount of information duplication and useless sections in most project documentation

I think I've got a pretty good default-minimum documetnation set worked out that has been applicable in my last few roles in a variety of different software development projects. It's my defautl starting set for all software development projects, I've even used it in Agile projects. The only difference is that I update the docs in parallel with development on a wiki instead of producing the documetns beforehand.

• Project Vision Document(Business Requirements in BABOK)
• What problem we are trying to solve
• Business Context (Just how people rely on each other to get their job done, no systems, no data flow diagrams)
• What success looks like
  
• Business Requirements (User requirements in BABOK, but everyone calls them Business Requirements)
• One page picture of possible solution
• Requiremetns in the form "As a.. I want to.. So that.."
• Conceptual Data Model (Entities, and if they are related, no attributes or cardinality)
• Business Functions and Elementary Business Processes affected
  
• Functional Requirements (Functional requirements in BABOK, but also called software requriemetns, systems specification, design, etc)
  • System Behaviour (Use Cases, ACtivity Diagrams)
  • Process Models (BPMN)
  • Logical Domain Model (ER Diagram)
  • User Interfaces (Wireframes, black & white)
    
• Traceability
  
  • Vision to User Requriements
  • User Requirements to Use Cases/ER/Process/UI
  • Test Cases to Use Cases
    
• Testing
• Project Vision Testing (UAT - Did I get value from this project?)
• Functional Testing (Did it support the functionallty and use behaviour in the User Requriements?)
• System Testing (Did it exhibit the behaviour specified in the functional design?)
  
  

I'm leaving out the technical side (To the extent that it's even a different side) because I don't want to get into it, I'm also ignoring all teh changes that come about from differnet project types (Integration, Portals, CMS, COTS, CRM, ERP, etc. All of these have their own twists.)

I'm also really heavy on the testing side - I like my V-Model testing. I like the idea that you verify you did-it-righ, and you validate you did-the-right-thing as distinct activities.