BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting March 3, Gathering Requirements On an Agile Project…

Gathering Requirements the Traditional Way 1 – Hold a series of SME sessions until you have a novel of specifications 2 – Create a document that lists all requirements 3 – Review document with customer to make sure nothing is missing 4 – Update Document (note that all requirements are equal in this format) 5 – Everyone signs off, result is a massive document whose details must be synthesized

Gathering Requirements the Traditional Way Too many details without enough organization or context. No easy way to discern between critical. requirements vs nice-to-have requirements. Not clear when you are done. Not easy to identify overlapping or contradictory requirements. Not easy to tell a SME that their desires have veered beyond the solution’s intentions. No 2 readers will ever synthesize all the details in the same manner. Memorizing or being totally familiar with everything in an FRS or SRS is not reasonable. Noone really reads it all. Why this isn’t EIM’s way…

Gathering Requirements the Agile Way Goal 1: Listen & Discover - the customer needs, pain points, desires. Where is the value? make sure their proposed “solution” offsets their actual pain points Goal 2: Paint a Picture of the Solution – Key Elements and Success Factors First (SDD) Goal 3: Get feedback on Proposed Solution Goal 4: Revise Picture of the Solution (Updated SDD – first few Mocks) Goal 5: Get detailed requirements to support each Key Requirement (tweak SDD – finalize Mocks – Build Product Backlog) Whether you begin building the solution before a complete set of requirements is gathered (as you would do in a textbook agile project) or you wait until all presumed requirements are defined, it still makes better sense to define key elements first, and let those then drive the more detailed requirements.

1 = Discover: First things First Goal 1: Listen & Discover - the customer needs, pain points, desires. Where is the value? make sure their proposed “solution” offsets their actual pain points. Begin clarifying must-haves vs nice-to-haves, and visualizing users interacting with the solution to understand what that needs to look like. Get critical elements defined before spending any time on nice-to-haves. Cornerstone Requirements: those elements that provide value in Key areas to Key users. If we could build these features, the customers main pain points would be answered… Important Requirements: those elements that provide value for Key or secondary users, less common scenarios, or solve major annoyances. These may be marked differentiators… Average Requirements: those elements that provide value, but aren’t necessary to enable key needs. They may solve minor annoyances or less important business problems. Nice-to-Have Requirements: things that the system can live without in most user’s eyes, but smooth over minor rough spots in the solution. Solution Parameters (Time/Resources) Requirements

2 & 3 = Paint a Picture & Get Feedback Goals 2 & 3: Paint a Picture of the Solution - Key Elements and Success Factors (SDD). Enable everyone involved to visualize the solution, so they understand what the solution will and won’t do. Still focus on the Critical Requirements here, not the nice-to-haves. Iterate with the customer until everyone agrees… With your first short-list of critical requirements (those that cover the Key areas) generate your SDD, and iterate this. As you do, you will: 1 – Reach Consensus on what needs to be built at a high-level, which gives you all of your Epics or Categories. 2 – Begin collecting additional detailed requirements as you decompose the higher-level Key areas. The SDD represents the Key Requirements or Key Features that define the solution. There won’t be many details in the SDD because that isn’t its purpose. The SDD was originally created as a tool to direct requirements gathering sessions and keep those sessions from veering out of scope. As the tool that drives requirements sessions (not the FRS or SRS), you continue to stay on course supporting the key vision, taking each key area and decomposing, which means gathering the right requirements that are already in a value-context. Once all the more critical elements of the solution are defined, it’s OK to begin decomposing and getting the details and nice-to-haves…

4 = Paint a Picture part 2 Goal 4: Revise Picture of the Solution (Updated SDD – first few Mocks). Once the SDD is in a state of being relatively complete and accepted, it is the right time to begin GUI mocks. As you walk through the SDD, necessary GUIs begin to appear. As you walk through the SDD, place a sticky in each area that a UI is needed to handle the functionality. 1 – Use Balsamiq to capture the basic elements that should go on each GUI. Now Requirements sessions can be driven by the SDD and GUI flows… 2 – Utilize our Graphics/UI department to transform the rough-sketch GUIs into market-ready GUIs. Now we have SDD and GUI Mock driven requirements gathering sessions. We are still in the process of decomposing, or using a top-down approach to requirements gathering – and noone has been injured from being asked to read and synthesize 1000 lines of “the system shall…”

5 = Gather Remaining Detailed Requirements (FRS) Goal 5: Get detailed requirements to support each Key Requirement, and all the nice-to-haves. Make sure at this point, as requirements are requested that clearly fall out of scope, that they are marked as out-of-scope or “for future release” A Requirements Document needs to be completed and signed off. The best case scenario is that the requirements document is not presented contractually as a promissory note, but that is in the hands of the PM or higher. Be aware that often, the FRS is considered a hard-and-fast commitment, in which case there needs to be a lot of thought about what is actually stated. For this reason, I like to organize the FRS into core functionality and expanded functionality, or something like this to set the stage for prioritization. I also have verbiage in the introduction that describes the FRS as a list of desired functionality (not promised functionality). Remember, regardless of the verbiage in or organization of the FRS, the contract itself determines the nature of the FRS (promissory note vs backlog of desired features that are open to interpretation during a more agile engagement).

Traceability One important note to remember when gathering and recording requirements, regardless of what project you are on, is that there has to be traceability. 1 – for those projects that have an associated PWS or FRS that serves as a “Promissory Note” (which is most projects), make sure that there is a process for mapping before the 1 st user story is entered into RTC. 2 – for requirements (user stories) entered into RTC, once saved and/or delivered to the client, an RTC number should never be used twice – meaning that you should never delete the contents and start over using the same number to represent a totally different requirement. This makes traceability next to impossible.