Why Every Job Seeker Should Have a Personal Website, And What It Should Include
IntellegoJobs – Current Job Opportunities, US Employment News, and Job Seeking Tips for the Bookkeeper, CPA, Programmer, Computer Hardware Engineer, Software Engineer, Computer Support Specialist, Systems Analyst, VoIP Engineer, Civil Engineer, Mechanical Engineer, High School Teacher, Middle School Teacher, Pharma Sales Rep, Sales Rep, Pharmacist, Physician Assistant, Physical Therapy Assistant, Registered Nurse, Pilot, and Truck Driver.
Business Analyst Community & Resources | Modern Analyst
RSS feeds for Business Analyst Community & Resources | Modern Analyst
What are some steps the Business Analyst can take to avoid vague, incomplete or ambiguous requirements?
Stakeholders often interpret requirements in a variety of different ways. Whether its from the natural ambiguity of conversational language or due to missing information, ambiguous and incomplete requirements can lead to project delays and budget overruns. But by keeping a few key considerations in mind the Business Analyst can dramatically improve the quality of product requirements.
What is a business entity model?
A business entity model is a logical model that documents the entities, or things, that a business or business process uses and interacts with in order to accomplish its business activities and goals. In addition to documenting entities, a business entity model may capture the attributes of an entity, relationships between entities, and cardinality information. Many business entity models are created in the form of a UML class diagram. However, it is important to note that business entity models document the logical structure of a business domain, not the physical structure.
What techniques have you used to elicit business requirements?
There are a number of methods used for eliciting and discovering requirements. These methods can be categorized into two main categories: Collaborative Interaction and Restricted Interaction.
What is DMN and how is it used to support BPMN?
BPMN is used to define business processes as a sequence of activities. Gateways are used to show branching of different process paths. For many years, analysts would clumsily model decision logic directly in business process models in an attempt to fully define process branching logic. This made process models messy.
DMN or Decision Modeling Notation was published in 2015 by the Object Management Group. It's a graphical language for specifying business decisions. DMNs primary purpose is to give analysts a tool for separating the business decision logic from the business process.
What are the 5 basic categories of elements in BPMN?
BPMN is a robust notation designed to balance two competing needs. The notation should be simple enough for all stakeholders to understand, yet robust enough to handle complex orchestration of events to a level of detail which can be made executable. Not an easy thing to do. However, by organizing elements into distinct categories, a sizable notation can be more easily understood.
What is the Cone of Uncertainty?
The Cone of Uncertainty is a term often used in project management to describe the phenomenon by which project unknowns decrease over time. As the project proceeds and more research and development is completed the amount of uncertainty decreases, eventually approaching zero. Project unknowns, or uncertainty, largely correlate to variances in project estimates. Plotting these variances over time creates a cone or funnel shape (variance percentages shown are only examples, values may vary).
What types of actions can help the business analyst avoid Analysis Paralysis?
Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis. Here are a few symptoms that might clue you in.
How can the acronym INVEST assist the analyst during the development of user stories?
INVEST is an acronym that can help a Product Manager or Developer create quality user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.
I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another. Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.
N - Negotiable: User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.
V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. This means that specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a component which is valuable to a user. A user might expect pages to load within 2 seconds. The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.
E - Estimable: You should always be able to estimate the size of a user story. Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story. When this occurs the user story can be split into two separate user stories. The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature. The spike is always time-boxed, meaning it is limited to a pre-defined amount of time. The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered. These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins. This gives the team time to react if problems arise from the spike.
S - Sized Appropriately: User stories shouldn’t be too big or too small. So how do you decide what size is right. First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big. The user story should be subdivided into two or more smaller stories. Similarly, there is no need to make user stories too granular just for the sake of decomposing features. If features group well together and complement each other then it makes sense to make a single user story. For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.” There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.
T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable. Consider the example, “pages should always load quickly”. There are two un-testable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.
What is the different between a business policy and a business rule?
Business Rules and Policies tend to be complicated for analysts to untangle because they are so closely related. Policies are typically more general assertions or guidance about how an organization is intended to operate, while business rules describe the specific execution of the business policy.
The BABOK describes a policy as “a non-actionable directive that supports a business goal', and a business rule as 'a specific, actionable, testable directive that is under the control of the business and supports a business policy'
The Business Rules Group goes further in their definition of business rules describing it as an atomic statement that defines or constrains some aspect of the business. They categorize business rules as one of three sub-classifications; structural assertion, action assertion, or derivation. The definitions of these get quite detailed and while knowing them, along with understanding things like fact models, may help elaborate one’s understanding of a business rule, at a summary level business rules are best understood by a higher level definition (like the IIBA’s) and a few examples.
Additionally, policies, being more general, typically change less often than business rules which are specific implementations of policies.
To restate, a policy is:
- A non-actionable directive
- Often requires employees to translate into specific statements of what to do (business rules)
- Supports a business goal
- Supported by one or more business rules
A business rules is:
- Supports a policy
Examples of policies for a car rental company:
- Maintenance must be performed in a manner which maximizes the life and value of the car
- Renters must have valid insurance
Example of business rules that may support these policies:
- All vehicles are required to have a 58 point inspection after every 3 months of use before re-renting.
- A car which has accumulated more than 3500 miles must have its oil changed before re-renting.
- Tires with less than 1/16th inch of tread must be replaced.
- Renters in the state of Texas must have insurance covering $100,000 of liability or more.
- Renters in the state of Arizona must have insurance covering $50,000 of liability or more.
Notice that each of the business rules are written as a level which is actionable, specific, and testable.
What is the business case for using personas?
Many organizations that lack experience with personas don't fully understand the value of them. Furthermore, personas can be difficult for the inexperience team member to properly create.
What are some pros and cons of using screen mockups for requirements elicitation?
Screen mockups can support the requirements gathering process when introduced at the right time, but if introduced too early they can become problematic.
What is a Mis-Use Case?
A Mis-use Case, which is derived from Use Case, is a requirements and process modeling term used to describe the steps and scenarios which a user performs in order to accomplish a malicious act against a system or business process. They are still use cases in the sense that they define the steps that a user performs to achieve a goal, even if the goal isn’t a positive one or a desired one from the perspective of the business process or system designers.
What is a focus group and how do you conduct one effectively?
A focus group is an interactive guided discussion with a carefully selected group of people (usually demographically diverse) used to obtain feedback about a product, service, or concept. A focus group can be conducted before a launch and/or afterwards for ongoing feedback. Open-ended questions are asked to the group and participants are encouraged to respond and interact freely with other group members. As the facilitator guides the conversation either a scribe will take notes or a video recording may also be made for further analysis and review at a later time. Focus groups typically last for one to two hours.
What is a RACI Matrix?
RACI Matrix is the name given to a table which is used to describe the type and degree of involvement that stakeholders have in completing tasks or deliverables for a project or business process. Also sometimes called the Responsibility Assignment Matrix or Linear Responsibility Chart, it is a common tool used by business analysts and project managers for establishing roles and responsibilities early on in a project. In this way it reduces project risk and sets expectations about the level of involvement that is expected by various stakeholders.
How familiar should a business analyst be with BA skills and techniques that aren’t used in their current position?
This may seem like an obvious question, as if the interviewer is asking you to say “very familiar, and I make sure I know everything there is to know about ALL things business analysis related”. However, how you answer this question can ultimately reveal a lot about your desire to grow as a business analyst, how well you manage your spare time, and how honest you are throughout your interview.
First, an interviewer wants to assess your eagerness to grow as a business analyst. Are you the type of analyst that is always looking to improve and learn a new technique or skill? Do you feel it’s important to gain and understanding of business analysis techniques that you won’t even use for the foreseeable future? The answer to this question should be yes.
Describe the User Centered Design methodology
The User Centered Design methodology focuses on the user's needs and goals throughout the entire product or application development lifecycle. This design approach places the user as the focal point of all phases of the development process from concept development to design, development, deployment, and finally to post-deployment assessment. It is an approach which emphasizes cognitive factors such as a user’s perception, emotion, and memory and how these cognitive factors participate in the interactive experience.
What are Personas and how are they used during application design?
Personas are used as part of User Centered Design methodologies. They are detailed profiles of fictional characters which represent a specific segment of users within a targeted demographic. For this reason, analyst and designers typically use personas together with market segmentation. They are intended to help application designers fully envision and understand the different attitudes and behaviors of users within various demographic segments.
What is meant by application usability?
Usability is a measure of the interactive user experience associated with a system such as a business system, website, or mobile application and is a focus of fields of the Human Factors Psychology and Human-Computer Interaction (HCI) fields of study. Usability is the quality of a system that makes it useful in achieving a user’s goals, effective and easy to use, quick to learn, and like-able, i.e., subjectively pleasing to the user.
What is Enterprise Architecture, and why is it relevant to a Business Analyst?
Enterprise Architecture (EA) is the practice of fully describing and viewing an enterprise through the use of models and other representations. EA’s views of the enterprise cut across all of the domains that a complex enterprise contains: security, strategy and performance, business, data, infrastructure, and applications.
What are the essential components of a use case?
Use case name
Normal process flow
Alternate process flows
What are the basic types of actors that can exist in a Use Case Diagram?
Actors can be primary or secondary actors. Primary actors initiate a use case, while secondary actors support a use case or receive something of value from the use case.
How should the Business Analyst begin the requirements elicitation process for a new product or solution?
When beginning analysis on a product or solution that is needed to meet a business need, the Business Analyst needs to obtain a basic understanding of the pain points that the business wants to address.
At this stage of this process there is only a need to get the equivalent of a business executive’s point of view. That is, the analyst needs to get a high level understanding of the pain points, framed through the six basic questions someone needs to ask in order to understand any object: Who, What, Where, When, How, and Why. Let’s take each of them in turn.
How would you build a Business Process Model?
Building a Business Process Model is a complex task that requires a number of successful steps to complete.
1) Determine scope
2) Gather background information
3) Conduct interviews
4) Begin Modeling
5) Validate and iterate
Describe the requirement engineering process SQUARE.
SQUARE stands for Security Quality Requirements Engineering. It is a requirements engineering process developed by Carnegie Mellon University’s Software Engineering Institute (SEI) which focuses on eliciting and documenting security requirements. Since security requirements are often not given the focus that they deserve and since trying to incorporate security requirements later in the software development lifecycle costs more than planning for them upfront, the SEI developed a nine-step process to ensure that quality security requirements can be gathered, categorized, prioritized, and validated early on in the software development lifecycle.
What is Document Analysis?
Document Analysis is a technique used to gather requirements during the requirements elicitation phase of a project. It describes the act of reviewing the existing documentation of comparable business processes or systems in order to extract pieces of information that are relevant to the current project, and therefore should be consider projects requirements.
Systems Analyst Jobs
Listed by State – Updated Daily
Powered by FirstRSS Plugin