Defining Business Requirements

Defining Business Requirements

Defining Business Requirements.

Requirements development is an iterative and incremental process, where you need a set of methods to ensure that you can move from fuzzy notions into a detailed specification, a layer at a time.  When you are facilitate a workshop, keep the discussion focused on the objective identified for that workshop.  Don’t let the participants get bogged down in excessive detail or the system solution when you are trying to document business requirements.   Understand that all business users will declare that their requirements have top priority.  By using a methodology, you can distinguish dependency and priority in relation to the Project Charter and Business Case.

Requirements rarely change, but your understanding of them does.  Analysis is a science and design is an art.  There should be one analysis / business model, one that fully models the business value stream (end to end process) and many design / solution models.  For example, the business model for the banking value stream: Customer Wants to Transfer Funds from One Account to Another, has the following business requirements:

  • Can the customer prove they are who they say they are?
  • Does this customer have access to a bank account where they can withdraw funds from? For example, you cannot withdraw funds from a car lease account.
  • Does the bank account have sufficient funds in it?
  • Is the account that the funds are being transferred to, have the ability to receive the funds? For example, you cannot transfer funds to a closed or inactive bank account.

Currently, there are various different design solutions, each has their own controls and functions that are required that meet the above business requirement below is an example, of how each method implements the first business requirement – Can the customer prove they are who they say they are:

  • The manual teller – photo id and signature
  • The ATM or self-service terminal – card and PIN
  • Internet banking user id and password
  • Telephone banking – user id and PIN or verification of personal information or answers to secret questions.

When you find user requirements are changing during the project life cycle, this is usually because the solution / the design has been modelled and not the business / the analysis.

There is no such thing as shortcut in development life cycle.  Shortening our requirements gathering effort will result in a system that doesn’t meet the business’ need and must be rewritten or modified.  Remember analysis is performed in all projects, it’s just a matter of when, I find it’s usually in the development and maintenance phases.  Every week you save by not modelling results in several weeks of needless programming because developers will build what they think.   Avoid shortcuts – do it once by doing it right.

Today’s archaeological dig:
Slush fund:
The fat obtained by “scraping the bottom of the barrel” by the ship’s cook and secreted away in his “slush fund” for selling ashore to candle makers, tanneries, etc. The words now describe a rainy-day fund or cash reserve. Alternate: The grease (slush) from frying the salt pork on a cruise was kept and sold when the ship returned to port. The money raised was put into a "fund" for the crew.

Bridging the gap between IT and Business

Bridging the gap between IT and BusinessBridging the Gap between Business & IT
System’s development is often characterised by a strained relationship between IT and Business / “the us and them syndrome”. The parties may not trust each other’s motivations or appreciate each other’s needs and constrains. In reality though, they have a common objective; a solution that works, easily and cost effectively.

As Business Analyst you may often find yourself torn between the two areas and to survive you must be honest. Sharing all relevant information with the stakeholders and telling the truth without blame or judgement to promote free and informed choices. Such an ideal environment isn’t always achievable. In fact, none of my suggestions are likely to work if you’re dealing with truly unreasonable people.

Defining Business requirements early in the project will clarify the prospective benefits for both the business and IT. The participants also need to realistic about costs and project constraints.

It’s not unusual for an analyst to solicit input from users only to be told, “I don’t have time to talk to you. You should know what I need”: However, project success is most like to occur when the analyst can forge an effective collaborative relationship with key business representatives. Identify individuals who could serve as the voice of the business for each business event, then engage them in discussion of their needs.

Business representatives might hesitate to participate in the requirements exploration until they know exactly what you expect from them, document project responsibilities clearly. Insufficient user involvement is well established as a leading cause of software project failure. Point this out to reluctant business users, who don’t want to spend time on requirements discussions. Remind them of problems you have experiences on previous project that can be attributed to inadequate user involvement. Nearly every organisation has horror stories of new systems that didn’t satisfy user needs, didn’t provide expected functionality, performance expectations or duplicated the shortcomings of the preceding systems. You can’t afford to keep rebuilding or discarding systems that don’t measure up because the user’s needs weren’t sufficiently understood. If the business won’t commit to reaching a shared understanding of their requirements, it might you’re your best interest to avoid that project.

This week’s archaeological dig:
Posh:
In the days when the wealthy traveled to India by ship it was customary for passengers to book quarters on the cooler port side of the vessel on the outward journey, and the similar cooler starboard side on the homeward trip. Hence port/out (PO) and starboard/home (SH) gave rise to the acronym POSH. Today we refer to people of class (Spice Girls notwithstanding) as being posh.

Business Analyst Communication

Business Analyst and communication

Communication and the Business Analyst

The Business Analyst communication becomes the middleman, bridging the gap between vague business user notions and clear development specifications. This analyst must first understand the user’s actual needs and then define a set of Business Requirements that allow designers, implementers and testers to build and verify the system. If you aspire to be an effective analyst, become proficient all forms of communication, including listening, speaking and writing. As you interact with user representative, understand their objectives of the proposed projects and their concerns about the business. Learn to use the vocabulary of the business, rather than forcing your business users to understand your jargon. Include business terms in your Data Dictionary.

Don’t be afraid to ask for clarification; business users should not expect every analyst to be a business expert. You might explain that you’re not completely familiar with their business and that is why you don’t fully grasp what they are describing. This approach sometimes makes the business more willing to help because they can see that you’re making a real effort to understand their environment. This is where models become imperative, as there is no ambiguity in modelling rules.

We all think within our own frame of reference, which is based on our own experience and knowledge. Take the time to learn about your business user’s environment and understand how they prefer to communicate. Watch out for assumptions that underlie either the users’ expression of needs or your own thinking. Avoid imposing your personal field of understanding on what you hear the user say.

Requirements development should lead to an understanding shared by the various project stakeholders. The analyst is responsible for writing high-quality and well-organised requirements that clearly express this shared understanding. Writing documents that business representatives can understand and verify, is a challenge, which is why I recommend that you use models (a picture tells a 100 words). Support the picture with narrative text, to further clarify understanding.

Today’s archaeological dig:
Port and Starboard:
Originally, the old sailing ships (like the Vikings), didn’t have a rudder, and were steered by a board on the right side. This came to be the “steerboard” side; the other side was called “larboard” at first, but since the side with the board couldn’t be against the dock, this other side, the left, became the “port” side.