Business Analysis Guidebook/Requirement Gathering Tools
A variety of tools are used to assist in the requirements gathering process. Each type of tool provides alternative means to illustrate, explain and specify exactly what must be delivered to meet the business goals. They simplify the understanding of requirements by application of the truism ‘a picture is worth a thousand words’. They encompass process documentation, graphical illustrations and detailed specifications to help in eliciting requirements, communicate proposals and decisions, provide details for the development process, and identify missing or incomplete requirements.
This section of the Guidebook uses examples for the many requirements that might be associated with the goal of acquiring a new car. The customer must decide what car to buy, the car dealer needs to be able to provide the car to the customer and the legal compliance requirements applied to ensure that public goals for safety and information are met during the transaction. Each of these players has different needs and constraints that must be satisfied to accomplish the delivery of a new car to the customer. Examples provided below will illustrate the tools that might be used when capturing the requirements for this scenario.
What are the Tools? edit
Tools included in the examples below illustrate many options that are available to a business analyst for use in gathering requirements. During the course of a project, one or more of these tools may be appropriate to use for gathering and/or clarifying/validating the requirements. There are additional modeling tools available which are not covered here, such as data-/task-/work-flow models, application or infrastructure diagrams and activity diagrams. Tools included here are readily understandable by all participant perspectives involved in a project, enhancing communication effectiveness.
Process Models edit
Process models provide a visual representation of a series of tasks, activities or actions directed toward specific goals. They are useful for illustrating a range of complexity, from providing a very high-level view of the overall process to capturing detailed activities for a small piece of the overall process (see images below). These figures are constructed below using the Object Management Group (OMG) Business Process Model and Notation (BPMN) specification, version 2.0.
High-level diagrams identify the context for the low-level process models. Inputs and outputs serve as placeholders for data requirements, indicating important information. Process delays and operational issues can be included in this type of diagram to assist in the identification and assessment activities involved in Business Process Improvement (BPI) initiatives. Whatever level you are capturing a process for, always identify each task or action with a number. Explain, in commonly used terminology, what is encompassed within the shape. This narrative will ensure that everyone involved in the project has a common understanding of what is represented graphically.
High-level Process Model: Simple process outlines what happens when a car is purchased:
Lower Level Process Model: Detailed tasks with inputs/outputs included for Create Offer process:
Use Cases and User Stories edit
A Business Use Case or Business Scenario represents a sequence of events or circumstances that occur to accomplish a business goal. The functional requirements that are needed to accomplish the goal are embedded in the Use Case. The narrative and diagram describe how people/systems interact to achieve the ‘Post Conditions’. They may incorporate only functional needs, without regard to ‘how’ the tasks are accomplished or system specification details may be incorporated into the Basic/Exception/Variation steps or supporting document sections.
The Agile development methodology doesn't generally spend a lot of time producing detailed documentation. The intent is to accelerate the development cycle so that benefits are realized quickly on development investments. Rather than process diagrams, Agile projects generally express the tasks within a process in the form of "User Stories". User Stories are simple statements of atomic-level requirements that document the functions that will be developed during an Agile development methodology Sprint. They include the affected business role, business need or goal and may include the benefit to be realized with the Sprint deliverable. User Stories are expressed in the format:
“As a <role>, I want <goal/desire> [so that <benefit>]”.
For the Insurance Transfer process above, a User Story associated with the receipt of the temporary registration might be:
“As a <salesman>, I want <to automatically receive a new insurance card> [so that <the customer can legally drive their new car off the lot>]”.
Story Boards edit
Storyboards can be used to illustrate steps in a process (see figure at right), providing an effective tool for eliciting requirements and communicating with project stakeholders. They may closely mimic an actual or planned activity, helping to focus participants in a requirements gathering meeting on the specific tasks discussed.
Mockups and Prototypes edit
Mockups and Prototypes display essential features of an application before it is developed. These tools demonstrate what a system will look like, not how it will be developed. The appearance of the images or screen elements may be very close to what is the expected final version, or they may include only the barest framework showing elements (buttons, text fields, etc.) and their behavior.
Mockups can be created by editing a screen shot of an existing application. The screen print can be edited to add objects or remove objects using image-editing software such as SnagIt, MS Paint, Adobe Print Shop or another graphical editing application.
If the Mockup shown above was a prototype, someone viewing the image on a screen would be able to click on the ‘Edit’ tab to open the page in edit mode and click on the navigation links to open the associated pages. A prototype would demonstrate the behavior of the interface without having the full programming behind the scenes. This enhances the clarity of the business interface and functionality requirements, preventing defects as the planned/developing solution is reviewed by stakeholders.
Wireframes are a type of mockup or prototype that show the framework for a web site – what will be displayed, approximate placement, field types and navigation, etc. Generic shapes are used to represent the fields and objects displayed on the proposed web page.
Data Dictionary edit
Data Dictionaries contain information about the data (metadata) that is stored in an application database. This tool helps to explain what the stored information represents and can be used when developing data models for an application.
Generally the dictionary for a database application will include the table names, information regarding what each entity (table) represents, each field name with a definition of what is stored in the field, the formatting for the field, whether the field must be unique, whether the field is required, and any default value for the field.
For an application that is used at the Department of Motor Vehicles to record information about the owners and their cars, a partial data dictionary might look like this:
The Data Dictionary captures what data is needed, the attributes of relevant entities that participate in a process, attribute definitions, and may include Entity-Relationship diagrams (see Section 3-2 Data Modeling/Data Documentation below).
Glossary edit
Each organization has its own acronyms, meaningful terms and specialized application of words to business processes. Creating a glossary of key business terms and definitions for a project will ensure that those involved are all communicating effectively, with a common understanding of what things mean.
A Glossary also links project work to the overall operations of the business. This tool can be useful in understanding high-level business organizational structure as well as identifying possible impacts of project work that are outside of the immediate project scope. When developing brand new solutions, a project Glossary may even be used to capture new terms that will be incorporated into the overall business jargon.
Glossaries for business projects are frequently included as tables in project documents. This allows project document reviewers to refresh their understanding of the meaning of information they may not be involved with on a daily basis.
Business Forms edit
Current business processes and tasks frequently rely on standard forms to collect meaningful information. Each piece of information that can be gathered using a form serves some purpose to the associated process or task. Forms provide a quick way to identify what information is important to the process or task. Exploring the ‘why’ of each of the fields and the relationships that may exist between different sections of a form helps to clearly identify operational requirements for a project.
Using business forms can assist in automation projects (where can this information be re-purposed from?), reengineering projects (why is this information needed and can it be removed given current constraints?) and any other type of project that is affected by where the data comes from, where it goes to, and/or what can be done with its inherent information.
For purposes of registering a new vehicle, the owner information that is required by the New York State Department of Motor Vehicles is found in section 3 of the DMV form MV-82 Vehicle Registration/Title Application
Why Use These Tools? edit
Use one or more of the tools listed above during the requirements gathering phase of a project to capture requirements. They help to accurately capture well-constructed requirements that reflect the actual needs and underlying concerns of the project stakeholders. Diagrams or lists that can be viewed while discussing requirements will facilitate identification of missing data, prevent the need for correction of misunderstandings, illustrate implications of proposed changes and determine specifications for the development phase.
Diagrams and other requirements gathering tools simplify communications with project stakeholders. Graphic images can clearly encapsulate many words, promoting a common understanding of what the requirements are so that they can more easily be validated. Simple illustrations and lists facilitate requirements gathering sessions by focusing the discussion and keeping everyone on the same page. Open questions can clearly be identified for follow-up and design specifications can be captured to ensure completeness.
When using diagrams and lists, requirements relating to inputs and outputs, behavior, data sources, content and other specific information can be accurately and completely documented. Documentation of the requirements will in turn facilitate the creation of design documents, test plans and scripts as well as training and user manuals.
How to Use These Tools edit
Focus for Requirements Facilitation/Elicitation edit
A review of a high-level process diagram provides a context for meeting attendees. Starting at this high level, the participants at a requirements gathering event can be acclimated to the subject of the discussion before drilling down into particulars of the process. A low-level process map can be used to identify inputs and outputs to the process, any communications that occur during the process, alternative process flows, process customers, data sources and any other of a number of elements that are needed to define requirements.
Business Use Cases and User Stories provide the foundation for understanding what business task or process needs to be accomplished, allowing existing requirements to be refined and completed from the user perspective. Use Cases can encompass more than one process, capturing required interactions between actors in a process. The User Story encapsulates a single value-adding feature so that development efforts can be directly focused to the goal of the Story.
Graphical illustrations become more and more important as a way to set user expectations. These diagrams illustrate the application of requirements to a real business process and often identify missed or incomplete/inaccurate requirements. Data Dictionaries, project Glossaries and Business Forms all provide a context for discussing design specifications. Reviewing these documents with stakeholders ensures that requirements are complete, concise and accurate.
Other Uses for Tools edit
Design specifications provide direction for application developers regarding exact data, interface and process details. Mockups and Data Dictionaries are especially useful for communicating design specifications to IT developers. Data models, screen navigation and process functionalities are derived from these tools and translated into working applications.
Manuals that are created for training, administration or application users may often include mockups, diagrams and other illustrations that are developed during the requirements gathering process. Some organizations provide guidance to users at implementation that mirrors the basic flow of the Business Use Case as well as the Use Case exception or variation process flows. The requirements are incorporated into user and administrator manuals to help users in understanding why and how the established application does what it does.
How to Create Some Diagrams edit
Visio© edit
One of the most popular tools available to business analysts in the public sector is the Microsoft Office® Visio©. The Visio© product includes many shape stencils that can be used for many different types of diagrams. These shapes are organized for the analyst into groups reflecting the types of diagram that can be created. For example, many of the Software stencils that come with Visio© support UML diagrams. There are many sources to download the OMG BPMN 2.0 Visio© stencil for free on the Internet and for Visio 2010©, a BPMN (v1.2) Template is included with the software.
Visio© uses drag and drop to create diagrams that use shapes provided on shape ‘stencils’. Connectors that are included on the stencils are used to indicate flows, relationships, messaging or other object interface connections or associations. Objects may be modified in Visio© by right-mouse clicking on them. The pop-up menu displayed may include extra properties embedded in the object that can be adjusted.
When adding connectors between objects, place the connector so that the ends of the shape are enclosed and the connected shapes are highlighted; this will ensure that when one of the shapes is moved, the connection will be preserved and the connector will automatically move to the most logical placement between the two objects.
Microsoft Office® Excel© edit
An excellent tool to use for a variety of business analysis tasks is the Microsoft Office® Excel© application. The application supports lists, metrics formulas, charts, reporting, filtering, sorting, consolidation and many other tasks that an analyst performs. The print setup feature allows worksheets and workbooks to be pre-formatted for printing so that reviewers will be able to generate readable hard copies easily. Spreadsheet cells, data, columns and rows can be quickly formatted to accurately reflect the contents.
Microsoft Office® Word© edit
Document artifacts can be produced using Microsoft Office® Word©. Requirements documents are typically used to present and distribute project requirements for review and approval. Documents can be converted to .pdf documents for posting and distribution using the Adobe® Acrobat Professional© software.
General Tips edit
- Each software application that is used to generate diagrams includes extensive documentation in the Help feature. Many specific actions are described and explained in the Help files and should be used for reference.
- When copying graphic images that were creating using a tool that embeds formatting, convert the image to an unformatted image before pasting into a document or artifact file. This is done by copying and pasting the image into a format-neutral application such as MS Paint, then copying the image from the format-neutral application to the final document or artifact. This procedure ensures that all readers of the document will be able to view the image without requiring the originating software application to be installed on their computing device.
- When setting up diagrams, use the source application header and footer configuration to include the file name, print date and page numbers. This will support an easy way to retrieve the originating file, identify when the diagram hard copy was generated and help keep multi-page diagrams organized for the reader. Including the diagram’s baseline date in the header/footer ties the diagram directly to the project timeline.