I've been tasked to document requirements for an existing system. Since the system is already in production, they expect no interact with the users. I'm supposed to learn the system and document accordingly. Does anyone have any advice to both approach and appropriate documentation practices?
Why is this being done? What would the results be used for? My initial thought is that if the system exists already, there is no need for Requirements. Documenting how the system works, if that documentation does not exist, is useful for support purposes, but that would not be requirements. It would also be useful for enhancing the system, but you would create new requirements for the enhancements only.
Another question: Is the scope of the work based purely on system functionality, or is it in the context of business processes? It goes to David's initial question; What is this work for?
The old system is being replaced in favor of a new ERP that has a module within it that could do the same functions (raising and approving POs). The current system is a home grown system so it is very customized to how we do business, especially in Europe where our approval hierarchies are quite complex. Management wanted to document the functionality and business process for the current system. They wanted to submit that documentation to serve as base requirements for the new system to ensure that major functionality is not lost.
It sounds like you were tasked to perform reverse engineering of an existing system. Take a look at my post in this thread and see if it addresses any of your questions:
http://www.modernanalyst.com/Community/Forums/tabid/76/forumid/-1/threadid/769/scope/posts/threadpage/2/Default.aspx
- Adrian
brought to you by enabling practitioners & organizations to achieve their goals using: