Now is a good time to “consider a more flexible career” because all the changes taking place in the marketplace are fundamentally transforming the way we work as well as the opportunities available to us!
This is great news for anyone interested in a more flexible career or employment including options to work from home, consult for companies or retire or travel while earning an income!
You are a tool minded business analyst, if the first question that comes to your
mind on hearing the words: “Use Cases, UML or User Acceptance Testing” is: “what tool
should I use to create my Use Case / UML / User Acceptance requirements document
Tool minded business analysts are more interested in learning the intricacies, features
or behavior of the software tools used in their requirements elicitation, analysis or documentation tasks than in correctly analyzing, validating or defining business requirements.
[Ask IT Career Coach] is a Career Advice Newsletter for Information Technology (IT) professionals including business analysts, computer programmers, data analysts, database developers, technical writers, project managers and software testers.
If you, have a challenging question about your career, submit it here and we will answer yours just as we are answering this question submitted by a technical writer titled: What Software Do I Learn to Become A Business Analyst? …
How do I learn or get the software knowledge that would make me a business analyst?
The project sponsor is not the business analyst even though the project sponsor helps the business analyst in gathering requirements and the project sponsor is not the project manager even though the project sponsor helps the project manager deliver a successful project.
It is the project sponsor’s job to ensure that the project team (project manager, business analysts, and team lead) have the technical or operational resources they need and that the project is aligned with the strategic needs of the organization.
If you work in an office where requirements management is a low priority, an afterthought or a process imposed by senior management, you may begin to lose sight of the value that requirements management offers.
In between chasing down your stakeholders for interviews, wrestling with your use cases or managing conflict and corporate politics, you may decide to abort what sometimes seems like meaningless meetings or endless paperwork.
What you may not know is that the reason you’re chasing down stakeholders or having so much trouble gathering requirements is that you don’t have an effective Requirements Management framework in place.
One of the toughest challenges facing business analysts today is building the domain experience required for business analyst jobs.
Acquiring business analyst domain experience from scratch is hard because you need to get a job before you can build domain expertise … yet no-one will give you a job without that required domain experience!
This post however discusses how to get around the business analyst domain experience required for business analysis jobs.
Use Cases skills are in-demand for documenting or communicating the functional requirements of a system
Use Cases skills are employed in product design roles, software development or architecture roles and are among the most sought-after skills for business analyst jobs
Why Use Cases Training for Business Analysts?
Here are some of benefits of Use Case training for business analysts:
Use Cases are effective for documenting the business processes, requirements (business or system), features and functionality of a system. So Use Cases skills are needed at the problem analysis or requirements gathering phase, software design or development phase or testing phase
Thomas Edison’s diary contains five million pages and is maintained as an important part of the United States historical record. Two of the criteria for Edison’s record system are crucial to the Business Analyst:
Item #3 -The Records must be Rearward-looking. Basically, you should always keep requirements traceability in mind as you take notes.
It is common knowledge that the biggest reason for IT project failure is poor requirements. If the requirements that the developers are working from are wrong, incomplete or otherwise inadequate, that project is doomed to join the 70% of IT projects that fail every year.
So why not simply gather good (SMART) requirements? Ask any business analyst and they will tell you that the biggest problem they face is getting users to tell them what they really want out of a new system or process. Why? The reasons are varied. Sometimes it appears that users simply won’t communicate what they really want. Sometimes it appears that the business analyst is asking all the wrong questions. Sometimes it appears that the users change their minds all the time.
When gathering or analyzing requirements, it is just as important to focus on the process that you are using to develop your requirements as it is to focus on the requirements themselves.
If you have a poor requirements elicitation or management process, you risk not understanding the business problem you are trying to solve or turning out a poor product.
The cost of Information Technology (IT) project failures has become so high that one can no longer ignore the fact that business analysts need to invest a good amount of time into understanding what they intend to build.