Business Analyst Community & Resources | Modern Analyst

Describe the Elicitation knowledge area of the BABOK and its key tasks (BABOK v2.0)?

cadams5 — Sat, 06 Feb 2010 22:02:00 GMT

How do you define the term Requirement?

cadams5 — Sat, 06 Feb 2010 21:55:00 GMT

What is the PDCA method and how is its application by the Business Analyst beneficial?

cadams5 — Sat, 06 Feb 2010 21:50:00 GMT

What are the seven business analysis knowledge areas as defined by the BABOK v2.0?

cadams5 — Sat, 09 Jan 2010 19:43:00 GMT

The BABOK Knowledge Areas define categories of related information and tasks that a business analyst must understand and apply.

Knowledge areas do not necessarily represent, or need to align with, phases of a project. There is no specific order in which tasks from various knowledge areas must be performed by the business analyst, as long as the necessary inputs for each task have been completed and are available. The seven knowledge areas are:

Business Analysis Planning and Monitoring
Elicitation
Enterprise Analysis
Requirements Analysis
Solution Assessment and Validation
Requirements Management and Communication
Underlying Competencies

How do you resolve an issue involving conflicting requirements from two or more stakeholders?

cadams5 — Sat, 03 Oct 2009 19:45:00 GMT

What is XML (eXtensible Markup Language)?

cadams5 — Sat, 03 Oct 2009 19:11:00 GMT

XML stands for EXtensible Markup Language. It is a self descriptive markup language. This means that the tags used to describe the content of the XML file are not predefined, but instead the author defines his own tags and document structure. XML was designed to transport and store data, while HTML was designed to display data. Unlike HTML which has standard tags that browsers can be programmed to display (i.e., <p>, <table>, <h1>, <em>), an XML file requires software to be written in order to send, receive, display or manipulate the data in the XML file.

XML was created to simplify data sharing. It provides a method for storing, sending, and receiving data between systems that may contain data in incompatible formats. Since XML is stored in a plain text format, an XML document is both software and hardware independent. This makes it much easier to create data that different applications can share.

While HTML can display data on a webpage directly, XML allows for easy separation of data from presentation information so that if the data needs to be changed the HTML page is left unaffected. This can be achieved by using Javascript within the HTML file that references the data in a separate XML file. Whenever the data needs to be changed, only the XML file needs to be updated.

What is HTML?

cadams5 — Sun, 06 Sep 2009 00:18:00 GMT

HTML stands for HyperText Markup Language. It is the predominant markup language used on web today for the creation of web pages. The term markup language is used to describe annotations that are added to any document that are distinguishable from the original text of the document. In the case of HTML, these annotations are distinguishable by the use of angle brackets “<” “>” to create HTML tags.

HTML tags are used to annotate a document, such as a webpage, in order to define its structure. HTML tags define various types of webpage content in terms of headings, paragraphs, lists, tables, data, quotes, and more.

HTML and Cascading Style Sheets (CSS) are almost always used hand in hand. While HTML defines the structure of a document, CSSs define the presentation of a document. Using the HTML <style> tag, a predefined style from a CSS can be referenced to format the content of the HTML document as desired. Using HTML and CSS together allows for the decoupling of the structure and presentation of a document. One of the benefits of this is that the presentation of a document can be changed at any time without modifying the HTML document itself.

How do you keep management from reducing your estimated analysis hours in order to fit their original high level guesstimates?

cadams5 — Sat, 05 Sep 2009 23:55:00 GMT

As seasoned business analysts, we are often asked to provide estimates for how long a particular set of tasks might take. If you’re working in an environment that is constantly trying to get more done with less, then you probably have also experienced the difficult task of having to rationalize your estimates for a large portion of analysis effort.

Consider the scenario where you provided the following estimates:
80 hrs – Documenting the AS-IS Business Process Flows
150 hrs – Eliciting and Documenting Requirements
100 hrs – Documenting the TO-BE Business and System Process Flows
400 hrs – Writing Functional/Design Specifications
Total 730 hours

Later you find out that while management was developing high level guesstimates for planning purposes they ball-parked 500 hrs.

This is when the business analyst is now asked questions like…
Will it really take 150 hours to elicit and document requirements? Can you do it in 100 hrs? What about Writing Functional and Design Specs? Can you do that in 350? Typically, the business analyst responds with an “I guess so” only to find out later that the work is behind schedule and they needed the full 730 hours, or more!

It can be difficult to defend the need for 400 hrs compared to 350 hrs when estimates are at such a high level. For this reason, the business analyst should get into the habit of providing more detailed work breakdown structures and estimates. By breaking each task down into more granular sub-tasks a number of benefits can be realized.

The level of error resulting from estimates tends to be smaller when more granular tasks are estimated. Business analysts have a fairly strong sense of how long a 6 or 8 hour task will take to complete. This is far different than estimating a 400 hour task. How do you really know if it will take 400 hrs, or 360hrs, or 440 hrs?
Management almost never questions estimates on very granular tasks. Have you ever heard a manager look at a work breakdown structure with 50 or more tasks and say, will this task really take 8 hours, or can you do it in 6? There are several reasons for this. First, they have a greater level of confidence in your ability to estimate a small task. Second, all they will save is two hours. That’s nothing. By contrast, they see a 400 hour task and think they might be able to say 40 or 60 hours. Now that’s something.
Having a more granular work breakdown structure gets everyone on the same page as to the steps involved to complete the work. This may uncover dependencies that the team would not have noticed if they were only looking at the high level tasks.

A good rule of thumb is that no single task should be greater than 40 hours when estimating. And if you know that your management has a habit of pushing back hard on estimates make sure that no single task is greater than 20 hours, with most being less than 8-12 hours.

What is a UI Design Pattern and what are its benefits?

cadams5 — Wed, 05 Aug 2009 03:53:00 GMT

What are some guiding principles or tenants of UI design?

cadams5 — Wed, 05 Aug 2009 03:49:00 GMT

Usefulness

Ensure that the system includes the most important features and functions needed to provide value to the user. A system that is missing high priority functionality is not going to be very valuable. Similarly, a system that includes too much additional functionality which lacks relevance to the user will obfuscate the intended flow through the system.

Consistency

Consistently apply the UI design patterns that your group has agreed upon and adopted ahead of time. This includes UI actions, product terminology and UI commands. UI design pattern consistency is important across screens within an application as well as across applications within a suite of products. Whenever appropriate, the concepts, terms and metaphors used should mirror that of the real world and present information in a logical order.

Simplicity

Keep the design clean and clutter free eliminating any unnecessary or irrelevant information, features, controls, or icons. When many options are available for a user to complete their task, keep the most commonly used options visible and make the other options readily accessible via some other means. Design the system with the goal of being intuitive enough that an appropriate user of the system can learn it without instruction or formal training.

Communication and Feedback

The system should provide clear and timely feedback in response to user actions. This reinforces within the user’s mind that they have taken the correct step to successfully complete the task. Organize and sequence the information within a screen in a way that conveys specific meaning to the user. Like information should be grouped together and the order in which a user encounters information should reinforce the flow of the process as they currently understand it. Ensure that whatever help information is provided is concise and focuses specifically on the user’s task.

Error Prevention and Handling

A system cannot and should not catch all mistakes. It should catch serious errors when possible, but should not be so restrictive that it does not allow for reasonable variation in data entry or process flow. Ask the user for confirmation before allowing a potentially destructive action such as permanently deleting a record. If the user performs an incorrect action, provide clear and descriptive messaging that describes what they have done wrong and when possible how they can correct it. To relieve anxiety, provide the user with the ability to discard unwanted changes, or to undo a particularly sensitive action.

Efficiency

Ensure that skilled users can use the system efficiently and that functionality built for inexperienced users does not slow down skilled users. Provide shortcuts keys and functions for the experienced user and allow for customization of shortcuts when possible for frequent actions.

Workload Reduction

Automate aspects of the process and system whenever possible. If something can be easily derived by the application then don’t make the user spend time doing it. Eliminate mental calculations and comparisons by showing the results on screen. Ensure that users don’t need to remember information from one screen to another. Provide the necessary information on each screen for them to be able to complete their work.

Designer Judgment

Remember that usability guidelines are just that, guidelines. There are tradeoffs between perfect UI design, user experience, and system performance. There will always be cases where it makes send to not follow a particular guideline or principle. Use your judgment. However, try to stray from guidelines as infrequently as possible and, when doing so, be sure to document the reason why the guideline was not followed for future reference.

What should be documented in a UI Design Pattern?

cadams5 — Wed, 05 Aug 2009 03:32:00 GMT

Though pattern descriptions vary somewhat, many pattern templates contain a set of common sections.

Primary Sections of a UI Design Pattern

Name: Should be concise yet descriptive (typically between two and four words in length) so that someone can find the pattern easily and reference it within discussions for clear communication amongst team members.

Description: A few lines briefly describing the pattern. Since short names are not always sufficient enough to clearly and uniquely describe the pattern a description is important. However, this is not where you will describe the pattern in great detail.

End User Requirement/Problem to Solve: Communicate what requirement or challenge will be solved by the pattern. What is the user trying to achieve?

When to Use/When Not to Use: It isn’t always obvious under which condition or within which context a pattern should be used. Here you can document when a pattern should be used and, equally important, when it should not be used.

Solution: Document the details of the pattern/solution including a detailed description of the user interaction. Include screenshots to help convey the pattern clearly as needed.

Comments: Capture any other comments that you feel are relevant to the reader.

Optional Sections of a UI Design Pattern

Depending on the needs of your team or organization you may choose to add some additional sections to your pattern template.

Examples of Past Uses: Including screenshots of past uses of the pattern along with a brief description can help the reader visualize the benefits of using the pattern.

Rationale for Use: Understanding why a particular pattern works so well can be invaluable when deciding whether to use one pattern over another. Detail out the specifics of the user experience and the direct benefits that they receive by using this pattern.

Implementation Specifications: If standards exist within your organization or team, consider accompanying the pattern with style guide information such as font family, font size, font weight, font color, table and cell spacing, and more. Or if the styles change based on the application or product being developed, provide a link to the style guide information.

Usability Research: Any specific feedback on how well the pattern works can be documented for future reference. Consider including feedback from UAT testers or your sales organization, but also don’t exclude feedback from developers and other testers.

Related Patterns: List other patterns that may solve a similar problem or patterns that work together to achieve a broader goal.

Pattern Variations: Document minor variations in the pattern that can be used. If the variations are significant enough, consider developing a separate but similarly named pattern. For example, “Tag Cloud 1” and “Tag Cloud 2”

Development Notes: Capture notes that help the development team implement the pattern. This may be a snippet of code or a link to a code library where the code for the pattern can be found.

What type of testing might involve the business analyst?

cadams5 — Fri, 03 Jul 2009 04:21:00 GMT

What types of testing should be considered when developing an application?

cadams5 — Fri, 03 Jul 2009 04:18:00 GMT

There are so many different types of testing that it would be difficult to come up with a comprehensive list. Additionally, each type of testing typically has a number of variants that have been developed based on the team creating the testing strategy. However, the most common types of testing used by a majority of projects are:

Unit Testing (Component Testing) – refers to the testing of individual software components as they are completed. This type of testing is typically completed by the development team.

Integration Testing – refers to the testing of components as they are combined or integrated together. This ensures that each component that has been tested on its own operates correctly when it is used in conjunction with the other components that it is designed to interact with. This is particularly important for client/server and service oriented architecture systems.

User Acceptance Testing – refers to testing that is performed by the user or end customer of the system as a condition of approval. User Acceptance Testing is where the user/client ensures that the final application or product meets the agreed upon requirements set forth by the Business Requirements Document. This is also why traceability of requirements throughout the entire Analysis, Development, and Testing lifecycle is so important.

Functional Testing (Black Box Testing) – refers to testing the features and behavior of an application to ensure that it coincides with the functional software specifications provided. This type of testing is also referred to as black box testing because it completely ignores the internal workings of the program and focuses only on the outputs as a result of the specified inputs and execution steps.

Usability Testing – refers to testing the ease in which users can learn the application, as well as the users’ efficiency and productivity while using the application.

Performance Testing (Load Testing, Stress Testing) – refers to testing performed to evaluate whether the system meets the documented performance requirements. Performance Testing ensures that the system will support a specified number of users while still maintaining specific service level agreements (SLAs) for page load times and service response times. This type of Performance Testing is also called Load Testing. Additionally, during Performance Testing, often it will be required to test the systems limits and determine the maximum number of concurrent users that can be supported before the system fails. This is referred to as Stress Testing.

Regression Testing – refers to testing a portion of the application that has previously been tested following a modification to ensure that the original functionality still works and behaves per the specification. While Regression Testing really just means to go back and retest, it typically refers to Functional Testing.

What is Model-View-Controller?

cadams5 — Sat, 06 Jun 2009 20:31:00 GMT

What is the difference between a Primary and Secondary Actor in Use Case Modeling?

cadams5 — Sat, 09 May 2009 23:10:00 GMT

What is a View as it relates to system modeling?

cadams5 — Sat, 09 May 2009 23:06:00 GMT

What is the 4 +1 View Model as it relates to system modeling?

cadams5 — Sat, 09 May 2009 22:59:00 GMT

The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process Development at Rational Software.

The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to capture and communicate different aspects of the system.

The 4 primary views are:

Logical View: this view describes the functionality of the system in terms of its static structure and dynamic behavior.
Development View: this view describes the system from a programmer’s perspective and is concerned with the organization of physical code, its main modules, and their dependencies.
Process View: this view focuses on the runtime behavior of the system and the elements of the system that relate to process performance. It includes aspects important to scalability, throughput, and process response times to name a few.
Physical View: this view shows the system from a system engineer's point-of-view. It is concerned with the deployment of software components across the physical architecture including computers and devices , as well as communication between these components.

The 1 supporting view is:

Use Case View: this view describes the functionality of the system from the perspective of external actors.

What is the difference between a use case alternative flow and an exception flow?

vineetbanwet — Sat, 07 Mar 2009 08:13:00 GMT

A use case specification describes the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system. It represents the most common way that the use case plays out successfully and contains the most popular sequence of user-system interactions. Other scenarios or paths through the system are described in alternative flows and exception flows. So what is the difference?

First, it’s worth saying that there are a number of opinions in this area since the Unified Modeling Language has no standard for Use Case Specifications. Some authors mention only alternative flows and use them for both optional flows and error flows. However, of those authors that do differentiate between alternative flows and exception flows some agreement in definition has emerged.

An alternate flow describes a scenario other than the basic flow that results in a user completing his or her goal. It is often considered to be an optional flow and implies that the user has chosen to take an alternative path through the system. An exception flow is an unintended path through the system usually as a result of missing information or system availability problems. Exception flows represent an undesirable path to the user. However, even though the exception flow has occurred the system will ideally react in a way that recovers the flow and provide some useful information to the user.

The primary benefit of differentiating between alternative flows and exception flows is the focus that exception flows bring to error conditions. By capturing all of the ways that the system can fail or produce an error, the business analyst can be sure to create a design which mitigates the impact of the error.

What are some of the limitations of use cases and use case specifications?

vineetbanwet — Fri, 06 Feb 2009 06:00:00 GMT

Use cases are a valuable tool available to the business analyst for documenting functional requirements of a system or business, however they do have limitations.

Use cases were not created to capture non-functional requirements (e.g performance, platform, scalability, reliability of a system). While use case specification templates have been extended by some in an ad-hoc fashion to list non-functional requirements, this strays from the intended purpose of a use case. Use cases are functional in nature. It is this very organization by function that give use cases their many benefits. Arbitrarily listing non-functional requirements in one use case specification or another can obfuscate the cohesiveness and benefits of the use case specification.
The non-sequential nature of a use case diagram is often difficult for some audiences to understand. When one use case includes or extends another, the reader of the diagram often arrives at the incorrect conclusion that the use case diagram is showing a sequence where the first use case is completed before the other begins. Those who are familiar with use case diagrams know that an included or extended use case can occur or be initiated at any point within the including or extending use case.
Learning how to write use cases takes time. Many consider it to be more of an art than a science. This is because there is no fully defined set of standards for how to write use cases, or what should be included within a use cases specification. And while there have been many different views espoused by authors, still a great deal of commonality has emerged among them. Where this commonality exists there is little disagreement among use case writers and those who consume or read use cases. However, in some areas there are still a number of differing opinions creating confusion for new use case authors. Because of this, the learning curve for use cases and use cases specifications is elongated. Still, over time, use case authors and readers develop a more sophisticated understanding of those areas that are more ambiguous and open for interpretation, such as the “extends” relationship.
Use case specifications are not an appropriate tool for describing the user interface of the application. Use cases should be left as UI independent as possible. Remember that a use case specification it intended to capture the functional requirements of the system, or in other words, WHAT the system should do in response to a user action. This is very different than HOW the system should do something. Any time an analyst captures requirements, the focus should be on the WHAT not the HOW. This gives the system and UI designer the freedom to develop the best solution possible. It also makes our use case specifications much more maintainable since a change in screen design doesn’t impact the user-system interaction previously defined.

Quality Assurance versus Quality Control

cadams5 — Thu, 08 Jan 2009 05:32:00 GMT

Quality Assurance is about Process. It describes the proactive method of establishing a process that is capable of producing a product or deliverable that is error or defect free. Expanding on this further, we can see that:

Quality Assurance means time is spent upfront planning and designing a process that can repeatedly produce a high quality product or deliverable.
Quality Assurance provides confidence that if the process is properly followed, there is a high likelihood that the final product or deliverable will meet specifications. In other words, it reduces and prevents defects or errors in the final product or deliverable.
Quality Assurance is about establishing a sound and capable process.

Quality Control is about Products or Deliverables. It describes checking a final product or deliverable to ensure that it is defect or error free and meets specifications.

Quality Control occurs after the process is completed.
Quality Control is about verifying that the product or deliverable meets specifications. It detects errors and defects in the final product before the product reaches the customer.
Quality Control focuses on the end product or deliverable.

To summarize, Quality Assurance is focused on the process, is proactive, and prevents defects; while Quality Control is focused on the product or deliverable, is reactive, and detects defects after the fact.

What is the difference between a use case specification and a use case realization ?

vineetbanwet — Tue, 06 Jan 2009 17:16:00 GMT

A Use Case Specification is a textual description of the functionality provided by the system. It captures actor-system interaction. That is, it specifies how a user interacts with a system and how the system responds to the user actions. It is often phrased in the form of a dialog between the actor and the system. The use case specification is represented in the use case diagram by an oval, and is what most people think of when they hear the term use case.

A Use Case Realization describes how a use case, which is logically defined by the use case specification, is physically implemented within a design model in terms of collaborating objects. It organizes the design model artifacts related to the use case. It often comprises multiple design artifacts such as a class diagram, object diagram, sequence diagram, etc. that describe how the physical design will implement the use case specification.

The purpose of use case realization is to separate the concerns of the system stakeholders, which are typically captured by the use case model and system requirements, from the concerns of the system designers. In doing so, the designers can choose to implement the use case specification without affecting the use case specification.

Which project participants benefit from Use Cases?

cadams5 — Wed, 01 Oct 2008 21:20:00 GMT

The full benefit of use cases are not always understood by all. Use cases provide more benefit than simply capturing functional requirements of the system, and therefore benefit more project participants than just the commonly understood project stakeholders. Here are some of the beneficiaries of use cases.

Project Stakeholders: For project stakeholders, use case models and use cases specify the functionality and interaction that a user will have with the system. It is written in a simple to understand form so that it can be understood by even the most diagram adverse individuals. By reviewing and gaining signoff from the project stakeholders, use cases help analysts validate that the system will meet the functional requirements expected by the stakeholders and will as a contract of what will be delivered.

Developers: Use case models provide a high level overview of the system functionality to the developers. The use cases and use case scenarios add the detail required for a clear understanding of system functionality and provide a solid foundation for the developers to continue with detailed design. By completing the detailed design with the use case model as a guide, the system design remains user-centric ensuring that the final system delivers on the requirements and needs of the stakeholders.

Analysis, Development, and QA Managers: Use case models are an excellent tool for estimating the level of effort required to complete analysis, development, and testing of the application. The use case model divides the system into logical pieces that can be assigned a complexity value and then each use case can be estimated and aggregated to create a final effort estimation.

Project Managers: Use case models are a great tool for project mangers to plan and track the progress of work. Use case models become especially useful in iterative development environments where iterations are planned around the successful implementation of use cases. Use cases are often used in this way because it is easy for stakeholders to see the value of each use case, and therefore the value of each iteration of the application that has been implemented.

Integration and System Testers: Use cases and use case scenarios directly translate into test cases and test scenarios that are used to validate and verify the successful implementation of the system requirements.

Anyone Requiring System Knowledge: Any time someone needs to know what a system does, one of the best places to start is the use case model. By reviewing the use case model, anyone can gain a quick understanding of the functionality of the system. Once they find the use cases that reflect the functionality that pertains to them, they can then look at the details of each use case and gain an immediate understanding of the functionality supported.

What is a Daily Scrum Meeting?

cadams5 — Sat, 06 Sep 2008 17:58:00 GMT

The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team (ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be completed next. It provides an update to the entire team while providing a daily refocus for each team member as they deliver their status.

The daily scrum meeting is led by a Scrum Master. The scrum master leads the scrum meetings, measures progress, identifies obstacles that are slowing or stopping the progress of work, and makes decisions about how to move forward when necessary. The Scrum Master should be someone who has been given the authority to make immediate decisions whenever possible.

During each meeting the Scrum Master asks each team member 3 questions:

What did you do since the last meeting?
Were there any obstacles that impeded your work?
What will you do before the next meeting?

The Daily Scrum Meeting is ideally held at the same time and place each day for 15-30 minutes. Standardizing the time and place of the meeting results in increased efficiency by eliminating overhead associated with finding rooms to schedule and team members determining where they should be each day. It also tends to decrease the number of late arrivals. A primary key to the Daily Scrum Meeting is to keep it short. Any topics unrelated to the 3 questions asked of each team members should be tabled during the meeting and handled at a later time.

What is a Burndown Chart?

cadams5 — Sat, 06 Sep 2008 17:13:00 GMT

A Burndown Chart is a tool used by multiple software engineering methods to track the progress of work completed. It compares the amount of work remaining (typically measured along the vertical axis) against time (measured along the horizontal axis). The amount of work remaining can be measured in whatever way works best for the project, i.e., work-hours, work-days, story points, or any other work unit. Similarly the time axis can be measured using a variety of units, the most common being days or iterations. The burndown chart gives a quick view of the amount of work that is completed over time.

When applied to Agile methods such as Scrum, this tool can be used to track progress at the Sprint level (a specific iteration of development) or at the release level (multiple iterations that deliver the total functionality for a product release). After the amount of work completed has been measured over several units of time, the burndown chart can be used to forecast the completion of an overall release or project.

Why is requirements traceability important?

cadams5 — Fri, 08 Aug 2008 16:36:00 GMT

Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward and backward direction; from its origins, through its realization in the design and functional specifications, to its eventual development and deployment and use, through subsequent rounds of modification and refinement.

If a requirement is changed or modified, using a requirements traceability matrix the analyst can identify those areas within the functional specifications that are impacted by the requirement and make the appropriate modifications. In addition, the analyst can determine if the portion of the specification being modified traces back to any other requirements. This is important to ensure that the new modification doesn’t break any existing requirements within the system.

Similarly, sections of the specification can be traced to areas of the physical code to ensure that all required changes are made during the development process. Test cases can also be traced back to functional specifications. When functional specifications are changed test cases nearly always need to be updated to ensure complete and accurate testing can take place.

Tell me about a time when you were faced with a requirement/enhancement that was not feasible. How did you handle the situation?

Mindra — Wed, 06 Aug 2008 19:13:00 GMT

Even if you know that a requirement is not feasible, be sure not to simply dismiss it away. Your responsibility as an analyst is to maintain a strong working relationship with the business representatives. Approach this situation in a way that makes it clear that the decision isn’t a personal one, but that it’s based on a well informed position with associated costs.

Clarify the requirement. Remember, often when a “requirement” is elicited it is really stated in the form of a solution. So take the time to verify the true requirement.

Identify why the requirement isn’t feasible. If the new requirement and the previous requirements cannot be accommodated at the same time regardless of the technical implementation, then present this information to the business. Do your best to explain the technical limitations using non-technical language that the business can understand.

Most often however, the implementation of a new requirement isn’t feasible due to the prohibitive cost that would be involved in making the technical changes required to support it. Estimate the associated cost and present this information to the business. This is helpful for a few reasons. First, you may have assumed that the cost outweighed the need for the requirement, but the business may feel differently depending on the business goal driving the requirement. Second, if the business agrees the cost of implementing the new requirement is just too prohibitive, then you as the analyst have made your case while making the business feel empowered and involved in the decision making process.

What sort of existing documents should Business Analysts refer to when starting on a new project?

sekharny — Wed, 06 Aug 2008 14:21:00 GMT

Few analysts are brought on to a project at the very beginning. For those that are, they will often have a hand in creating some of the important documents that other analysts should reference when they first join.

First, get your hands on the project charter. The project charter, while high level, will provide critical information on the project such as:

the reasons for undertaking the project, including the high level business goal or goals that are to be satisfied by the project and a calculation of Return on Investment (ROI),
objectives and sub-goals of the project as well as major constraints due to current business processes or existing technology infrastructure,
the high level vision and scope of the project outlining the initial direction for the solution being developed,
major risks which need to be avoided while developing the solution,
the important stakeholders involved which should include not only a project sponsor and steering committee members but also the business representatives that will have final sign-off on requirements.

Find out as much as you can about the project management processes that are being used to manage timelines, risks, communications, costs, etc. Ideally, these processes are outlined in a formal document. If not, be sure to talk to the project manager(s) on your project to fully understand the processes that should be followed.

The same goes for the analysis process and artifacts being used. Understand the methods that will be used for eliciting and documenting requirements. How will these requirements be communicated? How will they be captured and translated into functional specifications? Being an analyst, this is something that you will be taught at some point on the project, but the sooner you learn the details of the analysis process and artifacts being used the better off you will be.

If requirements elicitation has already begun, review the existing requirements documentation. Reviewing requirements will bring you up to speed rapidly. Record any questions you have regarding the system requirements and get answers to them. If a prototype has been created as a method for identifying and clarifying requirements, understand the prototype inside and out. Take the time to understand why each screen was designed a particular way. Was it to support a business requirement, or was it merely a design decision that could have been handled in a different way.

What is an Activity Diagram and what is its purpose?

cadams5 — Sat, 05 Jul 2008 21:05:00 GMT

An Activity Diagram is a behavioral diagram that shows the flow or sequence of activities through a system. The terms activity diagram and process flow are often used interchangeably. However, the term activity diagram is typically more restrictive as it refers to one of thirteen standard Unified Model Language (UML) diagrams. Activity Diagrams are one of the most commonly used diagrams since its notation and origin are based on the widely known flowchart notation.

What are the basic elements of an Activity Diagram?

cadams5 — Sat, 05 Jul 2008 20:42:00 GMT

UML defines a specific notation and set of rules for creating Activity Diagrams. The following are the most commonly used:

Initial Node - The initial node represents the starting point of the activity diagram.
Activity Final Node - The activity final node represents the termination point of the activity.
Action Node - An action node is a type of activity node that represents a single action or behavior of the activity being modeled.
Activity Edge - An activity edge creates a directed connection between two activity nodes. It represents the path that a token can take between two activity nodes.
Decision - A decision has one flow entering and several exiting. The exiting flows each have a condition that must be met in order to traverse the flow.
Merge - A merge has several flows entering and one exiting. The merge denotes that multiple parallel flows are merging at a single point. Only one flow must reach the merge point in order to continue to traverse the flow to the next activity.
Fork - A fork has one flow entering and several exiting. A fork denotes that several processes are occurring in parallel.
Join - A join has several flows entering it and one exiting it. A join denotes that multiple parallel flows are merging at a single point. All flows going into the join must be completed before the next activity can start.

There are others, but these eight symbols constitute the basic notation used by nearly every Activity Diagram.

What is the difference between a Business Requirement Document (BRD) and a Functional Specification Document (FSD)?

zaineb — Thu, 03 Jul 2008 17:10:00 GMT

Business Requirement Documents are written to define the requirements of a business process or a system that needs to support a business process. For purposes of contrasting the Business Requirement Document (BRD) and the Functional Specification Document (FSD), the description of the BRD that follows is written in terms of preparing a BRD for a system. The exact scope of a BRD and FSD vary from company to company. However, the two documents are typically defined as follows:

The BRD contains the business requirements that are to be met and fulfilled by the system under development. These requirements specify "what" the system must do in order to fulfill the requirements of the business. They often take the form of "The system shall..." Each requirement, or group of similar requirements, is typically accompanied by a business rationale. The business rationale explains "why" the business requirement is necessary. This is often important later if analysts or developers have questions regarding the purpose or validity of the requirement. The rationale can be used to support the need for the business requirement or clarify ambiguous language by providing a context for the requirement. In addition to a rationale, constraints can be provided for each requirement along with other supporting reference material.

In contrast, the FSD defines "how" the system will accomplish the requirements by outlining the functionality and features that will be supported by the system. Ideally, the functionality of the system will be described in logical terms so that the FSD is technology and platform independent. This gives the architects and developers more freedom in making development and design decisions about the physical design of the system. Inevitably, however, some things have to be explained in physical terms. The User Interface is one such example. Many FSDs include screen mockups or wireframes for communicating the layout and design of the system screens.

Is it the job of a business analyst or systems analyst to draw the class diagram?

admin — Sat, 17 May 2008 07:00:00 GMT

It depends, it depends, and it depends!

As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.

First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.

Second, the question implies that only one of the person/role on a given project would be task with creating class diagram. This is also not the case! There are many folks (business analyst, systems analysts, developers, etc.) who might have the need to create a class diagram in order to communicate a given concept or to solve a given problem.

So let’s rephrase the question:
“Who would use a class diagram and why?”

The business analyst might chose to create a class diagram in order to model the business domain showing the things of the business (the business domain/industry specific nouns found in the business lingo).

The systems analyst could use a class diagram to develop the logical data model for the system being designed.

The developer may also use a class diagram but for a different purpose: to show the actual classes, interfaces, and types being implemented in a given system.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Fri, 16 May 2008 16:10:00 GMT

The easy answer is “It depends!”

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

But first, let’s determine what a Class Diagram can do for you by looking at some of its characteristics:

A Class Diagram models “classes” also known as types. It shows what types of things can exist in the domain being analyzed. Remember: things = nouns!
A Class Diagram can show the “attributes” of the classes, that is it shows what type of data can be used to describe a given thing.
A Class Diagram illustrates how “classes” are related to each other. It depicts the relationships which can exist among the various things which exist in a given domain.
A Class Diagram shows “multiplicity” also known as “cardinality”. This concept is used to further clarify the relationships between things by specifying how many things of one type can related to how many things of another type.

Therefore, if the analyst uses the Class Diagram to depict the key nouns found in the lingo of the business users (aka the business domain) and the relationships among those things, then this class diagram would represent a domain model and would probably belong in one of the earlier artifacts of the project such as the Business Requirements Document (BRD).

On the other hand, if the Class Diagram is used to explain what C# classes will be used to realize the functional requirements and the types of data attributes which describe those classes, then this diagram would be considered a design artifact and would probably belong in the System Specification/Technical Specification document.

What is the role of the business systems analyst in testing?

mananthakore — Fri, 29 Feb 2008 21:45:00 GMT

The business systems analyst is often responsible for ensuring that the business requirements are satisfied by the final system implementation. This is called requirements validation. One requirements validation technique used by business analysts and systems analysts is the creation of test cases to ensure the final implementation supports the system requirements. Creation of test cases prior to design and implementation often discover problems long before they occur in system development.

What are some of the benefits of a requirements management tool?

Emeka — Fri, 29 Feb 2008 14:13:00 GMT

A requirements management tool supports the analyst in documenting project requirements, versioning requirements, managing the requirement change process, tracing requirements through the analysis and design process, and tracking the status of requirements.

Some examples of requirement management tools are:
Enterprise Architect, Requisite Pro, Telelogic, Caliber-RM

What is a Requirements Traceability Matrix?

Emeka — Thu, 24 Jan 2008 06:06:00 GMT

First of all, let’s talk about requirements traceability in general. Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward and backward direction: from its origins, through its realization in the design and functional specifications, to its eventual development and deployment and use, and through subsequent rounds of modification and refinement.

A Requirements Traceability Matrix is just one method of performing and maintaining requirements traceability.

A good Requirements Traceability Matrix or any other robust method for managing requirements traceability for a project can answer a variety of questions and solve numerous problems such as:

How was a specific requirement implemented?
What pieces of code will potentially be impacted by modifying a given requirement?
Which test cases are used to verify what requirements?
If I change a specific feature in the application what are the requirements which need to be looked at for impact?
What are all the places in the system where a given piece of data is being used?
etc.

What approach should a business analyst take when gathering requirements from high level executives versus the end users?

sonavi — Sat, 19 Jan 2008 00:24:00 GMT

For the most part, the methods and techniques for gathering requirements are the same regardless of whom the stakeholders are: interviews, focus groups, questionnaires, requirements workshops.

However, there are definite things that the business analyst should consider when gathering requirements from high-level executives vs. the end users. The business analyst should tailor his approach and expectations based on the stakeholder type.

Here are some ideas, side by side:

	High-Level Executives	End Users
Requirement Types	Generally provide vision and high-level guidance on the direction of the project. They address key features and major problems to be addressed by the software.	Can provide detailed needs and requirements as related to their specific day-to-day jobs.
Usability	Are less focused on detailed usability issues but may be interested in general UI and usability guidelines.	Are more interested in the usability of the system as they are the power-users. They want the system to be easy to use and efficient (ex: minimize keystrokes and clicks)
Budget/Cost	Are very concerned with the cost and budget of the system therefore will be more likely to prioritize requirements and focus on the ones with higher ROI.	Less concerned with cost, therefore might provide all kinds of “nice to have” suggestions which may not solve real business problems.
Interviews	Effective method of gathering requirements from this group.	Effective method of gathering requirements from this group.
Questionnaire	Not a good way to gather requirements from executives. The execs may actually be the ones approving the questionnaires before sent to end users.	A valuable tool when certain statistics need to be collected from a very large number of potential end users and stakeholders.
Requirements Workshop	Effective method of gathering requirements from this group. It is desirable to have all the decision-making stakeholders in the room when identifying the requirement rankings and when making key design decisions.	Effective method of gathering requirements from this group. It is a good idea to have a number of workshops one for each user type (ex: advanced users vs. most users vs. new/inexperienced user).
Time Availability	High-level executives are very busy so the business analyst must be very well prepared before meeting with this group of stakeholders. Be prepared to focus on the most important problems, issues, questions, etc. The business analyst should use this group to ensure that the direction and goal of the project is clear and well understood.	With this stakeholder group, you might have the luxury of time and ability to cycle back later to clarify requirements. Having said that, these users tend to be less experienced so the business analyst must be able to present the information in simpler and easier to understand ways.

Are there scenarios where the developers will produce something different from your requirements spec, and how would you handle this?

Emeka — Sun, 13 Jan 2008 16:46:00 GMT

Yes, there are instances when the developers will produce something different than what the requirements or functional specification documents contain. Here are some of the instances/causes of such differences:

The specifications are ambiguous or incomplete and they can be easily interpreted in multiple ways. In this case, the developer may have simply misinterpreted the ambiguous requirement in a different way than what was intended.
The developer simply ignored the specification and/or just read it quickly and then developed the system from memory.
The development team encountered technical limitations and the system cannot be developed exactly the way they were specified.

In general, the best way to handle this is to have a clear process in place to manage differences between the specification and the developed product. This would require a strong QA team and QA process. Here are some more detailed which address the three items above:

First and foremost, ensure that the business analysis team has documented guidelines for creating requirements and functional specifications as well as processes in place for peer and management review of analysis artifacts to ensure they are accurate and unambiguous. In addition, since the QA team is responsible for creating test cases and scenarios based on the requirements and functional specifications, they should look for, find, and document as spec defects (bugs) those areas of the analysis artifacts which are ambiguous or are missing information. These defect reports can be used by the analysis manager to identify areas of improvement and also to provide performance feedback to the individual business systems analyst.
Create a process in the development team for each developer to be accountable for his/her deliverables and produce code which is defect free. In addition, the QA team should be able to find these discrepancies and create defect reports (bugs) for the development team to fix.
A process should be in place to deal with instances when the requirements cannot be implemented as outlined in the functional specifications. Have the development team review the functional specs and provide feedback before the coding starts. The development team should be a key stakeholder and reviewer of the analysis artifacts. The feedback can then be incorporated back into the analysis artifacts and, hopefully, resulting in the alignment of the specifications and developed product.

What is the difference between a business analyst and a systems analyst?

adrian — Fri, 16 Nov 2007 09:00:00 GMT

While the differences between the business analyst (BA) and systems analyst (SA) vary from organization to organization, there are some acceptable differences:

Role and Responsibilities

BA: The business analyst's main role is to understand the business processes and procedures (how the business works), to identify areas of improvement (problem areas), and to work with the business stakeholders to identify suitable solutions. If the solution involves the development or modification of information systems, the business analyst is also responsible to gather, analyze, and document the business requirements which must be fulfilled by the software.

SA: The systems analyst's main role is to understand the business requirements (documented by the business analyst) and to design and document the functional and, often, technical implementation of the software/IT system. The systems analyst also helps solve problems and issues with existing systems through research of these systems, code reviews, data analysis, etc.

Skills and Competencies

BA: Great communication and negotiation skills, vertical business/domain knowledge, ability to map and document business processes, requirements elicitation and documentation.

SA: Strong technical skills, excellent troubleshooting and debugging abilities, solid technical writing skills, system modeling/documentation skills (class diagrams, sequence diagrams, etc.), data analysis and modeling skills.

Summary

BA: Talks the business talk; understands the business.

SA: Talks the IT talk; understands the technology.

The reality is that the business analyst and systems analyst roles often overlap. Many analysts who perform both roles have the title of "Business Systems Analyst."

What is Structured English (aka pseudocode)? Please provide an example.

adrian — Mon, 15 Oct 2007 06:43:00 GMT

Structured English or pseudocode is a technique used by systems analysts (and sometimes by IT business analysts) to model and document logic of information processes.

It is a form of English often used in functional or system specifications and it looks a bit like programming statements but does not have a compiler readable syntax.

Structured English uses a subset of English as follows:

Action verbs (ex: display, save, delete, etc.)
Noun phrases (ex: bank account, customer, etc.)
Set of well defined keywords (IF, FOR EACH, WHILE)
NO adjectives or adverbs

Example:

FOR-EACH Account belonging to the Customer

IF Account is NOT closed THEN

Display account on the screen

END-IF

END-FOR-EACH

Why are you looking for a new position?

cadams5 — Fri, 05 Oct 2007 05:06:00 GMT

Most people look for work for greater financial reward or greater responsibility. Totally avoiding the fact that you are looking for a new position because you desire a pay increase can work against you. Most employers are going to run a background check and ask for W2s or paycheck stubs from your current employer. If you are asking for a pay rate that is significantly above your last position you are unlikely to get it unless you confront the issue head on.

Typically a valid response to this question is something like "My last position offered the opportunity to learn some great new skills and improve upon my existing skill set and experience. While it clearly underpaid in the beginning for the skill level required, I was comfortable taking the position because I was sold on the fact that there would be future growth opportunities to compensate for the low salary/wage. This career growth never materialized and I wanted to take on greater responsibility. I no longer felt challenged in my current role and greater responsibility was not available within the current organizational structure. So now I'm looking for a new and challenging position that also offers a commensurate wage".

What is a use case diagram?

cadams5 — Tue, 25 Sep 2007 00:21:00 GMT

[Be the first to post an answer to this question!]

What is a use case?

cadams5 — Tue, 25 Sep 2007 00:18:00 GMT

A use case is a representation of an interaction between business worker and a business process or a user and an IT system in order to achieve something of value (a goal). Use cases are the ovals that appear in a use case diagram. A use case and a use case description or specification are different. While use cases represent an interaction (usually with a simple verb-noun phrase) use case descriptions/specifications describe the interaction in detail form.

Use cases can be subdivided into business use cases and system use cases. Business use cases represent the interaction between a business actor and a business process in order to achieve a goal, while system use cases represent the interaction between a system actor, which can be a system user or another system, and an IT system in order to achieve something of value.

What is CRUD?

adrian — Mon, 24 Sep 2007 22:49:00 GMT

CRUD stands for:

Create,
Read,
Update,
Delete.

These are the four basic functions that can be performed when working with data in a persistent storage.

It also refers to operations that a user can perform using a given feature. With the exception of workflow, most business applications deal exclusively with user interfaces which allow the user to either create (enter), read (view), update (edit), or delete data.

Do you feel UML models, or other types of models, have any value once the implementation code has been generated? Why?

cadams5 — Mon, 24 Sep 2007 22:34:00 GMT

[Be the first to post an answer to this question!]

Would you use a sequence diagram or an activity diagram to model a process flow that has lot of conditional flows and concurrent processing?

cadams5 — Mon, 24 Sep 2007 22:28:00 GMT

Modeling of processes that contain a lot of conditional flows and concurrent processing is typically done using an activity diagram. Showing decision points with multiple outcomes and parallel processes is not only easy to accommodate using the standard UML activity diagram, it is more readily understood by an audience that doesn't have a detailed understand of the UML notation. It's intuitive.

While UML 2.0 incorporates significant improvements over prior versions for supporting conditional processes, parallel processes and loops, using these features tend to be a little more cumbersome without the help of a very specialized or easy to use tool. In addition, the notation is not quite as intuitive to the untrained document reviewer.

What is a business entity model?

cadams5 — Fri, 21 Sep 2007 15:17:00 GMT

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.

The information captured by the business entity model is helpful in later stages of the software development process when class diagrams and database schemas are being designed. This is where logical information begins to be transformed into a physical implementation.

What do you do to increase your value as an analyst?

adrian — Fri, 21 Sep 2007 15:12:00 GMT

Most analysis managers and recruiters who are serious about hiring quality business analysts or systems analysts want to know that you are driven and interested in constantly increasing your knowledge and skills.

You want to be able to demonstrate to them that, outside of the employer required activities, you take the initiative to continue learning.

Here are some things that you can do (before the interview) and which will help you give a good and truthful answer:

participate in networking groups for business/systems analysts (ex: a local IIBA chapter),
join and become and active member of an on-line community of business analysts,
build your brand: write articles, create blog entries, discuss issues related to business analysis topics - this will showcase your skills and knowledge,
mentor junior analysts and other team members,
read books for business analysts (see: Modern Analyst Bookstore),
consider taking a course to refresh and complement your business systems analysis skills (see: List of Training Courses).

Is there anything in RUP that you would change in order to improve the efficiency of the system development process?

cadams5 — Thu, 20 Sep 2007 23:22:00 GMT

[Be the first to post an answer to this question!]

What is the difference between a business use case and a system use case?

cadams5 — Thu, 20 Sep 2007 23:20:00 GMT

A business use case describes the interaction between an actor and a business process with no mention of systems. When writing a business use case, it is irrelevant whether the business process being described is completed by the actor manually or by interfacing with a system. The focus is on the business process and how the actor interacts with it.

A system use case describes the interaction between an actor and an IT system.

In RUP business modeling, what is the difference between a Business Actor and a Worker?

cadams5 — Thu, 20 Sep 2007 23:17:00 GMT

A business actor is someone external to the business. This could be a supplier, a distributor, a customer, etc. A business actor is often described within the context of interacting with a business process.

A worker (also referred to as a business worker) is someone who works within the business. A business worker is also often described within the context of interacting with a business process.

If you are introduced to a new industry, what steps do you take to become familiar with it and understand it?

cadams5 — Thu, 20 Sep 2007 02:43:00 GMT

Creating a business entity model can really help increase the pace at which analysts, or anyone else for that matter, come up to speed in a new business industry. Business entity models document the entities, or things, that a business or business process uses and interacts with in order to accomplish its business activities and goals. Therefore, it is an excellent tool for identifying the scope of the business domain and for providing a framework from which the analyst can continue to build and elaborate to increase their knowledge. It helps the analyst quickly identify not only those things that they know about the business but also those things that they don't know about the business.

What is BPMN?

cadams5 — Thu, 20 Sep 2007 02:37:00 GMT

Answer:
BPMN stands for Business Process Modeling Notation. BPMN is an industry standard that provides businesses with the capability of visualizing and communicating their internal business processes and their external business to business processes in a standard manner. Beyond the obvious use of modeling business processes, BPMN has been created with the key goal of creating a bridge between the business process modeling notation (BPMN) and IT-oriented execution languages that will implement the modeled business processes within a business process management system. This is done by maintaining and supporting a strict internal model that maps the rich set of graphical objects and object attributes of BPMN to executable languages such as the Business Process Execution Language for Webs Services (BPEL4WS) or Business Process Modeling Language (BPML) to support immediate execution of modeled buiness processes.

What is UML?

cadams5 — Thu, 20 Sep 2007 02:27:00 GMT

UML stands for Unified Modeling Language. UML is an industry standards used to assist analysts and programmers with developing scalable, extendable, maintainable, secure, and robust applications. Large systems tend to be very complex and structure is one way of dealing with complexity. UML provides a common language for analysts and programmers throughout the IT industry to organize and structure complex systems in a way that can be understood by everyone involved. It allows IT professionals to specifiy, visualize, and document models of a software system, both structurally and behaviorally.

Name a few of the industry standards, methodologies, or best practices used by business analysts and systems analysts?

cadams5 — Thu, 20 Sep 2007 01:57:00 GMT

-UML

-BPMN

-RUP

What are the most relevant UML diagrams for Systems Analysts?

cadams5 — Thu, 20 Sep 2007 01:49:00 GMT

While opinions may vary based on the role of the Systems Analyst from organization to organization, the following UML diagrams are probably the most predominantly used by Systems Analysts:

-Class Diagram

-Use Case Diagram

-Package Diagram

-Activity Diagram

-Sequence Diagram

-State Machine Diagram

-Communication Diagram

Name and describe the different categories of UML diagrams.

cadams5 — Thu, 20 Sep 2007 01:37:00 GMT

There are 3 categories of UML Diagrams:

Structure Diagrams: Diagrams that model elements of a business domain or system irrespective of time.

Behavior Diagrams: Diagrams that model the functional or behavioral aspects of a system or business process. These diagrams place less emphasis on detailed interactions and focus more on the overall functionality and flow of a business process or system.

Interaction Diagrams: A subset of behavior diagrams, these diagrams place a heavy emphasis on the interactions between object of a business process or system.

What UML diagrams are available to analysts and developers?

cadams5 — Thu, 20 Sep 2007 01:21:00 GMT

UML 2.0 contains 13 different diagrams (up from 9 in the previous versions of UML) that can be grouped into 3 different categories. These categories are:

1. Structure Diagrams

2. Behavior Diagrams

3. Interaction Diagrams

There are 6 Structure Diagrams which include:

-Class Diagram

-Object Diagram

-Component Diagram

-Composite Structure Diagram

-Package Diagram

-Deployment Diagram

There are 3 Behavior Diagrams which include:

-Use Case Diagram

-Activity Diagram

-State Machine Diagram

There are 4 Interaction Diagrams which include:

-Sequence Diagram

-Communication Diagram

-Timing Diagram

-Interaction Overview Diagram

Who uses the output produced by a systems analyst?

cadams5 — Thu, 20 Sep 2007 01:18:00 GMT

-System Users of a New System: The systems analyst may gather requirements, define use cases, and create process flows that describe the functionality of a new system that the system users must read, understand, and approve.

-Programmers: The business analyst may use the gathered requirements, use cases, and create process flows to write functional specifications and sometimes even technical specs that the programmers will use to understand the intent of the new system and ultimately write the code.