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!
Is a business analyst with domain knowledge more valuable than a business analyst without domain knowledge?
By looking at how business analyst job descriptions are written, you may be tempted to say yes!
Business Analyst job descriptions are written as if there is a distinction between IT oriented business analysts with skills in UML, Use Cases, Requirements Elicitation, Requirements Modeling and domain oriented business analysts with knowledge in specific domains like sales, marketing, customer relationship management, insurance, finance!
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.