ANSWERS TO BUSINESS ANALYST QUESTIONS 1)

2) (1) A Business analyst should be a good communicator. (2) A BA should be a subject matter expert in his requisite domain. (3) A BA should be a successful negotiator as at times when the resources are not in fine picture or development is not getting anywhere, a panic environment is never the inevitable result. BA should be able to make the client understand the hurdles and suggest some feasible and appropriate solutions/business improvement practices to the client 3): The Project Manager is responsible for ensuring that the product is delivered to the customer on time and within budget. The Business Analyst is responsible for ensuring that the product is built according to the requirements and is built correctly. SME A Subject Matter Expert (SME) is a person who is an expert in a particular area. In software engineering environments, the term is used to describe professionals with expertise in the field of application but without technical project knowledge. 4) A use case is used to describe what a system does. A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use

case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous. A use case (or set of use cases) has these characteristics:

Organizes functional requirements Models the goals of system/actor (user) interactions Records paths (called scenarios) from trigger events to goals Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)

Is multi-level, so that one use case can use the functionality of another one. Use cases can be employed during several stages of software development,

such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals. 5): Actor is something or someone that exists outside the system. Actors are things outside the system but interact with it. They may receive or deliver information to the system or do both. An actor is not the person that interacts with the system but the role that he or she plays. An actor is someone or something outside the system that either acts on the system a primary actor or is acted on by the system a secondary actor. An actor may be a person, a device, another system or sub-system, or time. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified. An individual in the real world can be represented by several actors if they have several different roles and goals in regards to a system. These interact with system and do some action on that.

6). Business use cases focus on business operations. They represent specific workflows in the business that achieves business goals. Business processes may involve both manual and automated processes and may take place over an extended period of time. System use cases focus on the software system to be designed. How do actors interact with the software system? The flow of events that we write in a system use-case specification should be sufficiently detailed to be used as the starting point for writing system test scripts. Business use cases are often written in a white-box form. They describe the interactions between people and departments in the organization being modeled. Business use cases are used to describe how the organization works today in the "as is" business model. What new roles and departments do we need to create to provide more value or eliminate business problems? What roles and departments need to disappear? System use cases are almost always written in a black-box form. They describe how actors external to the software system interact with the system being designed. System use cases elaborate the system requirements. The purpose of the system use-case model is to document requirements from a stake holders perspective, not to design how to satisfy the requirements. 7): Few minutes ..

8): Exception flow is the activity in case of the exception thrown. They are the flow of events which will happen in case of the error. Alternate flows are the alternative actions that can be performed. For example in the login page the alternative flow will be checking the existence of the user name entered.

9): An include relationship is to be used when it must be possible to reuse the extracted behavior in different use casesthat is, when the extracted behavior has to be independent of where it is used. Moreover, the base use case is not complete without the extracted behavior; it is therefore dependent on the existence of the included use case. The argument for the extend relationship is the opposite: The base use case is complete without the extension use case; it must therefore be defined independently of the existence of the extension use case. Moreover, the extension use case describes an addition to another use case; it is therefore dependent on that use case (the base use case). 10): Logical relationship link between actors. A specialized actor can relate himself with any use case related with the base use case. Then it can be related with other use cases that are not related with the base use case. Generalization is a relationship between two use cases or two actors. Where A is a generalization of B, it means A describes more general behavior and B a more specific version of that behavior. Example of use case generalization : An example of this would be "make payment" generalizing "make payment by check", "make payment by credit card", "make payment "make payment". 11): Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that show how a use case is to be fulfilled. These are mostly generated after a use case is built. Use cases are useful in capturing and communicating functional
requirements, and as such they play a primary role in product definition. Example of functional requirement: From ATM use case is: "get cash", "get balance. The functional

by gift

certificate" etc... Each of these specializations accomplishes the actions of

requirements describe the system's functionality like:

The system should grant access to the user after he provides username and password; the system should provide access to the following pre-defined reports. Often they are listed under different project specific groups like user access, reporting, user interface, etc. Examples of non functional requirements are Usability, reliability, interoperability, Scalability, Security, cost etc. Examples of non-functional requirements include legal and regulatory requirements, application standards, and quality attributes of the system that relates directly to that particular use case 12): Functional Requirements are documented in the Software Requirement Specification requirements document are / Use Case in Document. the Non Functional document. listed SRS

13): Use Cases are another way to document functional requirements supplemented with a Non functional document. 14): Use cases should be written from the user point of view. How should the system function when using it? So "behind the scenes" specifics like what is stored in the data base or how the system will validate the information, are not included.. That would go in technical specifications. The people signing off on use cases are typically business users and the people using the use cases are typically software developers. 15): I often work through issues of policies, procedures and processes with my customers, and it was interesting to hear the comments on the relationship between policies and rules. If the policies are well-written, the rules pretty much write themselves, and by spending more time on the policy behind the rules, you end up with a better set of rules. Business rules are

requirements that represent constraints on behaviors, rather than behaviors themselves. Examples: All transactions are in U.S. Dollars. Valid operators license is required in order to rent a car. Late-fee is assessed for enrollment after the second week of the semester 16): Describe the main interactions with the system. Focus on the priority use cases and on the basic course. These priority use cases are sequences of events and interactions that contain fundamental information about the system functions. Consider each primary function of the system to: Document decisions made about the actions and sequence, with a granularity (detailed, high level) depending on the nature of the action (e.g., complexity) and stage of life cycle, provide an effective communication vehicle for requirements, serve as a set of instructions for the implementation. Focus on the main interactions in the system. Start with an external user's interactions with the system (e.g., for a bank, start with deposit cash, withdraw cash). Create a narrative that describes what happens as the system responds to the event. 17): Step by step bulleted list. 18): Actors are characterized not by the identity of the user or other, but rather by the role played by the actor. One person can be several different actors in different roles. One actor can be played (at different times) by several different persons. An entire committee could be one actor. An actor need not be a living thing; it could be another subsystem. Actors are not part of the system in question; they supply input to and receive output from, to the system. In other words, actors collectively define the environment of the system.

Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., role) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances. 19): The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not, ask:

What are the goals that the actor will attempt to accomplish with the system? What are the primary tasks that the actor wants the system to perform? Will the actor create, store, change, remove, or read data in the system? Will the actor need to inform the system about sudden external changes? Does the actor need to be informed about certain occurrences, such as unavailability of a network resource, in the system? Will the actor perform a system startup or shutdown? Understanding how the target organization works and how this information system might be incorporated into existing operations gives an idea of system's surroundings. That information may reveal other use case candidates. Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case. The relationship between actors and use cases should be captured, or documented. There are several ways to do this. If you are using a usecase model on the project, you can create use-case diagrams to show how actors and use cases relate to each other.

20):

On an average 4 9 steps are sufficient for a good use case.

21):

Identify system boundaries. Identify actors. Recall: an actor is an entity playing a particular role with respect to the system. Identify use cases themselves. Every use case has at least one actor. A specific actor initiates the use case. The same actor may participate in multiple use cases, as initiator in some and not in events. Identify clarifying scenarios where helpful. Provide additional information. Write in the active voice. Pair responses with the events that invoke them. Identify domain objects that clearly are part of the application context (such as catalog, inventory, fleet (of automobiles). others and create the description including flow of

22): Evaluating the use-case model with respect to some frame of reference, such as business needs, business domain, and so on. However, use cases will never really be complete until well after the project is over because the authors and end users' understanding -- of the system will be refined and will evolve over time. The need is required to focus on whether each use case is sufficiently detailed for development to proceed. The following need to be taken into consideration for a complete use case:

Use-case specifications. The basic flow and the alternative flows are clear and are understandable by the development and test teams, and have received approval from the end users.

Business use-case specifications. The specifications are very clear on when the use case is invoked within the business process. Also, the team has verified that the outcomes are of value to the steps in the business process. In other words, the team has verified the flow of events in the use case against the business processes.

Business entities. All the business entities that will be manipulated by the use case have been detailed, and their attributes and sub categorization have been defined. Subclasses are often used to evaluate the completeness of the flow of events and the business rules. For example, booking would be an entity for booking for a hotel room, but there are different types of bookings: advance; immediate; priority; and so on. These different types should be treated in alternate flows of events, and the business rules must also consider them, by computing room charges under different booking types, for example.

Business rules. The business rules required to support the use case are clear. For example, if there is a use case to make a room booking, there must also be computation rules to determine the room charges.

User experience storyboard. The screens required for user interactions defined by the use case are identified, including fields and navigation paths.

Supplementary

specifications.

It

is

clear

how

supplementary

specifications affect the use-case flow of events. For example, if the use case requires user identification, it must be clear when the identification is requested and what authorization is required. For an audit trail, it has to be clear what needs to be tracked and under what conditions.

23):

Use case: Use case is prepared by BA in the Functional Requirement Specification customer. Test Case: It is prepared by the Test Engineer based on the use cases from FRS to check the functionality of an application thoroughly. (FRS) which is nothing but steps which are given by the

24): Not sure about this answer.. 25): All stakeholders in a project-developers, end users, software managers, customer managers are the audience in use cases. 26) ..

27): The question should be open ended for chances exist for obtaining some information or possibility which a person would have never thought. The question should not give an idea about the supposed answer. (Not sure of this). 28): BA writes a Use Case. Project Manager and a BA review it. 29): With the following check list (Though am not sure of the answer) Is the use case a standalone, discrete task? Is the goal, or measurable value, of the use case clear? Is it clear which actor(s) benefit from the use case? Is the use case written at the essential level, rather than as a specific scenario? Is the use case free of design and implementation details? Are all anticipated alternative courses documented? Are all known exception conditions documented? Are there any common action sequences that could be split into separate use cases?

Is the dialog sequence for each course clearly written, unambiguous, and complete? Is every actor and step in the use case pertinent to performing that task? Is each course defined in the use case feasible? Is each course defined in the use case verifiable? Do the pre- and post-conditions properly frame the use case?

30): One of the things that I try to do always while facilitating use case sessions is that I make sure all the participants get the right definition of consensus. I would never say that "everyone must agree on everything" as it would lead to long discussions rather I say "there is nothing in this that we can't live with" so that way I have a better chance of getting things done quickly. As a facilitator my mission has always been is to get the group through the agenda to the desired results in as an effective and productive of a manner as possible. I have always made a point in the capacity of a leader of the meeting to exert subtle yet firm control over its course. Normally the comments I get from each one present in the JAD sessions is that I am very much apt at getting the group through the entire schedule on time. I was commented in being an attentive listener and a good Catalyst who is always neutral, avoids making judgmental comments and very much capable of directing the discussions in a direction which allows the participants to discover the appropriate answers for themselves 31): Business use-case model, Business entities and domain model , Business rules, User experience model and story boards , Supplementary specifications . (Not sure) 32: The first stage of requirements gathering that I normally do is to design and establish a rough scope of the project, a process often called simply scoping. Occasionally its done as a part of the budgeting process. The objective is to

provide a general framework for how much activity will be necessary to create the solution without delving into the specific algorithms, formulas, and techniques which must be used. Techniques that I normally use to gather and document requirements include UML, process flows, use cases, interview skills, workshop facilitation, and investigation of current state (existing systems and/or processes). This is done to be able to analyze, assemble and evaluate data and to be able to make appropriate and well reasoned recommendations and decisions to support business stakeholders and the project team. Gathering the requirement allows avoiding ambiguity regarding the functionality and objectives of certain requirements, incomplete information and misunderstanding of the needs of the users and conflicting goals by different teams. Avoiding unstable requirements or new requirements being added during the development phase also are a part of this. 33) 34) 35): First week in this case is always advisable to do a diligent amount of work on expectations, existing process, and time lines with the constraints surrounding. Depending on the project timelines, complexity and volume of the project I would present the recommendations for tools to be used and the estimated budget allocation required and also document the comparison of productivity and flexibility with and without tools used. This should help and motivate the project sponsors to take a call on going for tools. 36): Check the organizational hierarchy at the client side; it happens many times, without permission from the department head, end user doesnt entertain any analyst. Trying talking to them in a friendly way and making them realize that whatever they are doing is worth. This is all your

personal traits how you get along with them and make them speak. Initially you'll find them difficult to deal with, praise them for what they are doing, and make them feel that they are doing very important activity. This will definitely help you in sharing good relationship with clients 37): At a project's beginning, the use case must be a complete description of the system's behavior, yet must remain simple enough for customers to grasp. It must also describe the problem domain, the systems requirements, and customer expectations correctly and completely. During the design and analysis phases, the use case requirements model becomes the basis for the identification of analysis and design classes and subsystems. These are created through a process of allocating behaviors to the objects derived from the use case model. During the implementation phase, developers use the design classes and subsystems as the basis for developing the system's code, data, and computational interactions. Finally, during the testing phases, the use case requirements model forms the basis for test cases verifying that the system solution meets the original business needs. 38): Yes, it comes under the category of Data Maintenance use case. Writing one per entity is repetitive. Normally it is easier to write such use cases generically so that they can be applied to multiple entities. 39): Yes (not sure of this answer) 40): No, Use cases should be written from the user point of view. How should the system function when using it? So don't include "behind the scenes" specifics like what is stored in the data base or how the system will validate the information. That would go in tech specs. The people signing off on use cases are typically business users and the people using the use cases are typically software developers.

41): No, I was working as a Business Analyst. 42): The use cases arent written clearly that the customer can understand them. The system boundary is undefined or inconsistent. The use cases are written from the systems (not the actors) point of view. The use cases are written from the systems (not the actors) point of view. The actor names are inconsistent across use cases. The use cases dont correctly separate actors based on functional entitlement. The use-case specifications are too long or confusing. Writing Functional Requirements instead of usage scenario text. Avoiding explicit names for your Boundary Objects. Writing using a perspective other than the user's, or in passive voice. Describing only user interactions; ignoring system responses. Omitting text for alternative courses of action. Focusing on something besides what's "inside" a given use case, such as how you get there (precondition) or what happens afterward (post condition). Spending a month trying to decide whether to use "uses" or "extends

43: PROS: Use cases provide some very clear benefits to the Analysis Phase. One important benefit of use case driven analysis is that it helps manage complexity, since it focuses on one specific usage aspect at a time. Use cases start from the very simple viewpoint that a system is built first and foremost for its users.

Another benefit of use cases is that they provide basic groundwork for the requirements document, user manual and test cases. Use cases also encourage designers to envision outcomes before attempting to specify outcomes, and thereby they help to make requirements more proactive in system development.

CONS:

There are some drawbacks and risks associated with use cases. Use cases eschew description of user motivations and experiences, and do not address usefulness and usability. Although quality issues are often crucial to the success of a software system, there is no systematic way to handle nonfunctional requirements with use cases. Another drawback exists when trying to document interactions between requirements. Use cases look at each requirement separately and do not document the interaction between the requirements. Many developers often avoid use cases because of the time required to prepare a complete set for an application. Depending on the size of the system in question, it can take a significant amount of time to complete a set of use cases. Others scorn the boredom of use cases, with their unnamed actors and dry, generalized events. Finally use cases are criticized for not capturing all the off the wall mishaps and events that can occur.

44): A use case describes a task the user must be able to perform with a software product. Use cases shift requirements discussions from the traditional focus on features and functionality to the perspective of what the user will do with the product. This change in perspective is more

important than whether you draw elaborate use case models. The use case approach helps you avoid missing essential functional requirements or implementing cool functionality that no one uses because it isn't directly related to specific tasks. They can also help you identify exception conditions the system must handle, which sometimes are overlooked in the focus on expected system behaviors. I have found use cases valuable for deriving conceptual system test cases very early in the development process. The test cases almost immediately revealed errors in my functional requirements and analysis models. User representatives can generally describe their business processes and itemize the tasks a new application must let them perform. Skillful facilitation keeps elicitation workshops focused on user tasks, rather than drifting into discussions of functional requirements or detailed user interface design. 45): 46): 47): 48): Use should be readable and should be written in clear cut steps and not in one go. The writer should know when to stop as one needs to know what is sufficient to write a use case as use case is about describing what a system does and not how a system works. There shouldnt be any mismatched goals and description. Too long sentences and complex sentences dont make good use case. Lack of an actor, misuse of tenses and verbs also contribute to a bad use case. For example in the following use case there are unnecessary details in the first part: "Promote to Distribution" use case:

1. The use case starts when a user clicks on the "Promote to Distribution" button to bring up the Promotion screen. 2. The user selects a state from the state drop-down combo-box. 3. The system finds all eligible magazine issues for wholesalers in the selected state and displays them in a list below the state combo-box. 4. The user selects the magazine issues to promote by using CTRL + click to select multiple rows in the list. 5. The user clicks on the Promote button on the bottom of the screen. 6. The system promotes the selected issues and displays a dialog box showing a useful message that the magazine issues have been promoted. Here is a better alternative: 1. The user signals to the system to start the "Promote to Distribution" use-case. 2. The system displays filtering criteria to the user (states of the US and provinces in Canada) 3. The user selects one or more choices from the filtering criteria (one or more states / provinces) and signals the system to promote all eligible magazine issues for all wholesalers matching the filtering criteria. 4. The system validates the user's selections. 5. The system promotes all eligible magazines for wholesalers matching the filtering criteria. 6. The system displays to the user the results of the promotion (success or failure for promotion of each magazine issue and reason for failure). OR: Wrong: 1. Administrator fills in his user name 2. Administrator fills in his telephone number 3. Administrator fills in his email Correct: Administrator fills in his user name, telephone number and email