Tag: Techniques

Requirements in Context Part 5: Detail Requirements for Build or Buy

Written by Dan Tasker on June 29, 2016. Posted in Articles. 1 Comment on Requirements in Context Part 5: Detail Requirements for Build or Buy

The previous article in this series was about keeping the content of high-level requirements (HLRs) at a high level. This article is about the content of detail requirements containing the appropriate amount of detail. We start with a discussion of four delivery contexts, two involving building the solution in-house and two involving purchasing solutions. Examples of requirements are presented using two forms – User Stories and traditional Shall statements. But regardless of form, at the end of the day, content is king.

Build or Buy Contexts

The availability of subject matter experts (SMEs) is a critical factor in sourcing content for detail requirements. For the purpose of this article, we will assume that such people are available. Of equal importance to this deliverable is the consumer of these requirements – those responsible for delivering (i.e. designing, developing and testing) the solution based on the detail. Consider the following delivery contexts:

Build – In-house with embedded SME (e.g. full Agile)
Build – In-house without embedded SME (e.g. Agile-like, Waterfall)
Buy – a custom-built solution (outsourced development)
Buy – a package solution (with optional customization)

NOTE: The Build/Buy decision process itself is out of scope of these articles.

Build – In-house With Embedded SME

What could be better than having the source of detail requirements, an SME, as a full-time member of the development team? Not only that but working on a business information system that can be implemented bit by bit. Personally, I have only experienced Agile-like development. But based on reports from colleagues there are organizations where these conditions exist.

In full Agile environments, whether user stories eliminate the need for detail requirements or they are just considered to be an improved form of requirements, each user story still needs to include content that drives development and guides testing on the way to ‘done.’ From a requirements perspective, the real improvement is that development does not need to wait for a full set of requirements before work begins. Also, the delivery of results into production occurs not long after the requirement has been expressed.

Full marks to this delivery context and the Agile user story form that drives it. But developing and testing has to involve the complete content of what is wanted, so ultimately that content needs to be recorded somewhere (see examples below).

In-house Build Without Embedded SME

I am fresh off a project that utilized Agile-like development. We were given traditional business requirements. Some were high-level, others low-level-ish. As a BA, my role in one of the Scrum teams was ‘pseudo’ product owner. It was my job to interpret selected requirements and write the corresponding user stories and acceptance criteria. Where a requirement was unclear or did not contain sufficient detail, it was necessary to go back to the business requesting clarification.

Besides the problem with requirement content, the overall project was not suited to incremental implementation. At the end of each sprint, teams were able to demonstrate the results of completed stories, but these elements needed to wait many months for a major release of the system.

Functionality being delivered in each major release had to undergo both integration testing and user acceptance testing (UAT). Acceptance criteria from the user stories were of some use to the broader testing efforts, but end-to-end tests had to be developed separately. And because the business users had not been involved with the user stories, they had to come up with their own UAT test cases.

Based on this experience, my conclusion is that the Agile-like context would benefit from detail requirements that contain the most complete content possible. Requirements in either Shall or User Story form can and should include acceptance criteria. This would support any level of testing required.

Buy A Custom-Built Solution

The model of custom-built solutions that I am most familiar with involves the following steps:

The business provides requirements for what is to be delivered and selects a supplier.
The supplier produces a Statement Of Work (SOW) based on the requirements, specifying what they agree to deliver.
The supplier delivers the solution for UAT and bug fixing.
The supplier expects ‘final’ payment and supports warranty period.

My most recent experience involving a supplier was from the business perspective. The development form that the supplier used was Agile. But given that they were relying on client-provided requirements rather than embedded SMEs, they were really only Agile-like. Nor was the detail in their SOW in user story format. The crucial point about this context is that it necessitates the requirements content, regardless of form, to be complete and detailed at the point in time the supplier commits to deliver for a contracted cost.

Buy A Package Solution

Package solutions are almost always a compromise between requiring customization to support the acquiring organization’s current business processes and adjusting the organization’s current business processes to align with what is supported by the package ‘out of the box.’ Any customization required most often is done by the package supplier. If customization is wanted, then requirements for that work falls into the Buy context described above. Even if functional customization is not necessary, there will likely be interfaces and/or reports that need to be developed or customized. Each of these will require detail requirements to support that development. Again it is the content of that detail that is critical, not its form.

So basically regardless of any build or buy context, detail requirements in one form or another are involved – ideally providing unambiguous content. So let’s have a look at what level of detail should be provided for different types of requirements.

Content Detail for Report Requirements

In the previous article the following example of a high-level report requirement was presented:

The system shall support on-line customers being provided with the details of the order that they just placed including a list of items purchased, the amount charged, and expected delivery date in an email so that they have an off-line record of their on-line purchase.

The objective of a Report HLR is to describe it just enough so it is understood in terms of its purpose and value to the overall business information system. During detail requirements, the trick is not to record the detail as a series of individual detail requirements. The detail should ideally be specified in a report template.

A proper report template provides for capturing required information such as frequency, delivery method, and selection criteria. There should be provision for including a layout of the report showing relative placement of headings and labels. Lastly, the template should cater for recording supporting information about the fields seen in the layout. Fields like “Customer Number,” “Transaction Date/Time,” and summary total fields would need little or no explanation. But fields that require special lookup or values derived from other fields should be described, preferably including examples.

With report details recorded in a template-based specification, the detail requirement itself actually can be very simple. The following are examples of how simple a report detail requirement can be when the detailed content is relegated to a specification:

User Story Format:

As a Customer, I want to receive an email containing the details of what I just ordered on-line so that I have an off-line record of my purchase.

Shall Statement Format:

The system shall produce an email to on-line customers upon their submission of each order.

Both requirements should include acceptance criteria:

Acceptance Criteria

Given an on-line customer
When the customer places an order
Then the Customer receives an email that conforms to the “Customer Order Confirmation Email” specification found Appendix C.

While acceptance criteria in the Given/When/Then format has its origins in Agile, there is no reason it can’t be included with Shall statements.

Assuming that all aspects of the report share the same priority, business rationale, and need to be tested together, there is little or no advantage in representing different aspects as separate detail requirements.

Content Detail For Data Requirements

When the scope of a project is known to include new types of data (records and/or fields), ideally it’s good for these to be included as detail data requirements. The previous article had this example data HLR:

The system shall support establishing new customers, including capturing details such as name, address, and contact information, ensuring that every customer is uniquely identifiable. E.g. Fred Smith assigned customer number 555123, The Carter Foundation assigned customer number 654287.

From a detail requirements perspective, new record types needed in the business information system should be named and defined. Volume-related estimates are good to have. For new fields (including links to other tables) again business name and definition are useful. For fields, the details of their data type and size should be specified.

Depending on the complexity of the information there may need to be some database design done on the way to a solution. Still, for any new tables and/or fields designers and database administrators need specific information that can only come from an SME. As with reports, the types of information needed about data is common and best served by a Data Definition template.

This again means that all that is needed is a single detail requirement in one form or another. The Shall format example would look like this:

The system shall provide storage for information about Customers as described in the Customer data specification found in Appendix D.

Again, while the above requirement does not appear detailed, the overall information provided (mostly in the template specification) provides what is needed to get the job done. Also like the detail report requirement, if the full content is not provided, when it comes time to design and/or build the data solution an SME will need to be consulted.

Content Detail For Interface Requirements

System interfaces either import data that’s needed by a business information system or else export available data needed by some other system. Where the project scope has identified that information needs to pass between systems, there should be a high-level requirement that represents that need. The example from the HLR article was:

The system shall support sourcing of foreign exchange rates from the European Central Bank on a daily basis to support currency conversion when the on-line customer deals in a different currency than the supplier of a product.

From a detail requirements perspective, an SME should know what data items are expected from or by the other system. It should be possible to list those data items based on the existing (or under development) business information system.

If the number of data items is small, they can be listed right in the detail requirement. If larger or complex data structures are involved, the details can be described separately (dare I say using an interface template?). An example in user story form with a self-contained list of interface data items would be:

As the system, I want to receive daily currency exchange rate data from the European Central Bank so that I can convert purchase amounts from a supplier currency to a customer’s preferred currency.

Acceptance Criteria

Given access to base exchange rates made available from European Central Bank
When the ECB exchange service makes new rates available
Then the following details about each currency is recorded and available for use converting between currency pairs:
- To Currency E.g. USD
- Effective Date
- Exchange Rate From Euro E.g. 0.89
- Rate Type E.g. Mid-Market

Data items in an interface list should include details such as attribute name, description, and examples. The objective is to support the subsequent ‘mapping’ of corresponding items on each side of the interface during the interface development phase, where field details of size and type can be addressed. This technical mapping is done by someone familiar with the business information system’s database schema. That person will also need access to the external system’s interface specification.

Upcoming Articles

This article included discussions of content for Report, Data and Interface requirements. The two requirement types that were not addressed were Functional and Non-Functional. Types of Non-Functional requirements are each very different and the detail content will not be covered in this series. But detail functional requirements are so important that the next two articles are devoted to them (including adding Use Cases to the mix of possible forms of representing detail). Stay tuned.

Strategy Spotlight: Benchmarking & Baselining Your Organization in 6 Easy Steps

Written by Richard Lannon on June 7, 2016. Posted in Articles. 2 Comments on Strategy Spotlight: Benchmarking & Baselining Your Organization in 6 Easy Steps

You cannot conduct strategic business analysis or project management without benchmarking and creating a baseline. That is a fact.

I have seen times where executives and professionals skip this part of the planning process, thinking that they have all the information they need to document the current state. I have seen a lot of incidences where these people have been wrong and engage in a form of blame-storming when something was missed.

When working on a project, whether a pre-initiative or post-agreed, you need to focus on your benchmark and create a baseline to ensure you are clear about your present situation. A benchmark is a standard point of reference within your industry against which things may be compared or assessed. A baseline is the starting point used to compare your historical performance. Both are connected in the world of business analysis, sometimes interchangeable. The definition can change based on context.

Benchmarking became an important part of business performance management and a key input into financial analysis and business process improvement. It is also a powerful tool in change and transformation analysis forcing executives to look at the reality of the business through the facts. This is a practice that can become extremely uncomfortable for some people at times.

When I was thinking about this blog, I reviewed some of the steps that I have taken to benchmark a client’s internal and external situations. I realized that for me, benchmarking and baselining followed a standard 6 steps of activities.

1. Preparation

You will often hear me say preparation is the key to the success of any engagement. That is the truth in facilitation and in benchmarking activities. In this case, preparation has to do with your initial interviews and discussions with the leadership team to help you understand where their thoughts are at present, focusing on finding out ‘what, why this and why now.’ As part of this preparation, you need to know to what level the stakeholder is invested in the situation. Is it an emotional connection, being dictated from elsewhere or are they just stepping through the steps? This is all important to know.

2. Research

Getting the information you need is all about data collection. Information can be considered primary or secondary. Primary information is an account of the event from an original source. Secondary information is an interpretation of the account of the event.
There are many means of getting the information you need. I often use a three stage questionnaire process with the primary information holders and pre and post interviews to get a present state understanding for benchmarking. I expand my understanding by adding documentation reviews from inside and outside the organization.

3. Analysis

This is a key part of the pre-planning process often requiring information integration, leveling data and checking the sources and facts. You may need to normalize the data to ensure that a direct comparison is possible for operational subjects and issues. The analysis needs to provide comparisons, look at the gaps, cover all strengths and weaknesses, and be improvement focused. By this point you should have a clear state of the company, the project, the industry or application.

4. Presenting

This could be called reporting. It is just a matter of what the deliverable is. Prior to doing any planning type session (workshop, review, discussion), I do a summary of findings. This summary is laid out in such a way that the high-level stakeholders get a story of their present situation and is used for future planning. It is often delivered as a high-level, point form, executive summary with the supporting summary of findings behind it. It is not an extensive report – only a summary of findings. There is a difference. Accompanying a summary of findings might be a 6-slide deck using images to capture the data components.

5. Lessons

I have always liked the expression “forewarned is forearmed”. I think that is what lessons learned should be about, especially when we are doing benchmarking.

During the process, the business analyst should have gotten a clear picture of what I call the “truth”. The issues at play are known, and you should be able to pre-determine how things are going to play out and therefore plan more effectively. At a higher level, the best performing organizations share information and best practices for the benefit of all. If your baseline and benchmark are clear and honest, then you can start to focus on solutions and actions that need to be taken.

6. Actions

It is great to use the word “actions”, but it should not come before planning. In other words, “plan to act” with a well thought out implementation or action plan. This can only be done after the lessons have been accepted, integrated into the key stakeholders thinking (planning team) and the lessons learned can feed into the planning process.

The focus here is what you need to do to go forward based on your benchmark and baseline for your organization with all the common constraints. Dialogue should be forthcoming.

I can’t even remember the number of times that I have been part of benchmarking an organization or system through a combination of interviews, surveys, documentation, industry reviews, and workshop facilitation. I’ve participated in all of these activities just to get a clear picture of the state of things.

I do believe the process can be standardized and applied to any situation where getting clear on the present state is important and benchmarking to internal or external standards.

Developing good benchmarking and baselining skills is important. Chances are you will find yourself following a very similar process each time. I would encourage you to document your approach and share it. It is the place where good business analysis and planning starts. I hope this helps.

And remember:

Be your best, invest in the success of others, and make your journey count.

Richard

Requirements In Context Part 3: Scope = High-Level Requirements

Written by Dan Tasker on May 31, 2016. Posted in Articles. 1 Comment on Requirements In Context Part 3: Scope = High-Level Requirements

The first article in this series established the context of requirements being addressed are those that relate to business information systems and that various contexts have an impact on those requirements. The second article addressed the first of these contexts – Functional. That context was further divided into three conceptual levels labelled Functions, Processes and Activities. An example high-level requirement was presented at each of these levels.

Project Scope

This article moves on to a different context – Project Scope. We will see how scope statements, when making reference to business functionality, leads directly to high-level requirements.

Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope of a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered.

Related Article: Using Feature Trees to Depict Scope

A Context Diagram Is Worth A Thousand Words

In addition to the bulleted item list of scope, it is very common for the project initiation document to include a context diagram. The objective of a context diagram is to illustrate what is inside the system and what is outside. Things outside the system represent sources and/or consumers of data. The original form of context diagram comes from Dataflow Diagramming (DFD). The top-most level of functional decomposition using DFDs was considered a context diagram. The Unified Modelling Language (UML) Use Case modelling also supports a form of context diagram. Both of these diagramming techniques represent ‘the system’ and both portray things outside the system boundary. The DFD term for these outside things is External Entity. The UML term is Actor. The definition of these two terms is virtually identical.

A DFD context diagram says nothing about the functions inside the system. That is left to subsequent levels of functional decomposition. Clues are provided by labels given to the data flows. The Use Case context diagram provides more of a clue to the functions within scope by including named use cases. Data flows in a DFD context diagram connect only to the system. Actor connectors in a Use Case context diagram connect to one or more specific use cases within the system.

High-Level Requirements From Project Scope

Examples of high-level requirements were presented in the previous article based on a high-level business function, a medium-level business process and a low-level business activity. We are about to present an example of a project and its scope. As mentioned above, the scope of business information system projects is very often expressed in functional terms. It should, therefore, be possible to derive high-level requirements from scope items.

Consider the following situation involving a large hypothetical on-line retailer we will call Nile.com:

Nile.com has a well-established purchase process for its on-line customers. The check-out portion of this process includes activities for identifying the intended shipping address and for providing some form of payment. What the process does not currently include is anything to do with tax on items being purchased. As the result of pressure from various tax authorities this needs to change.

In establishing a project to deal with this change in the business environment the following scope items were agreed by the business sponsor and signed off:

Maintaining tax-related details for designated tax authorities
Determining applicable tax on items being purchased
Including applicable tax with purchases
Accounting for tax charged

The Use Case form of context diagram for this example would look like this:

Scope items will seldom be stated so conveniently that they can be converted one-for-one into the names of use cases. For the sake of brevity, please accept that the scope items in this example are “ones that I prepared earlier.”

The objective of this article is to show that it is possible to derive high-level requirements based on a project’s scope. The following are examples of such requirements from the scope in this scenario:

Scope Item 1 – Maintaining tax-related details for designated tax authorities

The system shall support an administrator maintaining tax-related details required to perform tax determination. This includes establishing tax authorities that are the source of tax rates and to whom collected taxes need to be paid. It also includes mapping of products to tax rates for each authority where there are product-specific rates or specific product types that are tax exempt.

Because charging tax is new to this organisation there may not be an in-house subject matter expert available when it comes time to sorting out the details for this requirement. Until more is known this high-level requirement acts as an appropriate placeholder for what is likely to be a number of business processes. One would likely be needed for setting up new tax authorities, one for setting up the tax rates and where applicable, one for specifying different rates for different product types. The requirement from a business perspective is fairly straight forward – maintain whatever details are necessary to be able to charge tax. The devil is in the detail.

Scope Item 2 – Determining applicable tax on items being purchased

The system shall be able to identify the appropriate tax that applies to the purchase of a given product based on the product type and the tax authority(s) that have jurisdiction where the shipment is to be delivered.

Where the previous requirement calls for wholly new business processes to be supported within the business information system, the functional context of this requirement would be somewhere within the “Identify the shipping address” activity within the “Purchase” process. At this point the product(s) are known, and the shipping address details can be used to determine any applicable tax authority(s). Subsequent detail requirements would get into how an appropriate tax rate is determined and specifics of where that rate is used in calculating the total charge to the customer.

Scope Item 3 – Including applicable tax with purchases

The system shall present to the customer all applicable tax amounts as part of the purchase process.

This statement should be sufficient as a high-level requirement from a business perspective. Part of the detailed requirements analysis would include identifying all of the places where the customer ‘sees’ purchase price details. Each of those places will require modification to include whatever tax applies, if any.

Scope Item 4 – Accounting for tax charged

The system shall report charged tax amounts as a distinct component of each purchase to the general ledger system identifying appropriate GL Codes and the designated tax authority.

Wherever money is involved the organisation’s general ledger needs to be kept informed. In this case it is unlikely that there will be any new processes or even activities required. Reporting to the GL will be in place for the current untaxed purchases. This reporting will just require an enhancement to include the tax amount and its corresponding GL Coding. There should also be an existing Accounts Payable process that handles making payments to suppliers for the organisation. The different tax authorities that are to receive payment of collected taxes should be covered under that process.

Next Time – Keeping High-Level Requirements High-Level

The four requirements derived from the project scope items would not be the only ones for the whole project. But it must be said that they cover the agreed scope of the project and that they are high-level (not slipping into detail). Next time we will look into how to keep high-level requirements high-level when dealing with stakeholders that are asked to participate in the context of “Gathering high-level requirements.”

Strategy Spotlight: 8 Tools & Techniques to Apply to Strategic Analysis & Planning

Written by Richard Lannon on May 10, 2016. Posted in Articles.

There are many definitions, tools, and techniques that can be applied to strategy analysis. If you do an internet search you will find all sorts of options available. The challenge is selecting the best approach, tools, and techniques to use given the business problem or opportunity.

Another part of the challenge is understanding what strategy analysis means since there can be many definitions. This can make it confusing. It is best to simply say that strategy analysis is an approach to facilitating, researching, analyzing, and mapping an organization’s abilities to achieve a future envisioned state based on present reality and often with consideration of the organization’s processes, technologies, business development and people capabilities. Part of that whole process is the ability to bridge gaps that exist between the strategic, tactical, and operational aspects of the organization. This requires a look at the present state, the future state, risk and financials and the creation of change requirements to achieve the desired outcomes.

Related Article: Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

Even though the definition of strategy analysis varies, there is common thinking on the key planning requirements.

Preparation for planning through the identification and review of information relevant for strategy analysis
Performing high-level environmental scan looking at the internal and external business environment with consideration for mission, vision, stakeholders, structure, existing plans, people profiles, and question responses.
Applying a choice of different tools and techniques to analyze the present state of a business environment and mapping out its future.

Some of the more common analysis tools and techniques include:

VMOST: This stands for Vision, Mission, Objectives, Strategy, and Tactical.

Success in an organization happens with top-down or bottom-up alignment. I was recently reminded of is when working with a client who stated that their tactical is not connected to the strategy. VMOST analysis is meant to help make that connection.

SWOT: The standard analysis tool, defined as Strengths, Weaknesses, Opportunities, and Threats.

Strengths and weaknesses are internal to the organization, opportunities and threats are external. SWOT requires you to be candid and provide an honest assessment of the state of things. It forces you to create a dialogue with stakeholders to get different viewpoints. Eventually, you focus in on the key issues.

PEST: This is a great tool to use in tandem with SWOT. The acronym stands for Political, Economic, Social and Technology.

PEST reveals opportunities and threats better than SWOT, the direction of business change, projects that will fail beyond your control, and country, region and market issues through helping you create an objective view.

SOAR: This stands for Strengths, Opportunities, Aspirations, and Results. This is a great tool if you have a strategic plan completed, and you need to focus on a specific impact zone.

I used SOAR to help a business that needed to focus on their business development requirements due to an external market change. The organization needed to discuss how they would recapture lost sales by $1 million per month to ensure they maintained their profitably. Given that they had already done everything they could to cut costs and operate a lean business, the SOAR was critical in helping define the focus for the next 12 to 24 months.

Boston Matrix (product and service portfolio): This tool requires you to analyze your business product or service and determine if it is a cash cow, sick dog, questionable, or a flying star.

I have applied this tool to product and service reviews with to help make product decisions with consideration for market share and market growth. But it has no predictive value, does not consider the environment, and you need to be careful with your assumptions. It does force discussions on your present offering and whether it makes sense to maintain or enhance those offerings. For example, maybe you are holding onto a business product that you love but is really a sick dog and maybe there is a cash cow in your business that you are not optimizing. A decision has to be made.

Porter’s Five Forces: This tool helps you understand where your business power lies in terms of present competitiveness and future positioning strength. It forces you to analyze the bargaining power of suppliers and customers, the threats to new entrants and substitutes, and competitive rivalry in your marketplace. Using this tool helps you understand the balance of power and to identify areas of potential profitability. According to Porter, this model should be used at the line of business level.

Maturity Models: There are many maturity models that can be applied to a business. From the evolution model, the technology model, to the team model. The idea is that every business or department goes through a maturity cycle. The standard cycle is chaotic, reactive, proactive, service, and value. If you were looking at processes in a department, you would look to see where that process is on the continuum. Then you would determine where you need to be and what it would take to get to that point of maturity. This is a simple explanation. When using a maturity model, it is important that you have a clear problem definition and solution context.

Root Cause Analysis: This is important, as there are times in the strategy analysis process you need to dig deeper into a problem. This is where RCA is used. The key is that you need to identify and specify the problem correctly, analyze the root cause using a systematic approach, verify the causes, and determine the corrective actions. Implementation of the corrective action is extremely important.

There are many definitions, tools, and techniques that could be addressed. The ones mentioned here are only the tip of the iceberg for strategy analysis and become a foundational part of the strategy analysis toolkit. In a short blog, there is no way to mention them all. But you could create a tool checklist that you could use in your next planning and analysis engagement to help you and your team define the present, future, risk and change state that you need to succeed.

Until next time, be your best, invest in the success of others and make your journey count.

Richard

Check out Richard’s workshop at Project World * Business Analyst World Toronto on Thursday, May 12 – “Strategic Business Analysis – Techniques to Uncover and Define Business Need“

Requirements In Context Part 1: Just Know It!

Written by Dan Tasker on May 3, 2016. Posted in Articles. 1 Comment on Requirements In Context Part 1: Just Know It!

I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential.

In thinking about what constitutes quality requirements, it occurred to me that there are a number of additional contexts that play a role. Examples include the organizational maturity level (from Informal through to Optimized) and delivery context (green fields through to package acquisition).

This is the first in a series of articles about business requirements. My primary objective is to help business analysts improve their elicitation and documentation of requirements. With an increased awareness of multiple contexts I believe that the quality of the requirements documented can be improved, and subsequently, lead to the better design, development and implementation of business systems.

Mark Twain is credited with saying, “Everyone talks about the weather, but nobody does anything about it.” The equivalent saying in the IT context would be, “Everyone agrees that good requirements are essential, but nobody does anything about them.” A perfect illustration of this is the classic IT cartoon “The Swings”:

What is not funny about this cartoon is that the situation it depicts is as true about business systems delivered today as it was when the above version was published. Over 40 years of struggling, and most often failing to meet user expectations, in spite of unimaginable improvements in technology.

I have no illusions that what I intend to present will magically make it all better. But these articles are at least my attempt to do something about it. If you are reading this, it means you are interested in improving your BA skills. Hopefully learning about the impact of different contexts on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or friend mentions that they want something – a new car, an electrical appliance, I immediately go into ‘requirements mode.’ I start asking questions intended to help them focus on their thinking in order to lead to making the best choice.

It occurred to me that it as I begin to present the various contexts related to requirements that I should set the context for this series of articles. The context of requirements that I intend to focus on is business information systems. And while a complete information system includes a hardware and a network aspect, the requirement contexts that will be discussed will not include these technical aspects. The requirements contexts will focus on business analysts interacting with business users to deliver the functional and information components of a system.

Please note that when I use the term ‘system,’ from a requirements perspective that doesn’t mean that every requirement will result in a computer-based solution. Having gathered requirements, a subsequent exercise is to determine which of them will be given automated support and which will be left as manual processes.

Functional and Information Components

The earliest “computers” were primarily electronic calculators. They allowed complex formulas to be broken down into individual computational steps. Having expressed these steps in a language the computer could understand the resulting instruction set was ready to receive the data to be manipulated. The end product was a set of calculated results.

When businesses began using computers, their objective was to maintain data about their business. Computational requirements were minimal. Simple things like adding or subtracting deposits and withdrawal amounts from a customer’s account balance. The original computerized business systems all performed their functions by reading in batches of data, operating on each record as it went through the system, and producing individual results before the next record was processed.

With the advent of database management systems and access in ‘real time’ to computer applications, more and more business processes could be supported by computers. Today virtually every office worker has a computer on their desk. And thanks to wireless networks and portable devices workers (and customers) outside of the office have access to the information they need when they need it.

With the focus of business information systems being the support of functions that capture and utilise data I offer a variation on the Nike slogan “Just Do It”. The objective of the business information systems we gather and document requirements for should be “Just Know It.”

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey itself will begin in the next article. In it, I will present a technique I have used for many years to help establish the functional context for a requirements gathering effort. The more common term for this functional context is “Project Scope.”

I will also discuss the possibility of combining the scoping exercise with the producing of high-level requirements. The result of doing this reduces that requirements task down to hours rather than days (or weeks). This will be the first of several demonstrations of the strength of applying the thinking that “Context is everything.”