Whichever methodology you advocate for software delivery the basic building blocks and outputs of a software delivery lifecycle are the same.
Epics/Features
These are the high-level requirements that describe the scope of delivery for the application. Please see earlier BLOG for details regarding defining and breaking down epics into user stories.
User Stories/Requirements
These are the units of change for an agile delivery methodology following an iterative process. Each user story has a specified size and business benefit that can be used to determine when it should be played. This is equivalent to a SMART requirement. In a waterfall methodology these are your higher-level requirements that you will subsequently decompose.
Logical Components
These are the various logical components that between them describe the detailed behaviour of the application that will meet the requirement specified in the user story or higher level requirements. Examples include documents, forms, actions, entities and their attributes and business rules.
Acceptance Criteria
The specific detailed attributes of each logical component are the acceptance criteria for that component. These are amended for existing components or specified for new components to meet the requirements specified in the impact assessment for that component.
Configuration Management Items
These are the files in the software configuration management repository that are required to deliver the software. A mapping exercise is performed by the solution analyst/developers to identify each of the physical system components in the application that must be amended to deliver the acceptance criteria specified for the logical components. These are then amended, compiled into executables and unit tested by the developers to prove that the changes have been made correctly. These are the executables that are delivered to the testers in their environments as a version of the application (also known as a build) that they will test to ensure that the requirements have been delivered prior to a delivery to live.
Test Cases
Test cases describe expected behaviour of the application from a user’s perspective. These are typically defined by specifying pre-conditions and then documenting an action taken by a third party and the expected system behaviour in response. These are then executed against a build to determine if the behaviour is as expected. Where behaviour differs from the test case then a defect is raised to amend the system functionality. Test cases are similar to instances of use cases in a similar relationship to that between an object and a class.