Quotes For Business Analysts
/Imagine you are re-engineering a process and an experienced user tells you there is a critical step to “obtain the customer’s signature on form XYZ” before proceeding further and that this often causes delays. This might lead you to think about ways to optimize the process to get the process quicker; perhaps you could send a form earlier in the process. However it’s also important to ask why that signature is necessary in the first place. Perhaps the process step could be fundamentally changed, or perhaps it isn’t necessary at all. It’s important that we explore these angles tactfully with our stakeholders. – Adrian Reed
On Building the Right Software
We compared our different approaches and experiences, extracted the core principles, and (to our surprise) managed to condense it into this shared message: Great results happen when: 1. People know why they are doing their work. 2. Organizations focus on outcomes and impacts rather than features. 3. Teams decide what to do next based on immediate and direct feedback from the use of their work. 4. Everyone cares. - Gojko Adzic
People often talk about “gathering requirements.” This phrase suggests that requirements are just lying around waiting to be picked like flowers or to be sucked out of the users’ brains. I prefer the term requirements elicitation to requirements gathering. Elicitation includes some discovery and some invention, as well as recording those bits of requirements information that customer representatives offer to the BA. Elicitation demands iteration. The participants in an elicitation discussion won’t think of everything they’ll need up front, and their thinking will change as the project continues. Requirements development is an exploratory activity. - Karl Wiegers
A business analyst is not simply a scribe who records what customers say. The BA is an investigator who asks questions that stimulate the customers’ thinking, seeking to uncover hidden information and generate new ideas. It’s fine for a BA to propose requirements that might meet customer needs, provided the customers agree that those requirements add value before they go into the product. A BA might ask customers, “Would it be helpful if the system could do X?” The customer might reply, “No, that wouldn’t do much for us.” Alternatively, the customer might reply, “You could do that? Wow, that would be great! We didn’t even think to ask for that feature, but it would save our users a lot of time.” - Karl Wiegers
I once spoke with a manager on a five-year project regarding requirements growth. I pointed out that, at an average growth rate of two percent per month, his project was likely to be more than double the originally estimated size by the end of the planned sixty-month schedule. The manager agreed that this was plausible. When I asked if his plans anticipated this growth potential, he gave the answer I expected: No. I was highly skeptical that this project will be completed without enormous cost and schedule overruns. - Karl Wiegers
When you know that requirements are uncertain and likely to change, use an incremental or iterative development life cycle. Don’t attempt to get all the requirements “right” up front and freeze them. Instead, specify and baseline the first set of requirements based on what is known at the time. A baseline is a statement about the state of the requirements at a specific point in time: “We believe that these requirements will meet a defined set of customer needs and are a suitable foundation for proceeding with design and construction.” Then, implement that fraction of the product, get some customer feedback, and move on the next slice of functionality. This is the intent behind agile development methodologies, the spiral model, iterative prototyping, evolutionary delivery, and other incremental approaches to software development. - Karl Wiegers
When I am ready to dig into the detailed requirements, there are a few things I am on the lookout for. First of all, what I do not want to see are long, wordy paragraphs with several requirements buried within it. It may feel more natural to write this way, but not only is it painful to read requirements this way, it also greatly increases the likelihood that a requirement will be missed somewhere along the way, either during the development, or in testing. A much safer practice is to write each individual requirement separately, and give it an identification number. That way, even if a requirement does get missed during development, it will get picked up in the testing.
