Friday, March 28, 2008

Get Those Rules and Requirements, Part 1

One of the clear goals of the IT Service Management (ITSM) approach is to create and support alignment between business goals and IT Services. To that end, the IT organization develops a specialized set of capabilities to deliver value to the business in the form of products and services. It should be obvious that a keen understanding of the business vision, mission and goals is necessary as a foundation for designing those products and services. How does the IT Service organization build the foundation? By learning and understanding the business rules and business requirements.

Simply put, business rules are those things that business must or must not do in order to exist and operate. Business rules originate from laws, regulations, contracts, and similar external drivers. Business rules guide the business’ behavior and circumscribe the “what” of a business, answering the question, “What business are we in?” How you choose to implement or enforce the rules is a different matter.

Business requirements define the conditions or capabilities needed to meet a business objective or solve a business problem. Requirements are statements that tell you what must be done to enable the implementation of and compliance with a business rule. Normally expressed in terms of desired outcomes, business requirements answer the question, “What do we need to conduct our business?” In ITSM, the goal is to create and maintain technology-based services that support fulfilling the business requirements.

Functional requirements describe what a product or service has to do to fulfill the business requirement(s). Functional requirements may be referred to as System Requirements, and can be in a many-to-one relationship with a business requirement.

Non Functional requirements describe how the product or service will fulfill the business requirement(s). They are requirements that specify attributes of the functional requirements, e.g. performance, scalability, security and usability requirements. Often nonfunctional requirements may be referred as the “ilities”. This is because many of them are expressed in terms like scalability, reliability, usability, stability, manageability, etc. The processes in the Service Design domain help the IT Service provider to discover, document, define and quantify these desirable attributes of a product or service as nonfunctional requirements.

How does the IT Service provider find out about the business rules or requirements? By developing and maintaining strong relationships with the customers. Documents such as vision statements, budget justifications, and internal procedures can be resources for matching IT services to business goals. Tools such as workshops, interviews, brainstorming, focus groups and the Service Knowledge Management System (SKMS) can assist the IT Service provider in developing and maintaining a deeper understanding of the business perspective. This is a valuable tool for identifying opportunities to align IT products and services with specific business goals and objectives. The Service Design domain, which contains the Service Level Management Process, concerns itself with customer relations.

Rhane Thomas

No comments: