Embedded Files
Consolidating all the information gathered from the process journey & feasibility study workshops shall in itself provide important tangible pieces of material, essentially building product IP whereby the Business Requirements Document may start being formulated.
The objective of this document is to highlight the current situation and its business challenges to then move into and describe the change, made up of a vision and a direction which shall increse business benefit.
Such a document is never finished. It is actually a living document, defining the journey of the product as well as the transformation of the features, functionality, use cases, and so on. Such content may be in one or more doucments, depends on the preferred structure of the team.
In technical terms, such documentation shall eventually feature into a product roadmap tool such as JIRA whereby all modules, features and functionality would be broken down into EPICS, User Stories & Tasks. Therefore, the logical structure of this document should from inception be structured, providing clarity to business stakeholders, investors (banks/business angels), as well as the engineering team.
Structure the document as clear as possible, from day 0! Clarity amongst the product team and key stakeholders is imperative.
My personal preference on the document structure is typically as follows:
Version Control table - Documenting the version of the document, date of modification as well as the high-level changes implemented in this version. I typically start with version 0.1 and define it as the 'Initial Draft'.
Executive Summary - Introduce to your readers the industry, the high-level challenge as well as the overall vision.
Business Challenge - Delve into the business challenges in greater detail. The reader must clearly be able to understand the pain points, the reason why the company is proposing this change and investment. We are not meant to document the granular detail, yet it would be beneficial to aid the readers into understanding the overall picture.
Business Opportunity - Implementing change shall surely bring about some form of opportunities. Mention and describe these opportunities to the readers and they'll be able to match the challenges to the opportunities and further understand the purpose of the change.
Project Stakeholders - List all the relevant stakeholders who had taken part throughout the workshops, entering their:
Full Name (John Doe)
Role (CEO)
Project Role (Project Sponsor)
Email Address
Contact Number
Current Process - Define the AS IS model in detail, explaining every User Role you had engaged with. What does the role fuflil? How & why is it performed? Provide any factual data such as the time per resource required to perform the task. Are there any other business units required to aid in the process? Was the time measured? Are there any external stakeholders, bottle necks, gaps, etc? Document the full flow in a role & process based perspective.
Conceptual Model - Define 'The Risk vs Reward', the TO BE model. From this point on, explain all the information/discussions which were held during the workshops on the way forward. Explain every user role in user stories and their input in the process, as well as their end-to-end business process flow. Initiate this in the following example manner:
As A: Customer;
I Want To: Create my user profile;
So that: I can hold my personal information on the system;
Towards the end of this section, every user role would have been explained therefore depciting every major functionality required. Think about:System Administrators - User management, Permissions, configurations, and all other system administration non-functional requirements
Senior Users - Team/Project Leaders
General Users - The rest of the operational team
Any other user who somehow falls part of the solution? Challenge the company in user permissions and groups. Can these be hard coded? Must they be dynamically built? Is this an internal system? Or is this a product being sold to comapnies who have different levels of hierarchy or simply have different business processes?
Business Requirements - Grabbing every user story defined in the previous section, creating the necessary wireframes and functionality per wireframe capturing the end-to-end process per user role. This task shall be the most tedious task since you shall be turning the conceptual model into a dry-run, a prototype of the solution, providing something more tangible and visual to the readers.
Achieving the above shall take its time and shall require a good amount of further discussions, clarity and communication with all stakeholders. The great element of tangible wire framing enables key stakeholders to visualise and think of other opportunities, or even highlight certain risks at a very early stage. Visualising is key!
Google Sites
Report abuse