I have recently joined an organization where Business analysis has been completed (when i say business analysis, this includes the workflow with some flow charts and use cases). From here i need to produce a technical document, which means to recognize what will be the flow of the app, what are the data elements that is relevent to each page,. My client do not have any current system (like any legacy) system to guide me through.
Please help me how to reconize data elements, design screen flow etc from this document. Where do i start?
I am new to this field and any help is much appreciated.
Hi Iris:
What do you mean by the flow of the app? Do you mean the flow of data, or the sequence of activities accomplished by the application, or both?
It sounds like you need to understand how data logically flows through the system so that you can then use this understanding to properly organize your document to discuss data elements per screen. If such is the case, only data flow diagrams systematically address data flows. You don't need involved data flow diagrams; often just rough cut diagrams showing the primary information flows will go a long ways towards helping you proper structure your document. I have ample experience as a Tech Writer, and this is how I have done it.
Tony
Iris,
Let me try and clarify where you are at the moment. It sounds like you have a Business Requirements Document or at least some of the information that might be included in one including, process flows and use cases.
Are these system process flows and system use cases? Meaning do they describe the system and what is should support, or do they describe the business / business processes and you are supposed to define the system that will support the business process? Do you have a list of System Requirements..."The system shall..."?
No they are not system process flows or system use cases, they are business process flows and business use cases. Using this doc, i am supposed to define system that will support the business process. I do not have any systems requirements as i have to cfreate this.
thanks for your time.
These business flows and business use cases need to be translated into system requirements. From a business flow perspective its easy to decide which of the activities need to be automated. This is Tony Markos' famous partitioning perspective: in the old DFD world we used to partition some process elements within the automation boundary. You then use these automated activities and create system use cases and system requirements. Sometimes its best to first create the system requirements as these govern the behaviour of the system; and system use cases describe how the system behaves when you, the user, interacts with the system.
warm regards,
K
brought to you by enabling practitioners & organizations to achieve their goals using: