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.
Wednesday, September 14, 2005
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...…
Subscribe to:
Posts (Atom)