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:
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.