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.


Anonymous said...

Fantastic blog you have here, I have a website that you
might find interesting, on how to get people to see
your web blog free. We have a list of over 200 free to submit directories
Stop by let me know what you think of it.
free directories

louislando7939 said...

i thought your blog was cool and i think you may like this cool Website. now just Click Here

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.