Business Analyst

UI Specification

A UI specification defines the rules of engagement for a user interacting with a specific page on a website or screen within an application.

Making Case Diaghrams

MS Visio and Rational Rose

Requirements do NOT include

- A requirements document does not explain how a system is built. - A requirements document does not describe the technology used to make a system. - A requirements document does not detail the schedule, plans, costs, or resources required to make the system.

Here are some qualities of effective requirements:

- A requirements document states - what is needed from a system in precise, measurable, and testable terms. - A requirements document details the way a system interacts with the elements around it. - A requirements document uses plain language understandable to soft‑ ware users and engineers alike.

BRD

- Background/History - Scope and Objectives - Regulatory Requirements - Business Level Requirements - Strategic - Tactical (Interoperability) - Operational (Process related mostly) - Stakeholder and User Analysis - User Requirements (the abilities that the users need) - Functional Requirements - Non-functional Level User Requirements - Assumptions/Constraints - Risks and Dependencies - Solution Options - Business Glossary (the nouns and noun-verb phrases of the business) - Reference to Business Rules - Reference to Business Case/Vision - Use Case Models

In creating an effective narrative form for a software requirements document, I use a mix of very specific elements:

- Clear, precise words - Clear, short sentences - Clear, short paragraphs - A strong overall structure that breaks up all the content into short sections with meaningful titles, organized by subject - Lots of diagrams (data flow diagrams, to be specific) showing every process in the system - Structured descriptions of each process - Descriptions of all the important data in the system - Summary material that ties it all together

Requirements document has many secondary purposes:

- It sells a project to senior management and other stakeholders. - It demonstrates that a thorough and well‑considered process has taken place. - It preserves a team's reasoning so that future team members can understand how choices were made. - It provides the basis for functional specifications and acceptance tests. - It can be a starting point for user documentation.

Software that doesn't work can have a large impact on an organization, and it can lead to many problems including:

- Loss of money - this can include losing customers right through to financial penalties for non-compliance to legal requirements - Loss of time - this can be caused by transactions taking a long time to process but can include staff not being able to work due to a fault or failure - Damage to business reputation - if an organization is unable to provide service to their customers due to software problems then the customers will lose confidence or faith in this organization (and probably take their business elsewhere) It is important to test the system to ensure it is 9error free and that it supports the business that depends on it. The later problems are discovered the more costly they are to fix.

Types of Meetings That a BA May Be Asked to Participate In

- Scope initiation: Brainstorm opportuities, risks, features. - Requirements definition. - Problem Log (PLOG) Resolution: Resolve a problem or issue. - Structured walkthrough: Review a project artifact, such as a section of the BRD. - Process modeling, workflow analysis: Analyze the workflow of a business process. - Design reviews: Review external design definitions, screen prototypes, etc. - Business process management: Manage, improve a business process. - Gate review: Review and sign off on deliverables at specified points in the project. - Confirmation of agreements. - Post-implementation review: Assess results of a change.

Software requirements

- Software requirements explain a business problem and the requirements of a software solution in nontechnical language. - Software requirements do not include project management details such as schedule, resources, and cost.

Interview Questions

- What are the major problems you are experiencing? - How often do they occur? - What opportunities are we missing? - What are the costs and benefits of a change? - What are the risks? - Who will be affected by the success or failure of the solution? - Who are the users? - Who is the customer? - Who will sign off on the solution? - What is each stakeholder's interest (an addressed need or opportunity) in the solution? - What new business services or processes will be introduced by this project? - For each identified service or process, what is the expected impact of the change on the business area and on other services and components? Which of the business process participants (business actors and workers) will be direct users of the system? - Which tasks involve the IT system? - What is the best way to group the automated steps into tasks that can be accomplished by one user in one session? - What business services or processes (business use cases) does this user task support? - What business goals does it support?

Pareto Chart

A Pareto chart plots events against their frequency of occurrence.

Waterfall model

1. Requirements specification resulting in the product requirements document 2. Design resulting in the Software architecture 3. Construction (implementation or coding) resulting in the actual software 4. Integration 5. Testing and debugging 6. Installation 7. Maintenance

Gap Analysis

A Gap Analysis is an analysis of the difference between customer needs and an existing system. The BA per-forms a Gap Analysis to determine how much of a customer's needs are not met by the current IT system or an off-the-shelf solution.

Business Analyst

A business analyst (BA) is a liaison between business stakeholders (those requiring a solution) and the solution provider. The solution may or may not involve IT. The BA is expected to discover, analyze, negotiate, represent, verify, and validate the requirements for a solution. Business analysis may be performed by people with job titles such as systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant, among others.

Business Model

A business model is an abstract representation of a business area. The business model describes both the structure of the business as well as the ways its processes are carried out.

Business Object

A business object is something that the business area keeps track of, monitors, or controls. A business object is an occurrence (specific instance) of an entity class.

Business Use Case

A business use case is a business process representing a specific workflow in the business—an interaction that a stakeholder has with the business that achieves a business goal. It may involve both manual and automated processes and may take place over an extended period of time.

Activity diagram

A diagram that depicts behavior using a control and data-flow model. The BA uses activity diagrams to model business processes and user-IT interactions. Activity diagrams (or other workflow diagrams) are recommended for describing the internal workflow of business processes (business use-case realizations) and, as an adjunct to text, in describing user-IT interactions (system use cases) when the flows connect in complex ways.

Data Flow Diagram

A good data flow diagram can show what a system does, what goes in, what comes out, and where it all goes in much less space and with more precision than is possible with text alone. A data flow diagram neatly condenses the work of a system into a series of processes and shows the output, products, or data that result from each process. Because of this focus on processes, inputs, and outputs, data flow diagrams are especially well suited to capturing and communicating requirements. In a data flow diagram, circles represent stages of work or processes, arrows show data moving into or out of processes, parallel lines enclose data stores that show data at rest, and rectangles stand for externals, or sources and receivers of data that are not part of the system being documented. The major occurrences are processes; the results of the process are data flows that trigger the next action. At each stage there are required actions and results that propel the story forward to its conclusion.

Legacy System

A legacy system is a system in the twilight of its life cycle that is developed and hosted on aging technology.

Performance Test

A performance testis a system test that checks the speed of the system, such as how fast it responds (response time) or how many transactions it can process per unit time (through-put). The BA must ensure that performance tests are planned and executed to ensure that performance requirements documented with the non-functional requirements are satisfied by the solution.

Process

A process is a repeatable series of steps used to achieve a result.

Project

A project is an activity with specified objectives, resources, and time frames.

Requirement

A requirement is a capability that a solution must provide or a condition that it must meet. Examples of requirements include the capability to conduct online transactions and the condition that the solution com-ply with a set of regulations. Within a business analysis context, a requirement is differentiated from a specification, in that a requirement describes what is required, whereas a specification defines how it will be satisfied. There are many types of requirements for which the BA is responsible; these may be broadly categorized as high-level business objectives, as well as functional and non-functional requirements.

Software Requirements

A software requirements document explains a business problem and the requirements of a software solution from a user anda business perspective. It is precise and detailed so that engineers can figure out what to build and how to evaluate what they produce. It uses common language that the business users and managers on the project can understand.

User Requirement

A user requirement is one that must be satisfied by an IT solution, written from the perspective of the end user. A recommended practice is to docu-ment user requirements as system use cases

Risk Analysis

The purpose of risk analysis is to analyze exposure to risk in order to support better decision-making and proper management of those risks.

Accessibility

Accessibility requirements describe the ease with which an application, product, or IT Service can be used by a person with special needs.

Actor

An actor is a type of user or an external system that interacts with the system under discussion. The BA uses actors to model user groups and external systems. They are depicted on Role Maps and use-case diagrams.

Audit

An audit is a formal inspection to verify compliance with required standards, guidelines, procedures, and/or outcomes.

Closeout Phase

The purpose of this phase is to manage and coordinate the processes, systems, and functions required for the deployment of a release into production and end project activities.

BA - Responsibility

BAs have responsibility for the following areas: - identifying the tactical options that will address a given situation and will - support the delivery of the business strategy; - defining the tactics that will enable the organisation to achieve its strategy; - supporting the implementation and operation of those tactics; - redefining the tactics after implementation to take account of business changes and to ensure continuing alignment with business objectives.

Difference between BRD and FRD

BRD described what is needed for the product and the FRD described the BRD in full details.

Business Analysis

Business analysisis the discipline concerned with analyzing a business area, its structure, its processes, and its problems, and with representing business needs to solution providers

Low level use case

By dividing a high level use case into several sub use cases then we get what is referred to as a low level use case.

Construction

Complete the analysis and design, code, integrate, and test the soft-ware. (On iterative projects, these activities are performed for each iteration within the phase.) Design and coding appear in all phases, but peak during this phase.

Discovery

Conduct investigation leading to an understanding of the solution's desired behavior. Requirements analysis peaks during this phase but never disappears entirely. During this phase, architectural proof of concepts are also constructed. The main objective of the Discovery phase is to understand the solution's desired behav-iour and baseline the architecture

Stakeholders

Customers - Provide insight into problems with current service offerings. Know what new services or changes are desirable from the perspective of the person paying for the service. Users - Ensure that requirements meet the needs of end users of the IT system. Ensure system supports all user tasks (goals) and workflow requirements and is easy to use. Understand day-to-day problems with current system. High-Level Management - Ensures that business objectives (such as increased capacity, reduced costs, and improved efficiencies) are met and that management control, tracking, and reporting requirements are included. Internal Users - Ensures that solution improves line operations for internal users; concerned with increasing efficiency, performance, throughput, turnaround, and so on of users under their control. Product Champion - Has broad vision for the change. An agent of change, motivator. Service Desk Agents - Have first-hand knowledge of customer complaints, interruptions of service, and other problems with current system. Have own requirements whenever a change occurs: new procedures, training, and so on. Executive Sponsor - Point of escalation for resolving conflicts that arise as service design progresses. Early and continuing involvement of sponsors and the steering group (approval boards) promotes buy-in. Business Process Owners - Understand problems and issues with current business process. Ensure that IT changes are consistent with the end-to-end business process. Ensure that the proposed process is fit for purpose. Ensure continual improvement of the process and its metrics. Service Owners - An executive position with hiring and firing authority. Ensures that business objectives (financial, etc.) for the service are addressed and realized. Service Manager - Ensures tactical, operational needs for the service are met. Responsible for continual service improvement and for evaluating emerging needs of customers. Service Level Manager - Ensures that Service Level Agreements (SLAs) are defined, agreed on, and met. Works with customers and suppliers of services.

Data Store

Data store: A data store is data at rest. Examples include a table in a database, a report, the volatile memory of a computer, or even a person's memory. A data store must have a name and requires either an input or an output.

Business Analysis Planning

Describes how to determine which activities are necessary in order to complete a business analysis effort, including identification of stakeholders, selection of business analysis techniques,and approaches, including requirements management and monitoring techniques and soft- ware tools.

Enterprise Analysis

Describes how to translate a business need into a change that can feasibly be implemented by the business. Covers problem definition and analysis, business case development, feasibility studies, and the definition of a solution scope.

Initiation

Make the business case for the project. Work also begins on the user experience and on architectural proof of concepts. The objectives of the Initiation phase are to develop the business case for the project, establish project and product scope, and to explore solutions, including the preliminary architecture. (The prototyping effort during Initiation should be risk-driven and limited to gaining confidence that a solution is possible.) The BA assists the project manager by identifying stakeholders, business services and processes, and IT services impacted by the project. By the end of this phase, key functionality is identified—such as key user tasks and IT services.

SDLC Phase

During the Plan stage, annual planning occurs; criteria for defining, categorizing, and prioritizing a project are developed; and projects are approved. During the Initiate stage, a business project is begun. During Execute, the proposed changes are realized. During Transition, the solution is made operational. At some point during or after this time, Post-Implementation Review. As the project closes, Early Life Support occurs—a period of time during which a team is on standby should problems occur, after which the internal IT team signs off on the changes.

External

Externals: An external is a source of or destination for data that is not in the scope of the current work. It is also sometimes called a terminator. An external must have a name and requires either an input or an output.

Financial Info on BRD?

Financial information would not be imbedded in BRD -> it would though include success criteria

Questions To Ask

How requirements questions How will you use this feature? Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps? How might we meet this business need? How might we think about this feature a bit differently? How will we know this is complete? Where requirements questions Where does the process start? Where would the user access this feature? Where would the user be located physically when using this feature? Where would the results be visible? When requirements questions When will this feature be used? When do you need to know about...? When will the feature fail? When will we be ready to start? Who requirements questions Who will use this feature? Who will deliver the inputs for the feature? Who will receive the outputs of the feature? Who will learn about the results of someone using this feature? Who can I ask to learn more about this? What requirements questions What do I know about this feature? Or, what assumptions am I making about this feature that I need to confirm? What does this feature need to do? What is the end result of doing this? What are the pieces of this feature? What needs to happen next? What must happen before? What if....? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true. What needs to be tracked?

Simple Questions to Ask

If we did XYZ, what would happen? What benefit does XYZ have? What would change once XYZ is in place? How does XYZ change things? Why should I care about XYZ? What's your goal? (or, the goal) How would XYZ impact you? (good technique to shift the conversation to a non-participant) What else do we need to think about if we do XYZ? Let's talk about what problem we might be trying to solve here. (yea, it's often necessary to re-iterate, just re-phrase if you can!) How would your day-to-day work change if we did this?

How to Start Exploring the System

If you are dealing with a consumer-facing application, such as a website, you'll want to start as any consumer would. Think of a goal the website should help you fulfill and start navigating to achieve it. If you are dealing with an internal tool, check around for training materials or business process documentation to gauge how a business user might use the tool. If no documentation can be found and you are exploring a new business domain, you might want to engage one stakeholder in a brief demo or invite yourself to some training of new hires. Taking an hour of someone's time in this situation will get you leaps and bounds ahead and make your exploration of the system much more fruitful.

Business Analysis - What They Actually Do

In business analysis, you do not actually perform the activities to build the solution, nor do you actually manage the process to build the solution or test the solution. Instead, you identify the activities that enable the company (with your expert help, of course) to define the business problem or opportunity, define what the solution looks like, and define how it should behave in the end. As the BA, you lay out the plans for the process ahead.

Software Development Cycle

Initiation, Discovery, Construction, Final, and Closeout

Wrap Up Questions

Is there any other way to accomplish this? Does this feature meet the business need and solve the problem we're trying to solve?

Agile

Manifesto for Agile Software Development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan

Net Present Value (NPV)

Net Present Value is the value of an item, expressed in today's currency.

Final V&V

Perform final testing before the product or service is transitioned into production. (While final testing occurs in this phase, testing activities may occur throughout the SDLC, for example, before design or as a replacement for it.

Plan-Do-Check-Act

Plan-Do-Check-Act is a guideline for managing a process. On an IT project, it involves planning for the change, executing it, verifying whether the change met its objectives, and plan-ning and implementing corrective action based on the results. On an iterative incremental project, a Plan-Do-Check-Act cycle is executed for each iteration.

Business Service

mean a Service that is delivered to Business Customers by Business Units, for example, delivery of financial services to Customers of a bank, or goods to the Customers of a retail store.

Prerequisites for BRD

Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC project. The BRD provides the opportunity to review the project charter to ensure that the objective, goals, scope, project team, and approvers are accurately reflected. Prerequisite four is the target environment assessment, created in the measure phase, and includes a detailed process map of the target environment including level two functions. When distinguishing between level two or three functions, group the process functions into the following categories: People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)] Systems: Systems is processing information and making decisions. Systems/people: System is processing information and people are making the decisions. Distinguish between employee and customer. Distinguish leadership requirement for associate in case decision making authority has to be moved up. The BRD appendix can be used to list a number of project details - constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project.

More Stakeholders

Product Manager - Provides input regarding the impact on the business if the proposed changes are made or not made. Provides insight regarding the impact of the change on existing services. Defines the overall risk profile and costs across lines of service. Business Relationship Manager - Provides a consolidated view of costs and risks across customers and contracts. Provides insight into how proposed changes will impact other services currently supplied to customers. Change Manager - Responsible for a final step in the approval process— ensuring that the Change Management process is followed. Primarily concerned with protecting the production environment and ensuring that the change does no harm (i.e., that change-related incidents are minimized). Reviews a checklist of items to ensure that the sponsor has agreed to the changes, that funding is available, and that resources have been allocated. Project Manager - Ensures that requirements are within scope of project and well-managed and that the System Development Life Cycle (SDLC) is being properly followed. SME - Provide deep knowledge in their area of expertise (business, technical, or other). Business Architects - Ensure that business standards, guidelines, and so on are being followed and that the changes are consistent with the business model. Standards - Representatives of (or experts in) standards and guidelines that constrain the project. Internal Solution Providers Provide a reality check to ensure that the requirements and requested warranties are realistic and that the requirements are of sufficient quality to be used for design and coding purposes. Supplier Manager - Ensures that all contracts with suppliers support the needs of the business and that all suppliers meet their contractual commitments. Ensures that suppliers have acceptable plans for responding to failures of their components. Testers - Ensure that requirements are testable. Report on test plans and results. Maintenance Programmers - Have first-hand knowledge of bugs in current system. Ensure that the changes will be maintainable in the future (proper documentation, standards followed, and so on).

Business Analyst vs Project Manager

Project managers are responsible for delivering the solution to a problem. Business analysts are responsible for discovering the problem and determining the solution.

Regression Testing

Regression testing is retesting to ensure that items that were not sup-posed to have changed remain unaffected by the solution.

Requirements must be signed off

Requirements may be signed off iteratively, as they are developed On waterfall projects, the following items are baselined and finalized; on iterative projects, requirements are subject to change at any time as long as they are not being implemented. Are the requirements complete, correct, realistic, testable, and within scope?

Risk

Risk is something that is unknown or uncertain that may impact the success or failure of a project

Sequence Diagram

Sequence diagram is used to tell an object's interactions with one another being arranged in a timed sequence. A sequence diagram is often used by developers and tests as it allows them to understand the system better.

Business Continuity Plan

The Business Continuity Plan defines the circumstances and process for activating a contingency when a disruption occurs to business operations and the process for restoring the service. The BA is responsible for eliciting and documenting business continuity requirements that are input to the Business Continuity Plan. Business continuity requirements are a component of the Business Service Level Requirements.

Business Requirement Document

The Business Requirements Documentis the consolidated documentation of all of the requirements (capabilities that a solution must provide or conditions that it must meet) that stem from the business.

Product Owner

The Product Owner represents the stakeholders and is the voice of the customer. He is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog.

Project Scope

The Project scope are the activities and deliverables that need to be performed/delivered during the project life cycle. The product scope is to be measured against the product requirements, while the project scope should be measured against the project plan. The Project Scope includes all the work needed to be done to create a product, or deliver a service, or result. The Project Scope includes all the work needed to be done to create a product, or deliver a service, or result. The Project Scope is all about the project, it defines the requirements of products, the work required to create the product, and defines what is in the scope and what not. The Product Scope is the characteristics, features, or function of the product, service, or result. It is the outcome of the project. The Product Scope is all about the product: how will it look like, how will it function, etc.

UML Model

The UML is a standard notation for the specification, visualization, and modeling of the structure and behaviour of business and software systems.

Architecture

The architecture is the repository for across-the-board knowledge about a system, including its structure, stan- dards, templates, and process models. The term architecture may be applied to any type of system or part thereof, such as a business, an IT system, or a service. The BA contributes business process models and static (structural) models to the architecture.

Business Architecture

The business architecture is a repository for knowledge about a business, including its processes and supporting organizational structure. Business architecture also contains a set of business goals and a roadmap for the evolution of the business.

Functional Specification Document (FSD)

The functional requirements section should describe "what" the system is to accomplish rather than the "how." Develop a prioritized list similar to the following: Business requirements should focus on what the client wants, not how they want it. Once the complete requirements are gathered, the solution should be discussed. There may be more than one type of solution that will meet the resource availability, etc. and will help in estimating the time required to deliver the solution to the client. Then the specifications should be written based on the solution to meet the requirements. This is where the business analyst arrange workshops with different teams involved in the project to discuss the UI design changes, DB changes, architectural changes, etc. These teams will comprise of developers, QA, DB, data security, etc.

UAT Testing

The goal of User Acceptance Testing is to assess if the system can support day-to-day business and user scenarios and ensure the system is sufficient and correct for business usage. UAT tests are created to verify the system's behavior is consistent with the requirements. These tests will reveal defects within the system. The work associated with UAT begins after requirements arewritten and continues through the final stage of testing before the client/user accepts the new system.

Business Requirement Document (BRD)

The most common objectives of the BRD are: - To gain agreement with stakeholders - To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer's and business' needs - To provide input into the next phase for this project - To describe what not how the customer/business needs will be met by the solution The BRD is important because it is the foundation for all subsequent project deliverables, describing what inputs and outputs are associated with each process function. The BRD distinguishes between the business solution and the technical solution. When examining the business solution the BRD should answer the question, "What does the business want to do?" For example, the business wants to serve 100 bottles of red wine each night during a three-day conference and the wine must be 57 degrees Fahrenheit when poured. The technical solution should support the business solution. For example, the company would need a wine grotto or refrigeration storage unit capable of holding 300+ bottles operating between 48 and 52 degrees Fahrenheit.

Analysis

The purpose of analysisis to create an abstract representation of the business area under discussion. The representation should be valid regardless of the technology used. In waterfall approaches to software development, analysis occurs in the early part of a project; with agile and other iterative approaches, it may occur throughout the life cycle.

Good Software Description

The system shall be able to import market data for commodity options supplied by MarcitData to the Transaction Management System for pricing of all commodity options transactions with less than 10 seconds latency to the market (see Appendix L for a MarcitData Commodity Options feed specification).

Waterfall Project

The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

Different Diagrams

There are a number of diagrams used by business analysts including entity relationship diagram, data flow diagram, class diagram, activity diagram, state chart diagram, collaboration diagram, component diagrams, use case diagram, and deployment diagrams. Another business analyst interview question may ask you to define the three different types of diagrams used most often by all business analysts. The three are use case, activity, and sequence diagrams.

Total Cost of Ownership

Total Cost of Ownership is the full cost of an item over its entire lifespan. TCO includes the initial investment, maintenance, and overhead costs.

Total Cost of Utilization

Total Cost of Utilization is the total cost to the customer of using a service during the entire period it is used.

Best Practices for a BRD

Validate scope: review and refine the scope as needed based on a process detail table, identifying any changes to what is in or out of scope now that the requirements have been developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after this phase will be handled through a change control process. Create systems impacted document: Create a design-elements diagram for each level two or three process function for impact assessment for: - People - Process - Technology - Materials and supplies - Facilities - Product - Machinery and equipment - Others as necessary (depending on the organization) Definitions and acronyms: Define any terms not clearly understood by all.

Getting things signed off the BRD

When the BRD is complete, you will have a sign off list of people who will read and validate the document. Usually this list includes the project sponsor, the steering committee, the IT Lead, the project manager and the business lead.

Sample questions for the current environment assessment and systems overview:

Who is the intended user? How many users are there? Are they the same type of user or different? What level of computer experience will the users have (or is needed)? What is the required security? Are there hardware constraints - networked or stand-alone? What are the approximate numbers of records required initially plus the anticipated growth? What technical support is necessary and available in-house? What other systems need to integrate/communicate?

Business Requirement Collecting

You create a requirements document to explain what you need to someone capable of meeting the need. The challenge when trying to write a story about what you want software to do is to make it understandable to two groups that communicate in very different ways: the needers of the software and engineers who make it. If both groups do not understand and approve of your story, it will fail.

Logical Data Model

a data motel is capable of telling and showing details about specific data that is physically stored in a database

Swim Lane

a visual element used in process flow diagrams, or flowcharts, that visually distinguishes responsibilities for sub-processes of a business process.

Non-functional requirements

anything other than functional requirements.

Functional requirements

denote externally visible behavior that a system must be able to perform and include features and use cases written from the customer, user, and system perspective.

Structured Analysis

explains systems as a series of processes that are represented in "Data Flow Diagrams." Structured Analysis was the primary way to do this work for most of the twentieth century, and in many ways it still is, especially in large organizations like corporations, government, and the military. The teacher never said anything about stories, but one night he said, "Every system is basically the same. It takes data from somewhere, it does something to it, and then it puts it somewhere else." We also learned a simple form of diagram. (See the example of a Yourdon DeMarco data flow diagram earlier in this chapter.) These diagrams showed data moving between what he called "processes." Each process was an action that changed data (not a thing). The lights went on.

Benchmark

is a record of something at a given moment in time.

Template

is a standardized form used for textual documentation.

Black Box Test

is a test that can be designed without knowledge of the inner workings of the system.

Description

is something that tells you what something is like; it is the actual documentation and may be in the form of text and/or diagrams.

SDD - System Design Document

it is a middle step dividing business users and developers.

Business Requirements

refers to a capability that a solution must provide (such as the capability to conduct online transactions) or a condition that it must meet (such as compliance with a set of regulations).

Business Analyst vs Systems Analyst

systems analyst refers to a role distinct from the business analyst; the business analyst analyzes the business, whereas the systems analyst designs the software solution.

Product Scope

the product scope is what the product should or should not be, or do, once completed.

High Level Use Case Diagram

this is broad view of any business process

Winrunner

used for regression testing

Load Runner

used for testing the performance of your business