Exactly... You really should look closer at use case and business/analysis domain modeling and how you can leverage that with testing!
Use Cases should be the area where the requirements and scenarios exist. Thus you are able to exploit the scenarios with test as the EA rep indicated.
My approach is to:
- Identify the business objects (things the business sees as "things" that are within the scope of the project), document glossary definitions,
- Concurrently identify the use cases (conceptual level) that will implement the features of the system, that the customer needs to be able to fulfill their business use cases (these I model very lightly as I am using them as a stand-in for the lack of a BPM) and get agreement.
- Identify the "basic" business level scenarios that the system will participate in - these can be used as the starting point of a system walk-through (thus following a specific end-to-end pathway to the outcome)
Note: From these business scenarios, you can begin to understand the context of what the system use cases need to accomplish (requirements) and you can start adding detail to each of the system use cases encountered along the business scenario walkthrough. During this you should be able to: identify scenarios for the SysUC (basic 1st) and then describe the flow of the Actor/System interaction within the scope of the SysUC - I use activity diagrams for this... The activities within those diagrams serve as anchor points for requirements specific to an activity, further linked to UI fragments, domain objects, etc. where additional requirements are defined.
- Update the SysUCs by adding the additional information described in the note above and the business domain objects that are involved.
Note: IT is important to understand that the "Activity" diagrams are NOT design constraints, but an analysis flow of an interaction with the system. It is so easy to step over the line and describe the solution as the requirements, which it is NOT. The solution is just that, one solution that is intended to meet the requirements.)
- Review the activities (steps in the flow) and their requirements with test and define "how" these will be validated at this high level (e.g., demonstration, inspection) and add some high level details. In EA I capture these as a type of user requirement called "Acceptance Criteria" and these must be reviewed with the customer. Once this is done, you can use EA's "testing" features that are available for ANY EA element, and document your initial UA tests there,
Wash and repeat this process, and you will end up with a set of SysUCs that accurately describe the functional (and some of the non-functional requirements), have domain element requirements, link to UI requirements (which can then be used as a source of input for the UI wireframes), and have a set of robust scenarios and scripts (which can be derived from the activity diagrams by following a specific scenario's path through that use case, using a set of data corresponding to the linked domain objects...)
My point being that you can develop a process that will provide everyone with what they want:
- Analyst - Source of Requirements, and Scenarios that describe a set of interactions with the system
- Test Teams - Source of Scenarios to be used to develop the test cases for UA, End-to-End, System/Integration, etc. and a set of data that was used to validate the UA "tests" during analysis and can be used to further explore fragments of scenarios using variations on that data (explore alternate paths, exception paths)
- Developers - Functional Requirements for specific system capability and the ability to understand them in the business context, and see what the customers expected outcomes will be.
- - Managers - A model to be mined for use with scenario driven releases, iterative development, or classic water fall process. You can extract metrics to show progress, risk, difficulty, etc.
It is possible to have one location be the source of "truth" which starts out vague and evolves into an accurate representation of the system under development's capabilities and requirements. By extending the traceability to realizations, then accurate/repeatable impact analysis is possible for change control, defect analysis, etc.
The model then will be something of value to maintain, exploit, and explore what-if scenarios.
MAN did I get on a soapbox or what?!!
Just a great tool that needs to be used with a thought out process.
David - BTW doing/expanding this on real-life projects!
[/list]
