9
« on: July 16, 2008, 11:28:42 am »
I am currently re-engineering the requirements, domain model, and use cases for a financial system that integrates functionality from two legacy systems (NY.. and NA..)
Remember, that the wireframes are a SOLUTION to the set of REQUIREMENTS you are trying to specify.
My approach is to basically create business domain model and the use case catalog (do some business level analysis to understand WHAY the solution solves.)
Then generalize out from the solution WHAT the business features of the system are, research and determine what the business rules are (HARD PART, as the rules can be implemented as constraints on the domain model, UI features, and of course CODE).
Trace the Business Features s and the Business Rules to the UCs, Document the flows, and then abstract out the high level functional requirements (what has to be accomplished), then specify the low level and UI abstracted requirements (e.g., what features the UI has to provide to support the HLFRs), rinse and repeat.
Hope that helps a little. Re-engineering requirements for a system is ALWAYS a battle to specify the requirements in enough detail that they are specific to describe what needs to be built (existing solution) but do NOT contain design choices specfied as requirements.
Example: Instead of saying something about the UI providing check boxes for selecting records, generalize it into something like...
UI will provide the capability for the user to indicate rows selected for printing....