Business Analyst Community & Resources | Modern Analyst

How do you influence people when you don’t have decision making authority?

cadams5 — Sun, 08 Aug 2010 22:25:00 GMT

Few business analysts have the final authority to make critical decisions on projects. That’s why it’s so important for business analysts to polish their influencing skills.

The process used to influence people can be a formal, well thought out presentation, or it can be an informal conversation. Either way, it never hurts to think through a standard framework by which to structure your thoughts before attempting to influence someone. The following is a concise 5-step framework that can be used for both formal and informal communications that involve influencing another person or audience.

Define the What, Why, and Who
Prepare your case
Deliver your message
Obtain a commitment
Agree to a specific action plan

These 5 steps provide a framework to structure and plan your communication to maximize your influence over a person or audience, but it’s the details of each step that will determine how influential you will be.

1. Define the What, Why, and Who.

It’s important for you to have a well define and thoroughly understood objective. What is your goal or objective? Why are you championing your particular position? Who do you need to influence? Answering these questions will focus your case.

2. Prepare your case.

Notice that I didn’t say “prepare your argument”. Influencing is very different from coercion or even selling. While there may be some selling involved, it should be a soft sell of the benefits that you are espousing.

Consider how you can customize your case for the person or audience. What does the person or audience value? What do you have to offer the person or audience? Do you have specific technical knowledge? Do you have a strong network which could benefit the person or audience?

For more formal communications, while you are preparing your case you should outline a number of potential options for the action plan that might be used if you get the person or audience to commit.

3. Deliver your message.

When delivering your message be direct in your thoughts and language. You want to come across as respectful and open to the feedback of the audience, but do so without obscuring the point of your message. Don’t hint at what you want, but also don’t demand.

Use powerful questions to engage your audience. Open-ended questions that lead the audience to realize the advantages of your case work best.

4. Obtain a commitment.

Whenever possible, it is best to obtain a commitment immediately following the delivery of the message while the benefits of your case are still fresh in the audience’s mind. Steer the conversation to help your audience arrive at the stage where they are comfortable committing.

5. Agree to a specific action plan.

Even with a commitment, you are only truly successful once you’ve realized your objective. That’s why agreeing to an action plan is so important.

Develop milestones for reaching the final objective
Identify resources and assign roles and responsibilities
Develop a method for tracking progress

To re-iterate, if you are planning a formal communication or presentation you will have a lot more time to spend thinking through the details of this 5-step process. However, even for brief communications within a short conference call, mentally thinking through these steps for just a few second can help guide your conversation and increase your degree of influence with your audience.

How would you assess your value as a business analyst?

cadams5 — Sun, 08 Aug 2010 22:18:00 GMT

This question is not intended to determine how much you are looking to make. If an interviewer asks you a question like this, they are likely looking for answers to a number of other unspoken questions such as:

Do you understand the real value a business analyst brings to an organization?

Do you ever think about the cost associated with employing you as a business analyst?

Do you have the skillset required to be a marketable business analyst?

Are your expectations of the value of a business analyst realistic?

Companies don’t hire business analysts for fun; they hire them to save money. It’s that simple. So how does a business analyst save an organization money? You might mention a few examples such as:

Make a process more efficient saving the company time and resources (which translates as money)
Drive out the real requirements of a system, instead of a half-baked solution, ultimately reducing the amount of rework and re-development required to develop a system that delivers the intended value (rework means lost money)
Identify opportunities for increased customer satisfaction leading to greater customer retention and greater new customer conversions (more money)

If you have quantifiable examples of work that you have produced in the past and know precisely how much your work saved a company (not the work of the entire team, but YOUR actual contributions) this information can be very powerful. This is your true value as an analyst within a similar organization and role. But few people have the information required to make this kind of assessment. In addition, the value you bring to an organization is very different from your “potential value”. If an organization has you writing specs for a system, your opportunity to bring value may be much lower than if you are re-engineering a multi-million dollar business process to eliminate hundreds of thousands or even millions of dollars of waste.

This line of reasoning leads us to the question “Do you have the skillset required to be a marketable business analyst”? You may have expert knowledge of traditional SDLCs and be able to create complex analysis diagrams, but if the organizations that are hiring all require you to work in an Agile environment then what value can you bring them? Even though your potential value for some organizations may be quite high, your value to others that use a different range of skills may be quite low. This example shows how your value is dependent upon the industry environment and the tools, competencies, and methodologies that are popular at that time. It also shows the need to keep your skillset current and then stress those skills that are most relevant to the interviewing organization.

If you can talk through these concepts with an interviewer, then you will have demonstrated that you don’t take you value as a business analyst for granted and that you are the type of person that will maximize your value within the organization that hires you.

How do you handle stress and pressure?

cadams5 — Sun, 08 Aug 2010 22:09:00 GMT

A nice, brief response to this question may sound like this: I handle stress well. I’m the type of person that mitigates stress rather than folding under it. I thrive on challenge and I’m used to working in a goal oriented environment with demanding deadlines.

But if you just leave it at that, your answer will sound canned and won’t be very believable. Expand on how you feel about stress and specific action you take to deal with it.

Stress and pressure in small quantities can be a motivator and allow us to operate at peak performance. However, in too large of quantities it causes anxiety, frustration, fatigue, and a host of other bad things that ultimately are counterproductive to achieving our goals and objectives. So it’s important to manage stress and to find the right balance that works for you.

When you do feel stress coming on and rising to levels which are counterproductive, you must first identify that the stress is there. This can be harder to do than it sounds, since when we are in a stressed state are brains aren’t usually in control of the situation. So how can you train yourself to do this?

Stress and pressure typically arise from a number of common root causes. Understanding these causes ahead of time can help us be able to quickly identify the stress and take appropriate action to manage the stress and bring it back down to reasonable levels. Here are some of the more common causes of stress and how you might deal with them.

1. Too much work/overburdened.

Feeling overburdened creates stress, but for most people this can be overcome by doing two specific things.

First, create a prioritized to-do list where you track every task along with progress notes detailing what has been completed for each task and what remains. The key is to track the information so that you don’t have to remember and so that you don’t worry over forgetting something important. If the list is too long, don’t stress, that’s what the second step is for.

Second, if time required to complete the tasks is too great, talk to your manager immediately. Review the tasks with him or her and talk about realistic expectations.

2. Lacking direction.

If you feel as if you don’t understand the direction you need to take on a task, raise it to your manager. Ask him or her to explain their vision for the outcome of the task. It could be that your manager doesn’t have a clear vision of what the results should look like, but they probably know what requirements or problem the outcome should solve. Explain to your manager that you would like to make an attempt at a solid start and then schedule periodic reviews together to review the progress that you’ve made. This gives them the opportunity to provide guidance and redirect your efforts if they feel you are going in the wrong direction. Remember that your manager probably wouldn’t have given you a task with such an undefined vision if he or she didn’t have a great deal of confidence in your abilities.

3. Lacking knowledge or experience.

Lacking the experience needed to perform a task certainly isn’t a confidence builder, but it’s important to remember that lack of knowledge or experience isn’t a weakness. Everybody is always learning, and no one person has all of the answers. If it’s information you lack, the key to reducing stress in this situation is taking a structured and well thought out approach to acquiring the information you need. If it’s experience with a specific skill set then it’s not out of line to discuss training options with your manager.

Ultimately, remembering that nobody is expected to know or have experience with everything is key to keeping stress levels in line.

You can’t completely avoid stressful situations, but one overarching approach that has always worked for me is approaching every challenging situation more like a strategic, thoughtful game of chess. Identify the challenges in front of you, evaluate multiple options for proceeding in the most efficient manner possible, and then act.

What is the Scrum method?

cadams5 — Sun, 11 Jul 2010 20:23:00 GMT

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the development of information systems. The Scrum method brings a small team together to work on a specified set of features over a period of 30-days (called a sprint).

Both the term Scrum and sprint are borrowed from the sport Rugby. A scrum is where the two teams are engaged in a huddled to begin play following a period where play has been stopped. The fast moving period of play from the point of the scrum until play ends again is called a sprint.

The Scrum method starts each 30-day sprint with a kickoff meeting (a period where the entire team comes together). The kickoff meeting lasts a full day and the features of the system to be developed are discussed. The outcome of the kickoff meeting is a set of features that will be developed over the 30-day sprint along with estimates of how long the analysis and development of each feature will take.

In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested, Refactored, and Documented. If this life-cycle is not fully accomplished during the 30-day sprint, perhaps due to an initial underestimation of the time required, the feature will be pushed to a later sprint.

Following the kickoff meeting, and throughout the duration of the 30-day sprint, each day is started with a short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up meeting). The purpose of this meeting is for the team to discuss what they accomplished the day before, what they will accomplish over the coming day, and to raise any obstacles that they have encountered that may impede progress.

One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size. Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.

Product Owner – identifies the features that will be included in the next 30-sprint and set the priority of each. This is typically a high-level stakeholder in organizations where a true Product Manger/Product Owner role doesn’t exist.
Scrum Master – acts much like the project manager. While the Scrum Master does not micro-manage the teams deliverables, this person ensures that the 30-day sprint is on track and enforces the key rules that guide Scrum such as; no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.
Team Member – unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

What is a Context Diagram and what are the benefits of creating one?

cadams5 — Sun, 11 Jul 2010 19:55:00 GMT

The Context Diagram shows the system under consideration as a single high-level process and then shows the relationship that the system has with other external entities (systems, organizational groups, external data stores, etc.).

Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a specialized version of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be helpful.

A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an information system. DFDs are one of the three essential components of the structured-systems analysis and design method (SSADM). A DFD is process centric and depicts 4 main components.

Processes (circle)
External Entities (rectangle)
Data Stores (two horizontal, parallel lines or sometimes and ellipse)
Data Flows (curved or straight line with arrowhead indicating flow direction)

Each DFD may show a number of processes with data flowing into and out of each process. If there is a need to show more detail within a particular process, the process is decomposed into a number of smaller processes in a lower level DFD. In this way, the Content Diagram or Context-Level DFD is labeled a “Level-0 DFD” while the next level of decomposition is labeled a “Level-1 DFD”, the next is labeled a “Level-2 DFD”, and so on.

Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But like many analysis tools they have been leveraged for other purposes. For example, they can also be leveraged to capture and communicate the interactions and flow of data between business processes. So, they don’t have to be restricted to systems analysis.

A sample Context Diagram is shown here.

A Context Diagram (and a DFD for that matter) provides no information about the timing, sequencing, or synchronization of processes such as which processes occur in sequence or in parallel. Therefore it should not be confused with a flowchart or process flow which can show these things.

Some of the benefits of a Context Diagram are:

Shows the scope and boundaries of a system at a glance including the other systems that interface with it
No technical knowledge is assumed or required to understand the diagram
Easy to draw and amend due to its limited notation
Easy to expand by adding different levels of DFDs
Can benefit a wide audience including stakeholders, business analyst, data analysts, developers

What approach should be taken when creating a Context Diagram? Top down? Bottom up?

cadams5 — Sun, 11 Jul 2010 19:44:00 GMT

A number of factors should be considered when deciding what approach to use (top down or bottom up) to create a Context Diagram. First let’s be clear about what each approach means.

The top-down approach: this approach refers to starting directly with the Context Diagram and creating it from scratch. This is done by placing the system under consideration in the center and then identifying each of its interactions based on either the analyst’s current knowledge or by asking others who may have the knowledge.

The bottom-up approach: this approach refers to starting with a lower level data-flow diagram, identifying known processes and the data that flows between them, and then following the data trail to uncover other unknown processes. After the lower-level data-flow diagram is completed, the processes can be rolled up to the system level.

The top-down approach is a more direct approach and is often the direction many analysts choose to take (whether right or wrong for their particular situation). It can work well under some circumstances, particularly if the system under consideration has only a few interactions with external entities or if the same analysts support the application on an ongoing basis and are very familiar with all of the possible interactions and dependencies that the system has. But if the system has a very large number of interactions and dependencies or if the analyst is unfamiliar with the system then this approach can be difficult. The less informed analyst would need to rely on a very iterative approach where the context diagram is evolved over time by reviewing it with a number of subject matter experts that understand pieces of the environment.

The bottom-up approach is a less direct method, but can be exceptionally valuable as an investigative technique. Starting with a lower-level data flow diagram allows the analyst to document the bits and pieces of the system that are understood and then follow the data to identify the various system interactions and dependencies that exist. This tends to be a more natural approach as it uses the power of the technique to document the entire scope of the system and its surrounding environment. In the top-down approach it can be difficult to know when the analyst has reached completion since it’s hard to know that which you don’t know. In the bottom-up approach the data-flow diagramming technique itself drives the analyst to a state of completion.

Describe what is meant by Agile.

cadams5 — Sat, 05 Jun 2010 23:22:00 GMT

Agile is a general term and conceptual framework used to describe a number of “light-weight” methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD), which exhibit a series of common characteristics. Some of these characteristics include:

Iterative analysis and development
Time-boxed iterations of a predefined length
Delivery of the most critical features and functions first
Delivery of a complete build with an initial set of limited features within a few months (often 1-2 months)
Small cross-functional teams usually of 6-9 team members.
Daily team communication meetings
Reduced levels of documentation

Most Agile methods begin with a prioritized feature list where features are group together into deliverable chunks and assigned to a particular iteration in which they will be developed and delivered. Using small teams and daily communication among all team members the Agile team can achieve a high level of efficiency.

Agile methods are intended to overcome or circumvent many of the recurring challenges that are encountered during software development projects. The iterative nature of these methods, along with the desire to deliver smaller sets of defined features per iteration, help mitigate risk due to evolving requirements, unclear project stakeholder direction, and unforeseen project complexities that typically arise during the latter stages of analysis and development. Some of the most salient advantages of Agile methods include:

Availability of working software much sooner which allows for more immediate feedback from application users.
More immediate, and therefore larger, Return on Investment from software features that are developed in short iterations and release to production immediately.
Less project overhead due to smaller team sizes.
Avoidance of large schedule overruns.
Avoidance of large budget overruns.

What is a logical data dictionary and what are the benefits of maintaining one?

cadams5 — Sat, 05 Jun 2010 23:19:00 GMT

A data dictionary, also commonly called a metadata repository, is a centralized repository of data elements and other metadata about them. This may include the meaning of a piece of data, relationships to other data, origin, usage, type and length.

While the term metadata repository and data dictionary are often used interchangeably, many organizations will define separate data dictionaries within a single metadata repository since the data can be described in a number of forms. The first major differentiation in the way that data can be defined is logically versus physically.

A logical data dictionary allows an organization to describe data in terms that business representatives can more easily understand. It focuses on the meaning of the data and its relationships to other data. Logical data also usually models the real world far more closely that physical data. The business may have something that they refer to as a Sales Contract. This logical entity is of importance to the business. The Sales Contract business entity, in order to be completely defined, is made up of or has a relationship to other data such as Contract Participants, Contract ID, Contract Expiration Date, etc. How this data is structured in a physical data model or database is of no consequence to the business representative. At a logical level, the business representative cares about questions such as:

What is a Sales Contract?
What are the primary elements of a Sales Contract?
Do these primary elements have attributes or data of their own?
How does a Sales Contract relate to other relevant business entities?

Once data has been logically defined, the definition and relationships between various pieces of logical data rarely need to change.

In contrast, a physical data dictionary allows an organization to describe data in terms of its physical data structure, type, format, and length. Physical data dictionaries provide programmers of many different systems with a tool to understand how and where the data is stored and how it must be referenced in order to consume it. Physically data can be stored in many different ways in an effort to optimize data integrity and increase the efficiency of data retrieval and data updates.

Since data is often stored in a number of physical ways, more than one physical data dictionary can be defined. While a standard piece of data may be defined in terms of a common XML Schema structure that is used by many different systems throughout the organization, it can also be defined in terms of a physical database structure that is specific to a single system.

Both logical and physical data dictionaries can be mapped together within a central metadata repository to provide traceability from one data element to another whether it’s a physical or logical representation of that data. Once the physical and logical data dictionaries are mapped together the logical data elements and their descriptions provide a single, easy to understand view of the data used by the business and its systems.

Finally, a logical data dictionary provides the added benefit of constancy since it changes infrequently. As systems and technologies change, physical data structures do as well. But the logical data dictionary remains relatively unchanged over time as it reflects relatively unchanging business concepts.

How is the Solution Assessment and Validation knowledge area of the BABOK v2.0 defined?

cadams5 — Sat, 05 Jun 2010 23:15:00 GMT

The purpose of the Solution Assessment and Validation knowledge area is to determine how closely a solution meets the original stakeholder and solution requirements as well as describe the activities that the business analyst should complete to ensure the successful implementation of solution. These activities and tasks can be performed by the business analyst regardless of the type of solution being implemented including a new or revised business process, organizational structure, outsourcing agreement, software application, etc.

The tasks involved in solution assessment and validation can be performed on a single solution or be used to compare several solutions for the one which will best satisfy stakeholder and solution requirements while minimize implementation risk. Additionally, the business analyst will determine which solution, if any, provides enough business value to justify its implementation.

The tasks involved in the Solution Assessment and Validation knowledge area include:

Assess Proposed Solution
Allocate Requirements
Assess Organizational Readiness
Define Transition Requirements
Validate Solution
Evaluate Solution Performance

How is the Requirements Analysis knowledge area of the BABOK v2.0 defined?

cadams5 — Sun, 09 May 2010 21:54:00 GMT

The Requirements Analysis knowledge area describes activities and methods used to analyze stated requirements and transform them into a potential solution which possesses the capabilities that will fulfill the stakeholder needs. It includes specifying and modeling both stakeholder requirements (requirements which describe WHAT capabilities the solution must have in order to meet the needs of various stakeholder groups) and solution requirements (requirements which describe HOW the solution will meet the needs of stakeholders ).

Requirements analysis also covers developing domain models of the current state of the organization which may be used to validate the scope of the solution with stakeholders, identify opportunities for improvement, or to aid stakeholders in their understanding of the current state during solution review meetings.

The tasks involved in the Requirements Analysis knowledge area include:

Prioritize Requirements
Organize Requirements
Specify and Model Requirements
Define Assumptions and Constraints
Verify Requirements
Validate Requirements

What is an XML Schema and what is its purpose?

cadams5 — Sun, 09 May 2010 21:46:00 GMT

An XML Schema is a document that is itself described using XML and which defines how an XML document must be structured in order to conform to structured required by the a system or service which references the XML Schema. Specifically it defines:

The elements that may appear
The attributes that may appear for each element
Which elements are child elements
The order in which child elements must appear
The number of child elements that may appear
The data types for each element or attribute
Default values and constant value for elements and attributes
Minimum and maximum occurrences of an element

The term DTD (Document Type Definition) is often used when discussing the acceptable form of XML documents. However, XML Schemas are successors to XML DTDs and have a number of benefits over DTDs. Some of these benefits are:

Schemas are written in XML
Schemas may be extended to future additions
Schemas contain a richer set of rules to which data must conform
Schemas make it easier to validate correctness of data
Schemas support data types

XML schemas are able to enforce specific rules and data conformity such as:

Data Types – data conforms to a specific data type (string, date, numeric, boolean, etc)
Value restrictions – data conforms to the acceptable values (enumeration, fractionDigits, length, maxExclusive, maxInclusive, maxLength, minExclusive, minInclusive, minLength, pattern, totalDigits, whitespace, etc)
Element Indicators – elements conform to specific indicators (Order Indicators, Occurance Indicators, and Group Indicators) which apply rules to how many elements must appear, in what order, or adhering to a specific structure (maxOccurs, minOccurs, all, choice, sequence, etc).

Sample XML Schema

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.somesite.com/2010/XMLSchema"
targetNamespace="http://www.somesite.com"
xmlns="http://www.somesite.com"
elementFormDefault="qualified">

<xs:element name="person">
   <xs:complexType>
      <xs:sequence>
         <xs:element name="firstname" type="xs:string" maxLength=”30” />
         <xs:element name="lastname" type="xs:string" maxLength=”30” />
         <xs:element name="middlename" type="xs:string" maxLength=”30” maxOccurs=”2” />
         <xs:element name="age">
             <xs:simpleType>
                <xs:restriction base="xs:integer">
                   <xs:minInclusive value="0"/>
                   <xs:maxInclusive value="120"/>
</xs:restriction>
             </xs:simpleType>
         </xs:element>
       </xs:sequence>
   </xs:complexType>
</xs:element>

</xs:schema>

Sample XML which conforms to Schema

<person>
   <firstname>Joseph</firstname>
   <lastname>Smith</lastname>
   <middlename>Brian</middlename>
   <middlename>James</middlename>
   <age>56</age>
</person>

What are the similarities and differences between a UML Class Diagram and Object Diagram?

cadams5 — Sun, 09 May 2010 21:37:00 GMT

Class Diagrams and Object Diagrams use almost identical notations. Both represent a static view of a system, however Object Diagrams represent a snapshot in time, whereas Class Diagrams are not time dependent and are an abstract view of the types of objects that may exist within a system, the relationships between them, and how and when one type of object can exist in relationship to another. Since Object Diagrams represent specific object instances that exist at a single point in time, they are sometimes called Instance Diagrams.

A few notable differences in the notation and rules used to represent Class and Object Diagrams are:

Class Diagrams represent each class via a rectangle and display up to 3 types of information; the class name (not underlined), its attributes, and its operations. The Object Diagram also uses a rectangle to represent an object instance, however the object name is underlined and lists the name of the object followed by a colon and then the class name which describes its type (e.g. Joe: Student, where Joe is the name of the object instance and Student is class). Additionally the Object Diagram will list an object's attributes, but it will also list the value of that attribute at that point in time (e.g. SSN = 555-55-5555).
Class Diagrams enforce multiplicity rules between associated classes. For example, a Class Diagram may display an association between a Car and Passengers. The Class Diagram would show a single rectangle to represent the class car and a single rectangle to represent the class passenger, but display multiplicities stating that each car may have 1..4 passengers. An Object Diagram being a snapshot in time would show a rectangle for the Car and up to 4 separate rectangles, one for each passenger that exists at that movement in time.
Many of the constraints or association types that exist in a class diagram have no relevance in an object diagram. Multiplicities in a class diagram may constrain the number of passengers in a car to 4, but this rule would be enforced within the code itself such that a 5th passenger object could never be created. Therefore, multiplicities are not shown within an object diagram. Only the actual numbers of objects that exist at that moment in time are shown. Similarly, other constraints such as "at least one passenger be of type driver" could also be captured and displayed in a class diagram but would not be shown in an object diagram since these rules are enforced within the actual code.

What is Stakeholder Analysis and how does it benefit the business analyst?

cadams5 — Sat, 03 Apr 2010 19:16:00 GMT

Stakeholder Analysis is the process of identifying project stakeholders, how their needs may impact the project, and the contributions that the stakeholders will make to the requirements elicitation process. Projects typically have a large number of stakeholders from many different areas of the organization. Based on each stakeholder’s position and responsibilities, the level of their involvement and their importance to the project will vary.

Stakeholder Analysis is sometimes called a Stakeholder Involvement Plan or a Stakeholder Elicitation Plan. Regardless of the name used, Stakeholder Analysis goes beyond identifying project stakeholders. After all project stakeholders have been identified, it should be determined how involved each stakeholder should be in the requirements elicitation process. The business analyst should document a number of factors for each stakeholder including:

Importance – How important is the stakeholder in the requirements elicitation process? Are they required in order to document all of the critical project requirements, or are they nice to have adding clarity to processes that may further refine requirements? Answering these questions will help ensure that the project will meet its goals and objectives, and that critical requirements aren’t missed.
Influence – How influential is the stakeholder to the project? Even if they aren’t needed for the requirements elicitation, are they in a position of authority? Does the stakeholder have the ability to dramatically alter the course of the project if they hear about and are unhappy with the current direction of the project? Answers to these questions will ensure that the most influential stakeholders are updated on a regular basis with the project status.
Level of Involvement – What level of involvement and how much time will be expected of each stakeholder? Do they need to be fully allocated to the project? Do they need to be in every requirements elicitation session? Can they be involved in only key requirements elicitation sessions? Do they only need to attend a final requirements review session? These questions help ensure that the necessary people are made available to the project for the right amount of time.
Frequency of Involvement – How often will each stakeholder need to be involved; daily, every other day, once per week? This information will help the business analyst plan and schedule the necessary meetings accordingly.
Method of Involvement – What method will be used to involve each stakeholder? Will they receive email-based status reports? Will they be involved in requirements gathering sessions? Will they be asked to sit in one-on-one requirements interviews? This information will aid in development of a communication plan and the appropriate selection of communication techniques.

What is Active Listening and how can it benefit the business analyst?

cadams5 — Sat, 06 Mar 2010 22:39:00 GMT

How is the Requirements Management and Communication knowledge area of the BABOK v2.0 defined?

cadams5 — Sat, 06 Mar 2010 22:34:00 GMT

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.