I am back from the Business Rules Forum, last week in Orlando. I have a lot of material to make use of, so I thought I would start with giving an overview of the major points themes of the conference:
- Business Rules has its origins in Expert Systems as well as Data Modeling.
- Business Rules and Business Processes are becoming more integrated than ever. BR approaches can be used to manage the ‘decision diamonds’, and simplify the maps themselves.
- Most common questions: who should document Business Rules? Is it Business Analysts? What is a Business Analyst?... I met a few people who are founding the Jacksonville FL chapter of the IIBA, and mentioned the existence of the IIBA in a few sessions.
- Some participants were evangelists who see Business Rules as the center of business and systems; others see Business Rules as apart but integrated with all the other ‘artifacts’ of business requirements, especially as organized by the Zachman Framework.
- The Zachman Framework was itself a common subject across many presentations, capped by a closing presentation by John Zachman himself. While his framework is methodology and artifact independent, he does however see Business Rules as a valuable addition to the Business Model of Row 2 of the Framework, mainly in the Motivation Column.
To see the overall agenda for the forum, you can visit http://www.businessrulesforum.com/
Saturday, November 19, 2005
Wednesday, November 16, 2005
Requirements and Architecture
Are my Information System Deliverables equal to artifacts that that can be organized by the Zachman Framework?
Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/
Let’s see what columns I have covered with my deliverables:
Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.
That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.
From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).
You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.
Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.
Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/
Let’s see what columns I have covered with my deliverables:
Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.
That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.
From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).
You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.
Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.
Monday, October 31, 2005
Integrating Requirements Deliverables
Some of the requirement Deliverable integration possibilities have been touched on in the previous postings. Listed together, they are:
- Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business.
- Use Cases can include the Declarative Requirements for the Information System/Solution.
- A Data Model will document all data items used within the scope of a set of Use Cases, and is cross-referenced in the Use Case for the data items used by the latter.
- Business Rules can also be documented across the scope of the Business being analyzed, including both the set of Use Case and the overall Process Map, as a Business Rule may be invoked at different points and times with the Business Operations. Use to date has shown they can then best cross-referenced in:
o In the Use Cases whose execution is impacted by one or more Business Rules
o In Process Maps at Decision Points, as Business Rules may play a role in deciding which path within a Map should be followed in any one execution of the Process
I have a diagram showing the relationships, but my blog site does not want to accept an upload of it. I will keep trying, but in the meantime, contact me at dwwright99@hotmail.com and I will send you the diagram (as a bmp file).
- Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business.
- Use Cases can include the Declarative Requirements for the Information System/Solution.
- A Data Model will document all data items used within the scope of a set of Use Cases, and is cross-referenced in the Use Case for the data items used by the latter.
- Business Rules can also be documented across the scope of the Business being analyzed, including both the set of Use Case and the overall Process Map, as a Business Rule may be invoked at different points and times with the Business Operations. Use to date has shown they can then best cross-referenced in:
o In the Use Cases whose execution is impacted by one or more Business Rules
o In Process Maps at Decision Points, as Business Rules may play a role in deciding which path within a Map should be followed in any one execution of the Process
I have a diagram showing the relationships, but my blog site does not want to accept an upload of it. I will keep trying, but in the meantime, contact me at dwwright99@hotmail.com and I will send you the diagram (as a bmp file).
Thursday, October 27, 2005
Business Rules
As a concept, Business Rules are not new, to the Business or IT; what is new is the focus on separating them from other forms of documentation so they can better defined and managed. Business Rules are similar to Process Models/Maps in that they are subject to more frequent change than other aspects of the business, frequently enough that if rules are hard-coded in an Information System, the effort and elapsed time to change the system can be too large to be tolerated by the business over time.
So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and Change independently of the information systems that uses them.
What is a Business Rule?
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further.
“Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.
I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply and process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.
The paper with the above definition is available at http://www.businessrulesgroup.org/first_paper/br01ad.htm
It includes an example case study of a fictitious car rental company with many defined business rules; here is a sample:
Rental reservation acceptance
- If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group).
- Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day.
- If the customer requesting the rental has been blacklisted, the rental must be refused.
- A customer may have multiple future reservations, but may have only one car at any time.
So, please go read that article at the Business Rules Group website (I want to avoid any charges of plagiarism of that site on my site).
To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include rental request, car group, reservation, branch, and customer. An example of a fact would be "a customer may have multiple future reservations": it’s when you add the constraint "but may have only one car at any time" that you have a rule, using that fact and the relevant terms.
Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in some ways, but they are similar enough that if you have both, you can easily use one to drive the creation of the other.
So, now we have covered all the Requirements formats that I commonly use:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules
… and I have already touched on some aspects of how these formats can be inter-related and integrated. I will review all those and add some more aspects in my next post on Integrating Requirements Deliverables.
So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and Change independently of the information systems that uses them.
What is a Business Rule?
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further.
“Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.
I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply and process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.
The paper with the above definition is available at http://www.businessrulesgroup.org/first_paper/br01ad.htm
It includes an example case study of a fictitious car rental company with many defined business rules; here is a sample:
Rental reservation acceptance
- If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group).
- Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day.
- If the customer requesting the rental has been blacklisted, the rental must be refused.
- A customer may have multiple future reservations, but may have only one car at any time.
So, please go read that article at the Business Rules Group website (I want to avoid any charges of plagiarism of that site on my site).
To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include rental request, car group, reservation, branch, and customer. An example of a fact would be "a customer may have multiple future reservations": it’s when you add the constraint "but may have only one car at any time" that you have a rule, using that fact and the relevant terms.
Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in some ways, but they are similar enough that if you have both, you can easily use one to drive the creation of the other.
So, now we have covered all the Requirements formats that I commonly use:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules
… and I have already touched on some aspects of how these formats can be inter-related and integrated. I will review all those and add some more aspects in my next post on Integrating Requirements Deliverables.
Monday, October 17, 2005
Process Models - are they bad for Requirements?
I am not aware of the origin of Process Models as we see them today, but their profile was certainly raised by Hammer and Business Process Re-engineering; you certainly had to define your Business Process before improving/re-engineering it. For myself, the one aspect of Process Models that does not get enough attention is defining & understanding the Events in the business environment (external or internal) that kick-off the execution of a Process; know your Events, as they come in handy in many ways when defining Information System Requirements
As a format for documenting Information System Requirements, process models can have a negative impact on the resulting system. The process as it exists at the time of documentation has often been ‘hard-coded’ in the delivered computer system; when the process needs to change, the system cannot support a different process, and the business starts to adapt or create work-arounds to get the work done despite the constraints of the system.
This situation occurs frequently because it is not recognized that some aspects of the business are less stable than others. It has been shown that the process of a business, especially the order of separate steps, is the least stable aspect of a business; at the other end of the scale, the data items and their definitions as used by a business are the most stable aspect of that business. In between the two ends of the scale fall things like specific procedures (units of work) and business rules.
So, automation of the current business process should not be an Information System Requirement. In fact, more generic process and workflow software have been developed over the years to specifically support rapid change in process, adding or changing or re-ordering process steps as needed.
Where Process Models play a role in documenting Information System Requirements is to provide a context for Use Cases. Most steps in a process map will state that some work is done in that step, before the process flow continues; often this work involves use of an Information System, which can be documented as a Use Case. As stated in earlier posts, the Use Case then provides context for Declarative Requirement Statements, as well as a cross-reference to data items and their definitions in a Data Model.
Just a few years ago, this would have been the last ‘format’ that would have been described in this document. However, a new emphasis on methods and formats for documenting Business Rules has recently emerged, the topic for my next posting.
As a format for documenting Information System Requirements, process models can have a negative impact on the resulting system. The process as it exists at the time of documentation has often been ‘hard-coded’ in the delivered computer system; when the process needs to change, the system cannot support a different process, and the business starts to adapt or create work-arounds to get the work done despite the constraints of the system.
This situation occurs frequently because it is not recognized that some aspects of the business are less stable than others. It has been shown that the process of a business, especially the order of separate steps, is the least stable aspect of a business; at the other end of the scale, the data items and their definitions as used by a business are the most stable aspect of that business. In between the two ends of the scale fall things like specific procedures (units of work) and business rules.
So, automation of the current business process should not be an Information System Requirement. In fact, more generic process and workflow software have been developed over the years to specifically support rapid change in process, adding or changing or re-ordering process steps as needed.
Where Process Models play a role in documenting Information System Requirements is to provide a context for Use Cases. Most steps in a process map will state that some work is done in that step, before the process flow continues; often this work involves use of an Information System, which can be documented as a Use Case. As stated in earlier posts, the Use Case then provides context for Declarative Requirement Statements, as well as a cross-reference to data items and their definitions in a Data Model.
Just a few years ago, this would have been the last ‘format’ that would have been described in this document. However, a new emphasis on methods and formats for documenting Business Rules has recently emerged, the topic for my next posting.
Sunday, October 09, 2005
Data Requirements
Data Models are used to define the data needed for an Information system to use and/or control, and often form the basis for the definition and creation of databases. The most common format used to capture data requirements is the Entity-Relationship Diagram, which I believe originated with Clive Finkelstein and was most popularized by James Martin’s Information Engineering Methodology.
A Web Search on Entity-Relationship Diagrams or on Data Models will return thousands of hits, as I think that Data Models as a requirements format are more popular than even Use Cases. Here are two interesting links I found today:
1) Data Modeling: Finding the Perfect Fit
An Introduction to Data Modeling
by Tim McLellan
Copyright 1995. All Rights Reserved.
http://www.islandnet.com/~tmc/html/articles/datamodl.htm
2) Applied Information Science
(Data) Modeling Methodologies
http://www.aisintl.com/case/method.html
In my use of data models for Requirements, the main component is the Data Entity, a subject of interest to the Business, associated by the business relationships between them. Each entity contains data items/attributes that relate to or describe the Entity. Each attribute belongs only to one Entity, so duplication of Requirements is reduced.
Entity-Relationship data models are also commonly classified as ‘Conceptual’ or ‘Logical’, in that they are intended to communicate the data requirements of the Business. Such models can then be transformed into a ‘Physical’ Data Model that is used to design a database.
If a Data Model is used in conjunction with Use Cases, the latter’s data items can be defined by a cross-reference to the Data Model. As a result, a data item used in multiple use cases will be defined only once, eliminating duplication and inconsistency.
A Web Search on Entity-Relationship Diagrams or on Data Models will return thousands of hits, as I think that Data Models as a requirements format are more popular than even Use Cases. Here are two interesting links I found today:
1) Data Modeling: Finding the Perfect Fit
An Introduction to Data Modeling
by Tim McLellan
Copyright 1995. All Rights Reserved.
http://www.islandnet.com/~tmc/html/articles/datamodl.htm
2) Applied Information Science
(Data) Modeling Methodologies
http://www.aisintl.com/case/method.html
In my use of data models for Requirements, the main component is the Data Entity, a subject of interest to the Business, associated by the business relationships between them. Each entity contains data items/attributes that relate to or describe the Entity. Each attribute belongs only to one Entity, so duplication of Requirements is reduced.
Entity-Relationship data models are also commonly classified as ‘Conceptual’ or ‘Logical’, in that they are intended to communicate the data requirements of the Business. Such models can then be transformed into a ‘Physical’ Data Model that is used to design a database.
If a Data Model is used in conjunction with Use Cases, the latter’s data items can be defined by a cross-reference to the Data Model. As a result, a data item used in multiple use cases will be defined only once, eliminating duplication and inconsistency.
Thursday, October 06, 2005
Use Cases
I am probably a relative new-comer to use cases, after working in analysis and requirements through Structured Analysis and Design in the eighties, and Information Engineering in the nineties. I found one author’s description of them almost aesthetically appealing, that each one is a case (or example) of the use of a system.
After that, I have seen many variations and permutations and various ‘uses’ of use cases; either that is a testament to their flexibility, or a condemnation of their vagueness. If you are new to Use Cases, be aware that different flavors of use cases are out there, being promoted and being used. When I am feeling the need for some rigor or consistency, I always go back to Alistair Cockburn (pronounced ‘coburn’) at http://alistair.cockburn.us/
Overall, I have seen and used two basic types of use cases:
- A multiple-step interaction between Actor and System, which relates to user interface design, and capturing the required functionality the system must provide to support the interaction. I saw this a lot when working with co-workers who were OO designers and programmers.
- A single step or occurrence format, where an Actor initiates the use case, which is provided some input and/or pre-conditions, and it executes a set of actions (calculate something, retrieve or store something else) that produces a result of interest to the Actor. (There may be multiple Actors, too.) The set of actions that are first defined are those that will normally execute, if no exceptions or other variations occur. I call this the ‘happy path’, as I am sure some author or instructor called it that, but I can’t recall who. However, if it is known that one or more exceptions/variations from the ‘happy path’ could occur (due to certain input values or combinations of pre-conditions), these are documented as alternative paths. Creators of these types of use cases don’t like to see path selection in their use cases, no “IF-THEN-ELSE” statements; use your alternatives instead.
Finally, both of the above types differentiate between the use case itself as the definition or template of the ‘use of the system’, and Scenarios, which are specific instances of the use case given one set of possible input values or pre-conditions; changing the input values produces another scenario, so a large number of scenarios could be defined for one use case, all of which will help the Testers of the information system developed based on the use case(s).
As you might expect by now, I mainly use the second type of use case as part of documenting Information Systems Requirements. They are extremely valuable as, if nothing else, a widely-accepted format for documenting the results of Analysis; anything that effectively assists in communicating Business Requirements to one or more audiences is something that should be used(!).
Now, they are not perfect, and they are not the ultimate format for documenting Requirements… they are only one format of many (five at last count). One issue I had with use cases early on was identifying them in the first place: what was the scope of each use case? How many use cases do you need? There will definitely be more than one. What I can say now is that one way use cases can be identified is by there relationship with Process Models, and I will describe this in a future post.
However, once you do have a set of use cases defined that cover the scope of the business you are analyzing, you can use them to organize the Declarative Requirements Statements I described in my last posting. I often start an Analysis effort by creating a list of High-Level Requirement Statements based on initial discussions with the business subject matter experts; if the these people want a new or enhanced system, they will tell you what they want from that system, which you can capture as Declarative Requirement Statements.
Once I have moved ahead to capture the necessarily detailed description of the business in use cases, I then allocate those Declarative Requirement Statements to the use cases that will actually support the Requirements (if you end up with Requirements that don’t match up to any of your use cases, you might be missing some use cases.) Detailed analysis will also support the definition of more Requirement Statements, again associated with particular use cases.
It might be argued that the detail provided in a use case supersedes the need for Requirement Statements, but I believe they still play an important role in communicating the essence of the use case. Designers/Developers will look to the use case detail for their understanding of the Requirements, but the Requirement Statements are often preferred by Testers as documentation of what they must test, and the Statements provide trace-ability from the Analysis through Design/Development to Testing.
So to this point, we have covered Declarative Requirement Statements and Use Cases, including how the two can be associated with each other… it must be time to discuss Data Requirements… in my next post.
After that, I have seen many variations and permutations and various ‘uses’ of use cases; either that is a testament to their flexibility, or a condemnation of their vagueness. If you are new to Use Cases, be aware that different flavors of use cases are out there, being promoted and being used. When I am feeling the need for some rigor or consistency, I always go back to Alistair Cockburn (pronounced ‘coburn’) at http://alistair.cockburn.us/
Overall, I have seen and used two basic types of use cases:
- A multiple-step interaction between Actor and System, which relates to user interface design, and capturing the required functionality the system must provide to support the interaction. I saw this a lot when working with co-workers who were OO designers and programmers.
- A single step or occurrence format, where an Actor initiates the use case, which is provided some input and/or pre-conditions, and it executes a set of actions (calculate something, retrieve or store something else) that produces a result of interest to the Actor. (There may be multiple Actors, too.) The set of actions that are first defined are those that will normally execute, if no exceptions or other variations occur. I call this the ‘happy path’, as I am sure some author or instructor called it that, but I can’t recall who. However, if it is known that one or more exceptions/variations from the ‘happy path’ could occur (due to certain input values or combinations of pre-conditions), these are documented as alternative paths. Creators of these types of use cases don’t like to see path selection in their use cases, no “IF-THEN-ELSE” statements; use your alternatives instead.
Finally, both of the above types differentiate between the use case itself as the definition or template of the ‘use of the system’, and Scenarios, which are specific instances of the use case given one set of possible input values or pre-conditions; changing the input values produces another scenario, so a large number of scenarios could be defined for one use case, all of which will help the Testers of the information system developed based on the use case(s).
As you might expect by now, I mainly use the second type of use case as part of documenting Information Systems Requirements. They are extremely valuable as, if nothing else, a widely-accepted format for documenting the results of Analysis; anything that effectively assists in communicating Business Requirements to one or more audiences is something that should be used(!).
Now, they are not perfect, and they are not the ultimate format for documenting Requirements… they are only one format of many (five at last count). One issue I had with use cases early on was identifying them in the first place: what was the scope of each use case? How many use cases do you need? There will definitely be more than one. What I can say now is that one way use cases can be identified is by there relationship with Process Models, and I will describe this in a future post.
However, once you do have a set of use cases defined that cover the scope of the business you are analyzing, you can use them to organize the Declarative Requirements Statements I described in my last posting. I often start an Analysis effort by creating a list of High-Level Requirement Statements based on initial discussions with the business subject matter experts; if the these people want a new or enhanced system, they will tell you what they want from that system, which you can capture as Declarative Requirement Statements.
Once I have moved ahead to capture the necessarily detailed description of the business in use cases, I then allocate those Declarative Requirement Statements to the use cases that will actually support the Requirements (if you end up with Requirements that don’t match up to any of your use cases, you might be missing some use cases.) Detailed analysis will also support the definition of more Requirement Statements, again associated with particular use cases.
It might be argued that the detail provided in a use case supersedes the need for Requirement Statements, but I believe they still play an important role in communicating the essence of the use case. Designers/Developers will look to the use case detail for their understanding of the Requirements, but the Requirement Statements are often preferred by Testers as documentation of what they must test, and the Statements provide trace-ability from the Analysis through Design/Development to Testing.
So to this point, we have covered Declarative Requirement Statements and Use Cases, including how the two can be associated with each other… it must be time to discuss Data Requirements… in my next post.
Monday, October 03, 2005
Declarative Requirement Statements
The Declarative Requirement Statement format is a direct assertion of one “...property that is essential for an IT system to perform its functions.” They are ‘declarative’ in that they do not imply any order or flow upon the information system. Such statements are usually part of a larger group or list of Requirement Statements, and can be documented at various levels --- from High-Level Requirements that are often documented first in a project, to detailed statements used as input to Design and as the source of Test Cases.
The common structure is: “…the System must.”
Variations on this structure include:
• Referring to the “Solution’ instead of ‘System’, as an information or other type of ‘System’ is not always what is needed to meet the Requirements of the business.
• Variations on the verb ‘must’, such as ‘shall’ or ‘will’; a ‘must’ statement is often interpreted as a mandatory requirement, while statements using other verbs mean the requirement is optional or ‘nice-to-have’. If multiple verbs are used in a set of Requirement Statements, the specific meaning of the use of each verb should be clearly defined.
Examples:
“The System will provide security that a Manager can only view salary data for their own reporting staff.”
“The System will calculate the monthly payment for a loan application, given the
• Interest Rate,
• the Amount Borrowed,
• and the Number of Payments & Payment Frequency”
Presenting large numbers of Requirement Statements can be a challenge, and grouping them by common attributes is one means of organizing the statements; one very common classification is the grouping of requirements as Functional or Non-Functional.
Requirement Statements can also be given a context by associating them with other documentation methods, such as Use Cases. This will be the topic of my next post.
The common structure is: “…the System must
Variations on this structure include:
• Referring to the “Solution’ instead of ‘System’, as an information or other type of ‘System’ is not always what is needed to meet the Requirements of the business.
• Variations on the verb ‘must’, such as ‘shall’ or ‘will’; a ‘must’ statement is often interpreted as a mandatory requirement, while statements using other verbs mean the requirement is optional or ‘nice-to-have’. If multiple verbs are used in a set of Requirement Statements, the specific meaning of the use of each verb should be clearly defined.
Examples:
“The System will provide security that a Manager can only view salary data for their own reporting staff.”
“The System will calculate the monthly payment for a loan application, given the
• Interest Rate,
• the Amount Borrowed,
• and the Number of Payments & Payment Frequency”
Presenting large numbers of Requirement Statements can be a challenge, and grouping them by common attributes is one means of organizing the statements; one very common classification is the grouping of requirements as Functional or Non-Functional.
Requirement Statements can also be given a context by associating them with other documentation methods, such as Use Cases. This will be the topic of my next post.
Wednesday, September 14, 2005
Documenting Information System Requirements
To support their understanding, the key aspect of all Information System Requirements is that they be documented; this usually means they are written down in some way. Many authorities on Requirements will say that if a Requirement is not written down, it does not exist; on the other hand, each authority tends to have its own favourite format (original or adopted) for documenting Requirements. Since the 1970’s, many different formats (and the systems development methodologies they were often part of) have been published and used. Over time, several format/methods have survived and are commonly used; for example, most analysts and developers are familiar today with use cases.
It is also now apparent that no one format is sufficient to represent all Information System Requirements. Since information systems can do many things –- calculations, store data, produce reports, support/enforce proper business practice --- it is necessary to recognize that the means of representing the requirements need to vary as well. As such, no one format captures all the requirements for information systems, but using several formats collaboratively, virtually all requirements can be documented and related to each other.
The following formats are those that I am commonly using to document Requirements:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules
I will be looking at each format in future posts, followed by my thoughts how to use all of them in collaboration to fully document Requirements for Information Systems.
It is also now apparent that no one format is sufficient to represent all Information System Requirements. Since information systems can do many things –- calculations, store data, produce reports, support/enforce proper business practice --- it is necessary to recognize that the means of representing the requirements need to vary as well. As such, no one format captures all the requirements for information systems, but using several formats collaboratively, virtually all requirements can be documented and related to each other.
The following formats are those that I am commonly using to document Requirements:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules
I will be looking at each format in future posts, followed by my thoughts how to use all of them in collaboration to fully document Requirements for Information Systems.
Monday, September 12, 2005
Requirements Discovery
Discovering Requirements makes use of different ‘behavioral’ techniques that will be familiar to anyone involved in systems development: find the key business experts and:
- interview them individually, or
- gather them in groups for structured discovery sessions (usually faster than individual interviews)
If access to the experts is limited or there is a very large number of experts, you may need to resort to questionnaires or other less direct methods, but I avoid these if I can, as they are inherently less effective. Of course, you should first read all documentation, policies, procedures and other source material relevant to the business that you can find. There may not always be much of this material, and it may sometimes be out-of-date, but find and use what you can.
The interesting thing is that there actually are a lot of books and training on the use of Behavioral Techniques for discovery of requirements. I have worked at companies where the Analysis phase of their System Development Methodologies covers nothing but Behavioral Techniques. As a result, I don’t think I will be writing much on this topic in upcoming posts. However, I find that these sources include little or nothing on how to effectively document the requirements after discovery, such that they can be agreed to by the business, and communicated to system designers and developers….. Documentation Techniques for Requirements is where I will focus my efforts at this site, starting with the next Posting.
- interview them individually, or
- gather them in groups for structured discovery sessions (usually faster than individual interviews)
If access to the experts is limited or there is a very large number of experts, you may need to resort to questionnaires or other less direct methods, but I avoid these if I can, as they are inherently less effective. Of course, you should first read all documentation, policies, procedures and other source material relevant to the business that you can find. There may not always be much of this material, and it may sometimes be out-of-date, but find and use what you can.
The interesting thing is that there actually are a lot of books and training on the use of Behavioral Techniques for discovery of requirements. I have worked at companies where the Analysis phase of their System Development Methodologies covers nothing but Behavioral Techniques. As a result, I don’t think I will be writing much on this topic in upcoming posts. However, I find that these sources include little or nothing on how to effectively document the requirements after discovery, such that they can be agreed to by the business, and communicated to system designers and developers….. Documentation Techniques for Requirements is where I will focus my efforts at this site, starting with the next Posting.
Thursday, September 08, 2005
What can be required of an Information System, Part 4
It’s all about the Rules:
The previous Parts have described that Information Systems have Requirements for processing (mainly data), storing data, and communication; these types of Requirements have been recognized for a long time, although not always viewed as being of relatively equal importance.
What has only more recently been recognized is that requirements for processing can often be defined in fairly straight-forward terms, but controlling that processing can be complex; all the exceptions, special cases, or alternative processing that may be needed. What is required of an Information System is to accept and use the rules of the business which drive, control and amend the system’s processing, better known as Business Rules. If this is a new or unexplored concept to the reader, I recommend visiting www.businessrulesgroup.org ; suffice it to say that defining the Business Rules that a system is required to support separate from process, data or communication requirements, results in an overall set of all Requirements of higher quality. (Of course, these different types of Requirements are not completely independent of each other; a future posting will describe how they are inter-related.)
Well, I think I am finished describing the types of Requirements that can be requested of a typical Information System. Remember, we are not talking about missile-guidance systems, or ‘Grand Theft Auto’ (see my earlier posting ‘What is an Information System?”). I am finished at this time, anyway; more types of Requirements are likely to be recognized down the road. For example, I would probably would not have identified Business Rules separately if I was writing this a decade ago.
So, given this set of Requirements, we need to (1) discover them, and (2) document them, so that Information Systems can be delivered that will actually meet the Requirements. … I will carry on with these topics in my next posting…
The previous Parts have described that Information Systems have Requirements for processing (mainly data), storing data, and communication; these types of Requirements have been recognized for a long time, although not always viewed as being of relatively equal importance.
What has only more recently been recognized is that requirements for processing can often be defined in fairly straight-forward terms, but controlling that processing can be complex; all the exceptions, special cases, or alternative processing that may be needed. What is required of an Information System is to accept and use the rules of the business which drive, control and amend the system’s processing, better known as Business Rules. If this is a new or unexplored concept to the reader, I recommend visiting www.businessrulesgroup.org ; suffice it to say that defining the Business Rules that a system is required to support separate from process, data or communication requirements, results in an overall set of all Requirements of higher quality. (Of course, these different types of Requirements are not completely independent of each other; a future posting will describe how they are inter-related.)
Well, I think I am finished describing the types of Requirements that can be requested of a typical Information System. Remember, we are not talking about missile-guidance systems, or ‘Grand Theft Auto’ (see my earlier posting ‘What is an Information System?”). I am finished at this time, anyway; more types of Requirements are likely to be recognized down the road. For example, I would probably would not have identified Business Rules separately if I was writing this a decade ago.
So, given this set of Requirements, we need to (1) discover them, and (2) document them, so that Information Systems can be delivered that will actually meet the Requirements. … I will carry on with these topics in my next posting…
Tuesday, September 06, 2005
What can be required of an Information System? Part 3
Requiring Information Systems to support Communication:
In the beginning, there was one computer, as we would recognize it today. Historians can be specific on whether it was a code-breaking machine of World War 2, or IBM's first commercial machine. Again, historians can confirm the famous quote of IBM's chairman saying there would only be 4 or 5 computers required for the whole world.
However, once there was more than one computer, it was just a matter of time before connections and networks appeared. It is not my intent, nor am I qualified, to describe how we arrived at the networked world of today; nor am I currently interested in the most popular uses of networks, such as email or instant messaging (although that might change in the future, as content evaluation and management tools allow information systems to make use of such unstructured data; if someone has expertise in that area, please reply to start a thread on that topic.).
From an Information System perspective, networks are useful for sending data from system to system, including the notification of other systems (or sub-systems) of an event on interest that has occurred. This means we can use Information Systems to track business events and actions in a business (or business department), and automate the overall business process, combining data processing with communication. Within a business enterprise, this most commonly results in workflow systems, such as those that originated along with first commercial imaging systems 10 to 15 years ago. Since then, the Internet has allowed the definition and implementation of cross-enterprise processes, best know as B2B. I was fortunate to participate in standards development for B2B processes in the high-tech industry with the RosettaNet organization; see http://www.rosettanet.org/ .
As a result, a very common requirement made of Information Systems today is to use their communications capability to control and improve an Enterprise's business processes.
Next time: its all about the Rules...…
In the beginning, there was one computer, as we would recognize it today. Historians can be specific on whether it was a code-breaking machine of World War 2, or IBM's first commercial machine. Again, historians can confirm the famous quote of IBM's chairman saying there would only be 4 or 5 computers required for the whole world.
However, once there was more than one computer, it was just a matter of time before connections and networks appeared. It is not my intent, nor am I qualified, to describe how we arrived at the networked world of today; nor am I currently interested in the most popular uses of networks, such as email or instant messaging (although that might change in the future, as content evaluation and management tools allow information systems to make use of such unstructured data; if someone has expertise in that area, please reply to start a thread on that topic.).
From an Information System perspective, networks are useful for sending data from system to system, including the notification of other systems (or sub-systems) of an event on interest that has occurred. This means we can use Information Systems to track business events and actions in a business (or business department), and automate the overall business process, combining data processing with communication. Within a business enterprise, this most commonly results in workflow systems, such as those that originated along with first commercial imaging systems 10 to 15 years ago. Since then, the Internet has allowed the definition and implementation of cross-enterprise processes, best know as B2B. I was fortunate to participate in standards development for B2B processes in the high-tech industry with the RosettaNet organization; see http://www.rosettanet.org/ .
As a result, a very common requirement made of Information Systems today is to use their communications capability to control and improve an Enterprise's business processes.
Next time: its all about the Rules...…
Thursday, August 04, 2005
What can be required of an Information System? Part 2
The core input that computers process is ‘data’:
From http://www.answers.com/data
da·ta (used with a sing. or pl. verb)
1. Factual information, especially information organized for analysis or used to reason or make decisions.
2. Computer Science. Numerical or other information represented in a form suitable for processing by computer.
3. Values derived from scientific experiments.
4. Plural of datum (sense 1).
I think we all know by now it all comes down to providing the computer large numbers of zeros and ones to crunch. In the field of Information Systems, the bits are used to represent numbers (as counts, identifiers, dollar amounts, etc.) and letters (words and text). Other data formats are seen in some Information Systems, most commonly graphics, especially maps in GIS systems… but most information systems today primarily process numbers and text, and that is where my interest (and actual work) is focussed.
Equally important as processing data in today’s information systems is storing data: to be processed later, or to store the results of processing, or to be stored for its own inherent value and accessed as needed in support of business activities. Hence, we have the requirement of almost all Information Systems to provide a database for storage of data beyond its use in processing; or, to be able to access other databases separate from the Information System.
There has been a long and still on-going debate in the Information Systems field about the relative value of data processing ‘versus’ data storage, especially in the sub-field of Information Resource Management (IRM). This discipline addresses the drawbacks of each Information System in an organization managing all its own data, if that leads to data redundancy and systems producing conflicting information using their own data; the common vernacular for this situation is ‘stove-pipe systems’, which is as good an analogy as any for this common situation. The corollary for this on the processing side is that an organization does not want more than one system performing the same function, either.
Unfortunately, I have seen the equivalent of religious wars between groups of information systems practitioners that see either data processing as more important than data storage, or data storage as more important than data processing. The reality is that both are needed, and the principles behind IRM can be used to produce the best information systems that an organization needs.
Next time: requiring Information Systems to support Communication
From http://www.answers.com/data
da·ta (used with a sing. or pl. verb)
1. Factual information, especially information organized for analysis or used to reason or make decisions.
2. Computer Science. Numerical or other information represented in a form suitable for processing by computer.
3. Values derived from scientific experiments.
4. Plural of datum (sense 1).
I think we all know by now it all comes down to providing the computer large numbers of zeros and ones to crunch. In the field of Information Systems, the bits are used to represent numbers (as counts, identifiers, dollar amounts, etc.) and letters (words and text). Other data formats are seen in some Information Systems, most commonly graphics, especially maps in GIS systems… but most information systems today primarily process numbers and text, and that is where my interest (and actual work) is focussed.
Equally important as processing data in today’s information systems is storing data: to be processed later, or to store the results of processing, or to be stored for its own inherent value and accessed as needed in support of business activities. Hence, we have the requirement of almost all Information Systems to provide a database for storage of data beyond its use in processing; or, to be able to access other databases separate from the Information System.
There has been a long and still on-going debate in the Information Systems field about the relative value of data processing ‘versus’ data storage, especially in the sub-field of Information Resource Management (IRM). This discipline addresses the drawbacks of each Information System in an organization managing all its own data, if that leads to data redundancy and systems producing conflicting information using their own data; the common vernacular for this situation is ‘stove-pipe systems’, which is as good an analogy as any for this common situation. The corollary for this on the processing side is that an organization does not want more than one system performing the same function, either.
Unfortunately, I have seen the equivalent of religious wars between groups of information systems practitioners that see either data processing as more important than data storage, or data storage as more important than data processing. The reality is that both are needed, and the principles behind IRM can be used to produce the best information systems that an organization needs.
Next time: requiring Information Systems to support Communication
Wednesday, August 03, 2005
What can be required of an Information System? part 1
What can be required of an Information System?
Computerized information systems can do many things, and in the future will likely do many things that have not been thought of yet. What I would like to describe is what I believe are the most common things that information systems are required to do, and use that to lead us to the means of documenting those requirements.
The core ‘concept’ of computers is ‘process’. Computers process stuff, turn ‘input’ into ‘output’, …the central component of a computer is a ‘Processor’. However, computers have to know before-hand precisely what to do to turn that input into output, and documenting that ‘what’ correctly is crucial, or the output will be unacceptable. The business knows generally what it wants the computer to do, designer/developers know how to make the computer do it, and the Business Analyst plays the interpreter between the two.
(Before I continue, I am well aware of the long-standing attempts to reduce the level of precision that is needed by computers and still produce acceptable output, most commonly in the area of ‘fuzzy logic’. Artificial Intelligence (AI) also seeks to make the computer less demanding in the precision of the instructions provided to it. However, it is unlikely that information systems that most people use in their jobs incorporate fuzzy logic or AI, especially if money is involved… you are more likely to encounter it on home PC playing Half-Life 2 or Medal Honor; game vendors like to boast they have the best ‘AI’ in their products to produce computerized opponents. I do wonder if AI academics see it that way.)
So, documenting ‘what’ a computerized information is supposed to do is an essential part of defining the Requirements for that system. Many different methods with many different names have been published over the last 50 years, intended to help a Business Analyst in this task; probably the only common aspect to emerge from these decades is that the end result is called the “Functional Requirements”, defining what the system is to do.
(A corollary aspect is the defining of ‘Non-Functional Requirements”; if a Functional Requirement documents what the system must do, a related Non-Functional Requirement may something like how fast the Functional Requirement must be performed. Defining a system’s Non-Functional Requirements may or may not be the responsibility of a Business Analyst, so I may not address them much on this website, until the mood strikes me anyway.)
Next Time: what do computers process the most? Data!
Computerized information systems can do many things, and in the future will likely do many things that have not been thought of yet. What I would like to describe is what I believe are the most common things that information systems are required to do, and use that to lead us to the means of documenting those requirements.
The core ‘concept’ of computers is ‘process’. Computers process stuff, turn ‘input’ into ‘output’, …the central component of a computer is a ‘Processor’. However, computers have to know before-hand precisely what to do to turn that input into output, and documenting that ‘what’ correctly is crucial, or the output will be unacceptable. The business knows generally what it wants the computer to do, designer/developers know how to make the computer do it, and the Business Analyst plays the interpreter between the two.
(Before I continue, I am well aware of the long-standing attempts to reduce the level of precision that is needed by computers and still produce acceptable output, most commonly in the area of ‘fuzzy logic’. Artificial Intelligence (AI) also seeks to make the computer less demanding in the precision of the instructions provided to it. However, it is unlikely that information systems that most people use in their jobs incorporate fuzzy logic or AI, especially if money is involved… you are more likely to encounter it on home PC playing Half-Life 2 or Medal Honor; game vendors like to boast they have the best ‘AI’ in their products to produce computerized opponents. I do wonder if AI academics see it that way.)
So, documenting ‘what’ a computerized information is supposed to do is an essential part of defining the Requirements for that system. Many different methods with many different names have been published over the last 50 years, intended to help a Business Analyst in this task; probably the only common aspect to emerge from these decades is that the end result is called the “Functional Requirements”, defining what the system is to do.
(A corollary aspect is the defining of ‘Non-Functional Requirements”; if a Functional Requirement documents what the system must do, a related Non-Functional Requirement may something like how fast the Functional Requirement must be performed. Defining a system’s Non-Functional Requirements may or may not be the responsibility of a Business Analyst, so I may not address them much on this website, until the mood strikes me anyway.)
Next Time: what do computers process the most? Data!
Monday, July 25, 2005
What is an Information System?
Before addressing the specifics of Business Analysis for Information Systems, I would like to define (or attempt to define) just what an Information system is.
Computers are used for many different purposes, often with very specialized hardware and software; examples range from missile guidance systems, to supercomputers crunching numbers for scientists at high speeds. On the other hand, personal computers and the internet that use common hardware and software platforms have become a part of daily personal life, whether to play more and more sophisticated video games, or to write blogs, among other things.
However, if you use a computer as a regular part of your workday, you are likely not doing any of the things mentioned in the previous paragraph. Instead, you are probably using a computer to do business as part of your job in the private or public sectors; you might also be self-employed or otherwise own your own business, but in any case, I know you are not playing Half-Life 2... you are most definitely using an "Information System".
When considering the basic principles that support what I do as a Business Analyst, I refer back a few decades to Finklestein and Martin's statement that "Information = Data and Process"; you can supplement that with the common axiom that "information is power". All this has been true since the origins of the abacus, through to the punch cards first used for collecting census data over 100 years ago, to the arrival of digital computers in the 20th century.
Today, we now have computers and networks and publishing media and related technologies that can be used to effectively gather and use information in support of "business" activities. (In this context, "business" encompasses public and private enterprise, profit and non-profit organizations, i.e. virtually any grouping of activities that use information to reach the desired goal of those activities.)
And that is all I am going to say about "what is an Information System...", at least for now. I have stayed away from creating a dictionary-style definition, mainly because I have never liked the ones I have read in dictionaries in the past. However, if you have a succint definition that captures what I have said in this post, please send it along and I will share it and all I receive in a future post... then we should send them to Websters , and Funk & Wagnell(!).
Next time: what is it we can "require" an Information System to do...
Cheers, Dave W
Computers are used for many different purposes, often with very specialized hardware and software; examples range from missile guidance systems, to supercomputers crunching numbers for scientists at high speeds. On the other hand, personal computers and the internet that use common hardware and software platforms have become a part of daily personal life, whether to play more and more sophisticated video games, or to write blogs, among other things.
However, if you use a computer as a regular part of your workday, you are likely not doing any of the things mentioned in the previous paragraph. Instead, you are probably using a computer to do business as part of your job in the private or public sectors; you might also be self-employed or otherwise own your own business, but in any case, I know you are not playing Half-Life 2... you are most definitely using an "Information System".
When considering the basic principles that support what I do as a Business Analyst, I refer back a few decades to Finklestein and Martin's statement that "Information = Data and Process"; you can supplement that with the common axiom that "information is power". All this has been true since the origins of the abacus, through to the punch cards first used for collecting census data over 100 years ago, to the arrival of digital computers in the 20th century.
Today, we now have computers and networks and publishing media and related technologies that can be used to effectively gather and use information in support of "business" activities. (In this context, "business" encompasses public and private enterprise, profit and non-profit organizations, i.e. virtually any grouping of activities that use information to reach the desired goal of those activities.)
And that is all I am going to say about "what is an Information System...", at least for now. I have stayed away from creating a dictionary-style definition, mainly because I have never liked the ones I have read in dictionaries in the past. However, if you have a succint definition that captures what I have said in this post, please send it along and I will share it and all I receive in a future post... then we should send them to Websters , and Funk & Wagnell(!).
Next time: what is it we can "require" an Information System to do...
Cheers, Dave W
Friday, July 22, 2005
Welcome to Business Analysis
Business Analysis is what I do for a living. It primarily falls within the Information Systems & Technology discipline, but it is probably the least well known or understood skill in the IS/IT industry.
My best descriptive analogy is that of an Interpreter; I work with business people who have money, and want an information system, to define, analyze and document what they want (usually called "The Requirements"), and do it in such a way that:
1) the business people can understand and review the Requirements in order to agree it is what they want (usually called "Approval" or (Sign-Off), and...
2) ..Information System designers and programmer can understand the Requirements, such that they will design and build the system that the business wants.
My best descriptive analogy is that of an Interpreter; I work with business people who have money, and want an information system, to define, analyze and document what they want (usually called "The Requirements"), and do it in such a way that:
1) the business people can understand and review the Requirements in order to agree it is what they want (usually called "Approval" or (Sign-Off), and...
2) ..Information System designers and programmer can understand the Requirements, such that they will design and build the system that the business wants.
That leaves us with two major topics that I want to discuss in this, my first blog:
I. How do you get Business People to tell you what they really need, and..
II. How do you document it in such a way that everyone who needs to understand the Requirements, can in fact understand them and use them as needed as input for their own work.
If you want to read about such topics, and expecially if you have comments and experience in Business Analysis, then welcome to my Business Analysis blog. I am going to spend this weekend mulling over what I want to write about first, and then we will be off.
WISE
Subscribe to:
Posts (Atom)